Available deployments
vCPU and RAM figures are the standard preset totals. Ethereum networks also ship a Light preset that uses half the CPU and RAM with the same storage — see EVM Layer 1 below.
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 bootstraps from a pre-built snapshot (plan for ~2× storage during deploy). Base, Unichain, and Zora sync without a snapshot.
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.Sui Testnet needs more storage than Mainnet — ~2.2 TB against 400 GB. Mainnet bootstraps from a pruned snapshot, while Testnet bootstraps from a full snapshot and additionally ingests state from a checkpoint archive.
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.Tempo Testnet needs considerably more storage than Mainnet — ~1.1 TB against 70 GB — because the test network carries far more history.
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.
Coming soon
See the FAQ for the roadmap.