in-solana by Supanode

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)

ComponentMinimumRecommended
CPU24 cores / 48 threads (AMD EPYC 7443P or similar)32+ cores
RAM512 GB DDR4 ECC1 TB DDR5 ECC
Storage (ledger)2 TB NVMe PCIe Gen44 TB NVMe PCIe Gen5
Storage (accounts)2 TB NVMe PCIe Gen44 TB NVMe, separate drive
Network1 Gbps symmetric10 Gbps symmetric
OSUbuntu 22.04 LTSUbuntu 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

MetricRequirement
Bandwidth1 Gbps sustained, 10 Gbps burst
Monthly transfer30–100 TB
Latency to validators< 50ms to major clusters
Ports8000–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 --ledger and --accounts on 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

ItemOne-timeMonthly
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: