Supported deployments

This page is the canonical catalog of every deployment available in Chainstack Self-Hosted — the protocols, networks, clients, client versions, resource requirements, and exposed ports. The System requirements and Deploying nodes pages link here for the per-deployment details.

​

Available deployments

The sections below group these deployments by architecture family. Each family shares the same client topology, networking guidance, and operational caveats.

​

EVM Layer 1 (execution + consensus)

Runs a paired execution client and consensus client. vCPU and RAM are split evenly across the two clients. These deployments bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. Each Ethereum network offers two preset tiers:

• Standard — 8 vCPU / 32 GiB total, for production.
• Light — 4 vCPU / 16 GiB total with the same storage, for evaluation. You can move between tiers without resizing disks.

​

Exposed ports

The execution client’s auth RPC port (8551) and the consensus client’s P2P port (13000) are used internally between clients and are not exposed.

​

EVM Layer 2 — OP Stack

Runs a paired execution client and rollup (consensus) client. vCPU and RAM are split across the two clients. Optimism Mainnet, both World Chain networks, Blast Mainnet, and both Mantle networks bootstrap from a pre-built snapshot (plan for ~2× storage during deploy). Base, Unichain, Zora, and Blast Sepolia sync without a snapshot. Blast pins its client versions per network, so Mainnet and Sepolia run different versions — see the Available deployments table above.

​

Exposed ports

The execution client’s auth RPC port (8551) is used internally between clients and is not exposed.

​

EVM Layer 2 — opBNB

Runs a paired execution client and rollup (consensus) client. vCPU and RAM are split across the two clients. Both networks bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times.

​

Exposed ports

The execution client’s auth RPC port (8551) is used internally between clients and is not exposed.

​

EVM Layer 2 — Arbitrum Nitro

Runs a single Arbitrum Nitro full node client (Nitro v3.11.2). These deployments bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times.

​

Exposed ports

​

Polygon PoS

Runs a paired execution client (Bor) and consensus client (Heimdall). vCPU and RAM are split across the two clients.

​

Exposed ports

The Bor P2P port (30303) and the Heimdall CometBFT RPC (26657) and P2P (26656) ports are used internally and are not exposed.

​

Starknet

Runs a single full node client (Pathfinder v0.22.5).

​

Exposed ports

​

TRON

Runs a single full node client (Java-Tron GreatVoyage-v4.8.1.1).

​

Exposed ports

The gRPC API port (50051) is used internally and is not exposed.

​

Bitcoin

Runs a single full node client (Bitcoin Core 31) with the transaction index (txindex) enabled.

​

Exposed ports

The P2P port (8333) is used internally and is not exposed.

​

Sui

Runs a single full node client. The client version is pinned per network, so Mainnet and Testnet can run different versions — see the Available deployments table above. These deployments bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times.

​

Exposed ports

The node serves JSON-RPC and gRPC on the same port — there is no separate gRPC listener. The P2P port (8084/UDP) and the validator network address (8080) are used internally and are not exposed.

​

Tempo

Runs a single full node client (Tempo v1.11.0) that serves both the execution and the consensus layers, so there is no separate consensus client to configure. Each node runs as a non-validator follower of an upstream endpoint, in archive mode. These deployments bootstrap from a chain snapshot that the client downloads itself rather than syncing from genesis. Unlike the other snapshot-bootstrapped families, Tempo needs no extra storage headroom for the bootstrap — the storage figures above already cover the temporary peak while the archive is downloaded and extracted. See Initial sync times.

​

Exposed ports

Both listeners serve the eth, net, web3, debug, and trace namespaces. The P2P port (30303 on TCP for RLPx and UDP for peer discovery) is used internally and is not exposed.

​

Plasma

