Running Your Own Solana RPC Node
TL;DR
- - Minimum: 24 cores, 512 GB RAM, 2 TB NVMe — roughly $3,000–$8,000 in hardware
- - Ongoing costs: bandwidth ($200–$800/mo), colocation ($200–$500/mo), ops time
- - Consider managed dedicated nodes if you lack ops capacity for ongoing maintenance
Running your own Solana RPC node gives you maximum control over performance, data retention, and configuration. It also requires significant hardware investment and ongoing operational effort. This guide covers the requirements, costs, and tradeoffs.
Hardware requirements
Solana’s RPC node requirements are substantial compared to most blockchain networks. The node must keep pace with the network’s high throughput in real time.
Minimum specifications (as of 2026-10-21)
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 24 cores / 48 threads (AMD EPYC 7443P or similar) | 32+ cores |
| RAM | 512 GB DDR4 ECC | 1 TB DDR5 ECC |
| Storage (ledger) | 2 TB NVMe PCIe Gen4 | 4 TB NVMe PCIe Gen5 |
| Storage (accounts) | 2 TB NVMe PCIe Gen4 | 4 TB NVMe, separate drive |
| Network | 1 Gbps symmetric | 10 Gbps symmetric |
| OS | Ubuntu 22.04 LTS | Ubuntu 22.04 or 24.04 LTS |
Why so much RAM?
Solana stores the accounts database in memory-mapped files. The active account set is hundreds of gigabytes. With insufficient RAM, the OS pages to disk constantly, and the node falls behind the network.
Why NVMe?
The ledger grows at several GB per hour. Standard SSDs cannot sustain the write throughput. NVMe drives with high sustained write speeds (2+ GB/s) are required. Use enterprise-grade drives rated for high write endurance (DWPD ≥ 1).
Network requirements
| Metric | Requirement |
|---|---|
| Bandwidth | 1 Gbps sustained, 10 Gbps burst |
| Monthly transfer | 30–100 TB |
| Latency to validators | < 50ms to major clusters |
| Ports | 8000–8020 (QUIC/UDP), 8899 (RPC), 8900 (WebSocket) |
Solana’s gossip protocol and block propagation consume significant bandwidth. Running in a data center with good peering to other validators is important for staying synced.
Setup steps
1. Install the Solana CLI
sh -c "$(curl -sSfL https://release.anza.xyz/stable/install)"
export PATH="$HOME/.local/share/solana/install/active_release/bin:$PATH"
2. Generate an identity keypair
solana-keygen new -o ~/validator-keypair.json
This is the node’s identity on the network (not a voting or staking keypair for an RPC-only node).
3. Configure the validator
Create a startup script:
#!/bin/bash
solana-validator \
--identity ~/validator-keypair.json \
--no-voting \
--known-validator dv1ZAGvdsz5hHLwWXsVnM94hWf1pjbKVau1QVkaMJ92 \
--known-validator dv2eQHeP4RFrJZ6UeiZWoc3XTtmtZCUKxxCApCDcRNV \
--known-validator dv4ACNkpYPcE3aKmYDqZm9G5EB3J4MRoeE7WNDRBVJB \
--entrypoint entrypoint.mainnet-beta.solana.com:8001 \
--entrypoint entrypoint2.mainnet-beta.solana.com:8001 \
--rpc-port 8899 \
--full-rpc-api \
--no-os-network-limits-test \
--ledger ~/solana-ledger \
--accounts ~/solana-accounts \
--limit-ledger-size 200000000 \
--log ~/solana-rpc.log
Key flags:
--no-voting: RPC-only mode, no voting or block production.--full-rpc-api: enable all RPC methods including heavy ones.--limit-ledger-size: limit ledger retention in shreds (adjust for your storage).- Separate
--ledgerand--accountson different NVMe drives for better I/O.
4. Download a snapshot
Starting from genesis takes days. Download a recent snapshot:
solana-validator \
--identity ~/validator-keypair.json \
--no-voting \
--entrypoint entrypoint.mainnet-beta.solana.com:8001 \
--expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \
--wal-recovery-mode skip_any_corrupted_record \
--limit-ledger-size \
--ledger ~/solana-ledger
Snapshot download takes 30–60 minutes depending on bandwidth. Catching up from the snapshot to the current slot takes additional time.
5. Verify the node is synced
solana catchup ~/validator-keypair.json --our-localhost
The node is healthy when the slot delta reaches 0.
Operational considerations
Monitoring
Monitor these metrics continuously:
- Slot delta: how far behind the network the node is.
- CPU usage: sustained > 80% indicates the node may fall behind.
- RAM usage: page faults indicate insufficient memory.
- Disk I/O: high latency indicates storage bottleneck.
- RPC response times: baseline and track p50/p95/p99.
Updates
The Solana software (Agave) releases updates regularly. Some are required (breaking changes with feature gates), others are recommended. Monitor:
- Anza Discord announcements.
- GitHub releases at
anza-xyz/agave. - Testnet feature activation schedule.
Ledger management
The ledger grows continuously. Without --limit-ledger-size, it fills the disk. Monitor disk usage and adjust retention as needed. For archive access, configure Bigtable export.
Cost summary
| Item | One-time | Monthly |
|---|---|---|
| Hardware (server) | $3,000–$8,000 | — |
| Colocation | — | $200–$500 |
| Bandwidth (30–100 TB) | — | $200–$800 |
| Electricity | — | $50–$150 |
| Ops time (monitoring, updates) | — | 5–20 hours |
| Total | $3,000–$8,000 | $450–$1,450 + ops |
Compare to managed dedicated: $500–$5,000/month with no hardware cost and no ops burden.
FAQ
Can I run an RPC node on a cloud VM? Yes, but it is more expensive than bare metal for the same specs. A 512 GB RAM cloud instance costs $2,000–$5,000/month. NVMe performance on cloud VMs also varies. Bare metal or dedicated server hosting is more cost-effective for production.
How long does initial sync take? With a snapshot download: 30–60 minutes to download, then 30–120 minutes to catch up to the current slot. From genesis: several days.
Can I run an RPC node at home? Technically possible with a fiber connection, but residential internet typically has insufficient upload bandwidth and the node consumes significant electricity. Data center hosting is recommended.
Do I need to stake SOL to run an RPC node?
No. An RPC-only node (--no-voting) does not need stake. However, staking provides SWQoS bandwidth for transaction forwarding. Running with stake is recommended if you use the node to send transactions.
Updated: