Solana Full Node: Complete Guide

What is a Solana full node?

A Solana full node runs validator software that verifies every block, keeps a local copy of the ledger and accounts state, and can expose JSON-RPC for wallets, indexers, and dApps. On Solana, operators usually distinguish voting validators from non-voting RPC nodes — both process the chain, but only validators participate in consensus.

RpcNode focuses on managed Solana Full Node RPC: HTTPS access to a synced node so you can call methods like getHealth, getSlot, getBalance, and sendTransaction without operating NVMe clusters yourself.

Why Solana full nodes matter

Every wallet balance, payment confirmation, and contract read ultimately depends on nodes that agree on Solana state. Public endpoints rate-limit and flake; your product’s reliability tracks the quality of the full nodes behind your RPC URL.

Solana in the RpcNode catalog: Solana.

• Native asset: SOL
• Environments: Mainnet, Testnet, Devnet, Localnet, Alpenglow Testnet
• API family: Solana JSON-RPC
• Listed in the RpcNode network catalog

When to run your own Solana node

Self-hosting a Solana full node makes sense when you need custom indexing, ultra-low latency next to your app, or compliance constraints that forbid third-party RPC. For most product teams, managed Full Node RPC is faster to ship and cheaper to operate.

• Building wallets, payments, or address watchers that need reliable Solana reads and writes
• Avoiding multi-terabyte disks, peer tuning, and 24/7 pager duty for chain upgrades
• Preferring HTTPS JSON-RPC with allowlists, keys, and usage metering
• Evaluating Solana before dedicating hardware — start on RpcNode, or self-host with Toolkit in a few clicks

Solana full node server requirements

Solana full node server requirements are among the highest in the catalog: a non-voting Agave RPC node needs many cores, large RAM, and fast NVMe — ideally separate volumes for ledger and accounts.

Do not size for an ultra-pruned “tiny ledger” profile if you want useful Full Node RPC depth. Budget 2+ TB NVMe and 256 GB+ RAM as a practical minimum for mainnet RPC.

Looking up "Solana server requirements", "Solana hardware requirements", or "Solana minimum specs"? Use the checklist below as the planning baseline for a self-hosted full node.

If you mainly need HTTPS Solana RPC for wallets or backends, prefer RpcNode managed Full Node RPC instead of sizing and babysitting this hardware yourself.

• CPU: 12+ cores, high clock (16–32+ common for busy RPC)
• RAM: 256 GB+ for comfortable RPC; more for heavy getProgramAccounts
• Disk: 2+ TB NVMe; prefer isolated ledger vs accounts mounts
• Bandwidth: 1 Gbps+ with open gossip / dynamic UDP ranges
• OS: Ubuntu 24.04 LTS; raise nofile / memlock for the operator user
• Role: non-voting RPC (`--no-voting`) — no validator voting keys required for RPC-only

Install a Solana full node in a few clicks

Solana is in the free RpcNode Toolkit catalog (mainnet, testnet, devnet, localnet). Skip the manual binary hunt: the self-hosted panel walks Add server → Add node → the node page.

On Linux (amd64/arm64) you install the host agent once, register the server, pick Solana and an environment, then the node page handles ports, install, snapshot when the chain supports it, sync, logs, and the public RPC endpoint.

1. Install the host agent on the Linux server (curl one-liner from rpcnode.dev).
2. Add server: paste IP and AGENT_API_TOKEN, Check connection, then add.
3. Add node: network Solana → environment (mainnet, testnet, devnet, localnet) → that server.
4. Open the node page — install, sync %, logs, restart, client update, fullnode RPC.

Self-host Solana with Toolkit

How to run a Solana full node

How to run a Solana full node for RPC: use Agave validator as a non-voting node with `--no-voting` and `--full-rpc-api`. Do not configure voting keys for an RPC-only host.

From Agave v3.0 onward, build `agave-validator` from source matching cluster `getVersion`. Prefer separate NVMe paths for ledger and accounts.

If you mainly need HTTPS Solana RPC for wallets or backends, prefer RpcNode managed Full Node RPC instead of sizing and babysitting this hardware yourself.

1. Provision Ubuntu 24.04 LTS (or the OS your client documents) on bare metal or a dedicated VM. Create a system user such as `nodeop` — do not run the node as root.
2. Attach 2+ TB NVMe — ideally `/mnt/nvme-ledger` and `/mnt/nvme-accounts`. Mount it away from the root filesystem and give ownership to the operator user.
3. Apply OS hygiene: unattended-upgrades or a patch cadence, fail2ban/SSH keys, and raise file-descriptor limits if the client docs require it.
4. Tune sysctl for large UDP buffers and `vm.max_map_count` / `fs.nr_open` as recommended for Solana operators.
5. Install build deps, Rust tooling for the operator user, and build Agave from the tag that matches mainnet-beta `getVersion`. Install `agave-validator` into the active release bin path.
6. Generate a local identity keypair for the node (identity only — not a voting authorized withdrawer setup for RPC-only).
7. Write a start script with `--no-voting`, `--full-rpc-api`, sensible `--limit-ledger-size` (not ultra-tiny), known validators / entrypoints, RPC bind `127.0.0.1:8899`, websocket `8900`, and gossip ports `8000-8026`.
8. Install a systemd unit (e.g. `solana-validator-mainnet`) running as `nodeop`, then enable it.
9. Firewall: open gossip/TVU/TPU `8000-8026` udp and `8000-8001` tcp publicly; whitelist RPC/WS only.
10. Verify with `solana catchup --our-localhost 8899` and JSON-RPC `getHealth` on `http://127.0.0.1:8899`.

• Key flags: `--no-voting --full-rpc-api` (RPC full node, not voting validator)
• Ports: 8000–8026 P2P; 8899 RPC; 8900 PubSub — RPC behind allowlists

Using Solana RPC without self-hosting

RpcNode exposes managed Solana JSON-RPC for Solana. Create an endpoint in the cabinet, restrict IPs if needed, and call the same methods your stack already uses.

Catalog environments for Solana: Mainnet, Testnet, Devnet, Localnet, Alpenglow Testnet. Create an endpoint in the RpcNode cabinet for the environment you need, or use this guide to plan a self-hosted deployment.

Typical methods teams start with: getHealth, getSlot, getBalance, getTransaction, sendTransaction.

Self-hosting vs managed Full Node RPC

Self-hosting gives maximum control and can reduce per-request cost at huge scale, but you own upgrades, peers, disk growth, and incident response. RpcNode Toolkit cuts the install to a few clicks (agent → Add server → Add node → node page) while you still run the hardware.

Managed RpcNode Full Node RPC trades that ops burden for a stable HTTPS endpoint, usage visibility, and the same method surface your SDK already speaks. If you are comparing providers, also see RpcNode’s comparison page.

Solana integration checklist

Use this short checklist when wiring Solana into production.

• Pick the correct environment (Mainnet, Testnet, Devnet, Localnet, Alpenglow Testnet) — never mix testnet keys with mainnet funds
• Store RPC URLs and keys in secrets management; rotate on staff changes
• Add IP allowlisting for server-side backends
• Alert on tip lag / getHealth (or equivalent) failures
• Load-test eth_getLogs / getProgramAccounts-style heavy calls before launch
• Decide full vs archive needs early — RpcNode is Full Node oriented
• Confirm Solana server requirements (CPU/RAM/disk) before self-hosting
• Or install with RpcNode Toolkit in a few clicks — free self-hosted panel

Solana full node FAQ