Runs a paired execution client and consensus client — Reth for execution and the PlasmaBFT observer for consensus — as a non-validator node in full mode. Reth takes 4 vCPU / 16 GiB and PlasmaBFT takes 1 vCPU / 4 GiB. These deployments sync from genesis over the network’s public peers rather than restoring from a snapshot, so they need no extra storage headroom beyond the figures above. Expect a longer initial sync than a snapshot-bootstrapped deployment — see Initial sync times. Storage splits into 300 GB for Reth and 50 GB for PlasmaBFT on Mainnet, and 200 GB for Reth and 50 GB for PlasmaBFT on Testnet.

​

Exposed ports

Both Reth listeners serve the eth, net, web3, txpool, and debug namespaces. The execution client’s auth RPC port (8551) carries the engine API between the two clients, and the consensus client’s P2P port (34070) and telemetry port (9745) are internal — none of the three are exposed.

​

Avalanche

Runs a single AvalancheGo full node as a non-validator in full mode. One node serves the whole Primary Network, so there is no separate client per chain. Mainnet bootstraps from a pre-built chain snapshot, which temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. Fuji syncs from genesis over the network’s public peers and needs no extra headroom. See Initial sync times. The client version is pinned per network, so Mainnet and Fuji run different versions.

​

Exposed ports

All chain endpoints share port 9650 and differ only by path — /ext/bc/C/rpc for C-Chain HTTP, /ext/bc/C/ws for C-Chain WebSocket, /ext/bc/X for X-Chain HTTP, and /ext/P for P-Chain HTTP. The node overview lists all four. Only the C-Chain offers a WebSocket endpoint; the X-Chain’s pubsub endpoint was removed upstream and nothing replaced it. The P2P port (9651) is internal and is not exposed.

​

Arc

Runs a paired execution client and consensus client as a non-validator node in full mode, following the network’s public endpoints. Arc-Execution takes 6 vCPU / 24 GiB and Arc-Consensus takes 2 vCPU / 8 GiB. These deployments bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. Storage splits into 250 GB for Arc-Execution and 64 GB for Arc-Consensus.

​

Exposed ports

Both listeners serve the eth, net, web3, txpool, trace, and debug namespaces. Arc-Consensus publishes nothing of its own — its RPC port is the internal upstream of the execution client’s arc namespace. The execution client’s auth RPC port (8551), the consensus client’s RPC (31000) and P2P (27000) ports, and both metrics ports are internal and are not exposed.

​

Sonic

Runs a single sonicd full node as a non-validator in full mode. One process serves both the HTTP and the WebSocket JSON-RPC. Mainnet bootstraps from a pre-built chain snapshot, which temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. Testnet starts from a pruned genesis export and syncs the remainder from the network, so expect a longer first sync and no extra storage headroom. See Initial sync times.

​

Exposed ports

Both listeners serve the eth, web3, net, ftm, txpool, abft, dag, trace, and debug namespaces. The P2P port (5050, TCP and UDP) and the metrics port (6060) are internal and are not exposed.

​

Stable

Runs a single stabled full node as a non-validator in full mode. One process carries both the CometBFT consensus engine and an embedded EVM, so a single node serves the chain end to end and there is no separate consensus client to provision. Both networks bootstrap from a pre-built chain snapshot, which temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. The client version and the consensus timing are pinned per network, so Mainnet and Testnet run different versions and different values.

​

Exposed ports

Both listeners serve the eth, net, web3, debug, and txpool namespaces. The CometBFT RPC port (26657) is internal — it carries the node health surface, not a customer endpoint. The CometBFT P2P port (26656) and the metrics port (26660) are internal as well, and the Cosmos gRPC server is bound to loopback, so none of them are exposed.

​

Berachain

Runs a paired execution client and consensus client as a non-validator node in full mode. Bera-Reth is a Reth-based execution client that serves the JSON-RPC, and Beacond is Berachain’s BeaconKit consensus client running on CometBFT with block building disabled. These deployments bootstrap from a pre-built chain snapshot rather than syncing from genesis. Snapshot bootstrap temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. The Beacond version is pinned per network, so Mainnet and Bepolia run different versions. Compute and storage also differ per network — Mainnet splits 4 vCPU / 16 GiB and 200 GB for Bera-Reth with 2 vCPU / 8 GiB and 50 GB for Beacond, and Bepolia splits 6 vCPU / 24 GiB and 100 GB for Bera-Reth with 2 vCPU / 12 GiB and 64 GB for Beacond.

