Running a Solana RPC node

It is the same binary with voting off and the full RPC API on, and that is where the similarity stops. An RPC node serves queries about history and accounts that a voting validator never answers, and it builds indexes a validator never builds. Sizing one from validator requirements is the single most common way to end up with a node that is permanently a few slots behind the cluster and cannot explain why.

• No vote account, no keys that matter. An RPC node has nothing to slash and nothing to lose but its own currency, which makes it a much less frightening thing to operate.
• It is more expensive, not less. More memory, more disk, more IO — see the requirements below.
• Which implementation you run is a consensus question, not an RPC one. Solana clients covers why: RPC is served by Agave components even when Firedancer is doing the networking.

Read the last sentence twice. It is the requirement most often treated as advice, and it is not a capacity statement — a single device that satisfies the combined size still fails on operations per second, and the node falls behind the cluster while every capacity graph looks fine.

The shape of the invocation, with the two flags that make it an RPC node and the two paths that must be on separate devices:

agave-validator \
  --no-voting \
  --full-rpc-api \
  --ledger  /mnt/ledger \
  --accounts /mnt/accounts \
  --rpc-port 8899 \
  --rpc-bind-address 127.0.0.1 \
  --private-rpc

--no-voting

No vote account, no duties, no penalties. This is what makes it an RPC node rather than a validator.

--full-rpc-api

Enables the methods an application actually wants — history and account queries — rather than the minimal set. It is also what makes the node expensive.

--rpc-bind-address 127.0.0.1

The same rule as every other chain: the RPC listener does not belong on a public interface. Exposing RPC without giving it away covers what goes in front of it.

Start from a snapshot rather than from genesis — on this chain that is not an optimisation but the only practical route — and expect the first catch-up to be IO-bound. Anza’s documentation is the authority on the current flags; the point of the shape above is which decisions exist, not which spelling is current.

Solana moves fast enough that “behind” is a different quantity here than on a twelve-second chain. A node two slots behind is a fraction of a second late; a node two hundred slots behind is serving state from a minute ago while answering every call successfully.

Slot distance from the cluster

Not from itself. Compare your node’s slot against an independent source, exactly as the observability article describes — a node that has stopped following the cluster reports itself perfectly healthy, because from inside, it is.

Which commitment you are asking for

Two healthy nodes legitimately disagree about the head when one answers at processed and another at confirmed. Every measurement on this site pins an explicit commitment for that reason, and your monitoring should too, or you will chase a lag that is a units mistake.

Disk, as a rate

The ledger grows continuously and the accounts database is rewritten constantly. Alert on days remaining at the current rate rather than on a percentage.

If this reads as more machine than you want to own, that is a reasonable conclusion. Getting a dedicated node works through the comparison honestly, and the Solana rankings measure what the public endpoints actually do in the meantime.