How to read these requirements
These profiles assume Linuxx86_64 hosts, production-grade SSD or NVMe storage, unmetered or high-capacity bandwidth, NTP or chrony time sync, process supervision, and monitoring for disk, CPU, memory, peer count, block lag, and service restarts.
Do not place chain data on HDD-backed storage. Network block devices should be used only after validating sustained read/write latency and IOPS during sync, compaction, upgrades, and high RPC load.
The older 500 GB SSD, NVMe recommended bootstrap value remains useful as a state-sync floor for short-lived or test infrastructure. Production nodes should use the node-profile minimums below.
Hardware matrix
| Node profile | Minimum | Recommended | Notes |
|---|---|---|---|
| Full node, pruned/private | 4 vCPU, 16 GB RAM, 1 TB NVMe, 100 Mbps | 8 vCPU, 32 GB RAM, 2 TB NVMe, 1 Gbps | Default for private application infrastructure and state-sync bootstrap. |
| Validator node | 4 vCPU, 16 GB RAM, 1 TB NVMe, 100 Mbps low-latency | 8 vCPU, 32 GB RAM, 2 TB NVMe, 1 Gbps | No public RPC. Connect only to sentries and the signer or KMS. |
| Sentry node | 4 vCPU, 16 GB RAM, 1 TB NVMe, 100 Mbps | 8 vCPU, 32 GB RAM, 2 TB NVMe, 1 Gbps | Public P2P. Enable protected RPC only when the sentry is intentionally serving that surface. |
| Seed/seeder node | 2 vCPU, 8 GB RAM, 100 GB SSD, 100 Mbps | 4 vCPU, 16 GB RAM, 250 GB SSD/NVMe, 1 Gbps | Dedicated peer-discovery role only. If deployed as a full ctmd node, use full-node storage. |
| Private RPC node | 4 vCPU, 16 GB RAM, 1 TB NVMe, 100 Mbps | 8 vCPU, 32 GB RAM, 2 TB NVMe, 1 Gbps | Internal wallets and applications, protected by firewall rules or a private gateway. |
| Public RPC node | 8 vCPU, 32 GB RAM, 2 TB NVMe, 1 Gbps | 16 vCPU, 64 GB RAM, 4 TB NVMe, 1 Gbps+ | Place behind reverse proxy, rate limits, authentication where applicable, and horizontal scaling. |
| Archive node | 8 vCPU, 64 GB RAM, 4 TB NVMe, 1 Gbps | 16 vCPU, 128 GB RAM, 8 TB expandable NVMe, 1 Gbps | Replay from genesis with pruning = "nothing" and monitor storage growth. |
| Archive RPC/debug node | 16 vCPU, 64 GB RAM, 8 TB NVMe, 1 Gbps | 32 vCPU, 128 GB RAM, 12 TB expandable NVMe, 1-10 Gbps | Private debug and trace surface only. Do not expose debug, txpool, or personal publicly. |
| Event/indexer node | 8 vCPU, 32 GB RAM, 2 TB NVMe plus separate DB storage, 1 Gbps | 16 vCPU, 64 GB RAM, 4 TB NVMe plus separately sized DB/index storage, 1 Gbps+ | For WebSocket/event consumers, scanners, and exchange or indexer pipelines. |
Storage and growth
Plan storage for the selected data mode, not just initial sync. Pruned full nodes can bootstrap with state sync and default pruning, while archive nodes must replay from genesis and retain complete historical state. Archive profiles should use expandable storage and growth monitoring. Keep enough headroom for chain growth, database compaction, upgrades, logs, and backup staging. For archive configuration, usepruning = "nothing", keep ABCI responses, enable the transaction index, and enable the EVM indexer as described in Archive Data Setup.
Archive sizing
Use1 TB as the initial archive disk sizing floor, plan for about 10 GB/month archive growth, and keep 2 TB recommended headroom. Archive RPC/debug nodes need extra CPU, RAM, and disk I/O when serving traces, long historical scans, or backfills. Run archive backups monthly and resize from observed query load.
RPC scaling
Public RPC is an infrastructure tier, not a single-node promise. Put public HTTP, WebSocket, REST, and gRPC surfaces behind a reverse proxy with TLS, rate limits, request-size limits, authentication where applicable, and IP allowlists for private or paid endpoints. Use the default public EVM namespace shapeeth,net,web3 for external RPC. Enable debug, txpool, or personal only on private operations or archive RPC nodes. For published endpoint limits, see RPC Providers and Events and WebSockets.
Validator and sentry separation
Run validator nodes as private infrastructure. They should not expose public RPC, REST, gRPC, WebSocket, or metrics endpoints. Connect validators only to trusted sentries and the signer or KMS path. Sentries absorb public P2P exposure and can be rotated or scaled without moving the validator consensus key. Recommended validator-side settings includepex = false; recommended sentry-side settings include pex = true, persistent_peers including the validator, and private_peer_ids including the validator node ID. For the full topology notes, see Validator Installation.