​

Exposed ports

Both listeners serve the eth, net, web3, txpool, and debug namespaces. Beacond publishes nothing of its own — its CometBFT RPC port carries the node health surface, and its ABCI proxy app is bound to loopback. The execution client’s auth RPC port (8551), its P2P port (30303, TCP and UDP), Beacond’s RPC (26657) and P2P (26656) ports, and both metrics ports are internal and are not exposed.

​

Cronos

Runs a single cronosd full node as a non-validator in full mode. One process carries both the CometBFT consensus engine and an embedded EVM, so a single node serves the chain end to end and there is no separate consensus client to provision. Both networks bootstrap from a pre-built chain snapshot, which temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. The node stores state with the RocksDB backend, under the network’s default pruning policy. Cronos Testnet additionally enables versioned state.

​

Exposed ports

Both listeners serve the eth, net, web3, debug, and txpool namespaces. The CometBFT RPC port (26657) is internal — it carries the node health surface, not a customer endpoint. The CometBFT P2P port (26656) and the metrics port (26660) are internal as well.

​

BNB Smart Chain

Runs a single reth-bsc full node in pruned mode. One process serves the chain end to end, so there is no separate consensus client to provision. Both networks bootstrap from a pre-built chain snapshot, which temporarily requires about 2× the steady-state storage while the archive is downloaded and extracted — provision the node’s volume at the peak. See Initial sync times. The node runs in pruned mode, keeping recent state rather than the full history. Mainnet is the larger of the two by a wide margin — size the volume from the catalog figures above, not from the testnet.

​

Exposed ports

Both listeners serve the eth, net, web3, txpool, and debug namespaces. The P2P port (30303, TCP and UDP) and the metrics port (9001) are internal.

​

Kaia

Runs a single kend full node with full sync and full garbage collection. One process serves the chain end to end, so there is no separate consensus client to provision. Both networks sync from genesis rather than from a snapshot, so expect a long first sync. See Initial sync times. Full garbage collection keeps the state needed to serve current-block queries. The node’s transaction pool is sized well above the client default, so it holds a deeper queue of pending transactions under load.

​

Exposed ports

Both listeners serve Kaia’s native klay namespace alongside the standard eth, net, web3, and debug namespaces, so Kaia-specific and Ethereum-compatible calls reach the same endpoint. The P2P port (32323, TCP and UDP), its subport (32324), and the metrics port (61001) are internal.

​

Ronin

Runs an OP Stack execution client and rollup client alongside a data-availability proxy. Ronin posts its rollup batches to EigenDA rather than to Ethereum calldata, so the rollup client reads generic commitments and resolves the underlying blobs through the proxy. CPU and RAM are split across the three clients. The execution client bootstraps from a published state export instead of replaying history from genesis, so it reaches the chain head without a full sync. Transactions submitted to the node are forwarded to the network’s sequencer.

​

Exposed ports

Both execution listeners serve the eth, net, web3, trace, debug, and txpool namespaces. The engine auth RPC port (8551), the execution P2P port (30303), and the proxy’s REST (3100) and metrics (7300) ports are internal — the rollup client reaches the proxy inside the deployment, not from outside it.

​

Hyperliquid

Runs a single full node that serves the EVM JSON-RPC. One process serves the chain end to end, so there is no separate consensus client to provision. The network syncs from its public peers rather than from a snapshot. See Initial sync times. The node prunes its logs on a rolling 48-hour window, so steady-state disk use stays flat over long runs rather than growing with uptime.

​

Exposed ports

The single HTTP listener carries the EVM JSON-RPC. There is no separate WebSocket listener on this deployment. The gossip ports (4001 and 4002) are internal.

​

Coming soon

See the FAQ for the roadmap.