Self-Hosted vs Managed Solana RPC and Yellowstone gRPC

Running your own Solana RPC node, with Yellowstone gRPC on top, gives you full control and no shared limits. It also makes you the operator of a machine that has to keep pace with mainnet, take upgrades often and fail over when it falls behind. This post covers what self-hosting involves, what it buys you and what it doesn't, with a starting configuration.

Disclosure: AllenHark sells managed RPC, Yellowstone gRPC and servers. Facts about running a node come from Anza's Agave docs and source code and from the Yellowstone gRPC repository, linked under Sources and checked November 2, 2026.

The short answer

• Self-host when you need what only your own node gives: a custom Geyser plugin, account indexes you choose, a client version you control, or your bot and node on one machine. Plan for two nodes and someone on call.
• Managed, shared when you're building, testing, or running a bot whose traffic fits a plan's limits.
• Managed, dedicated when shared limits get in the way but you don't want to run the node.
• Co-location when your bot is latency-sensitive: rent a server in the same city as the endpoints you read from, or run your own node on it.

Whichever you pick, the node you read from is not a fast way to send transactions. More on that below.

What an RPC node is

An RPC node runs the same software as a validator (Anza's Agave client, in this post) but doesn't vote (--no-voting). Per Anza's docs it needs no vote account and earns no rewards, and running RPC on a voting validator is "strongly discouraged because your node will not be performant enough to do either task well." It follows the chain like any validator, answers JSON-RPC and WebSocket calls, and forwards the transactions you send it.

Yellowstone gRPC is a Geyser plugin: a shared library the validator loads at startup through --geyser-plugin-config, which streams accounts, transactions, slots and blocks to subscribers. Self-hosting gRPC means self-hosting an RPC node and the plugin together.

Anza also warns that the RPC service "is NOT intended to be directly exposed to the public internet". Keep it behind your own firewall.

Hardware: what Anza recommends

Anza gives these figures "as a guide" and encourages operators to do their own performance testing. The RPC column is in addition to the validator column.

The same page says Anza builds and runs on Ubuntu 24.04, that cloud virtual machines need "significantly greater operational expertise", and that Docker is not recommended for live clusters. Open TCP and UDP ports 8000 to 8030 for gossip, Turbine and repair (--dynamic-port-range can narrow the range), and avoid NAT.

What self-hosting involves

First sync: a snapshot, then catch-up

A new node has no state. It downloads a snapshot from the validators you name with --known-validator, loads it, then replays what the cluster did in the meantime: "by the time you receive the snapshot, you may already be behind the network," Anza notes. solana catchup shows how far behind you are and how fast you're closing the gap, and --minimal-snapshot-download-speed switches to another known validator if a download is slow.

Anza publishes no sync time; it depends on your hardware, network and snapshot source, so time it on your own machines. Once a node has local state, keep it: restart with --no-snapshot-fetch, and fetch a new snapshot only after prolonged downtime or when the node keeps falling behind.

Upgrades, and a plugin that has to match

"As an operator, you will need to upgrade often," says Anza. Agave cuts a new stabilization branch about every 13 weeks, with patch releases in between; v4.4.0, released October 28, 2026, is the "stable release recommended for general adoption". You can build a new version while the node runs, then restart into it with agave-validator exit.

The Yellowstone plugin makes each upgrade a two-part job. It is compiled Rust running inside the validator process, and each release names the Agave version it was built for: v16.2.0+solana.4.3.2 (October 30) pins the Agave 4.3.2 crates and Rust 1.97.1. Agave 4.4.0 moved to version 5.0.0 of the Geyser plugin interface crate and to Rust 1.98.1. On November 2 the newest Yellowstone release was still the 4.3.2 build; builds for 4.4.0 existed only as release-candidate tags such as v17.0.0-rc9+solana.4.4.0. Neither project's docs state a compatibility rule, but the tags make the pairing explicit. Treat validator and plugin as one unit: upgrade them together, build the plugin from the tag that names your Agave version, and run the pair on a spare node first.

If you write your own plugin, note that Agave 4.3.0 deprecated update_account, notify_transaction, notify_entry and notify_block_metadata, "slated for removal in the next major release", in favour of bank-scoped methods.

Monitoring and alerting

"It is essential that you have monitoring in place," says Anza. For a voting validator that means agave-watchtower watching for delinquency. An RPC node doesn't vote, so watch what your bot feels: getHealth reports healthy while the node is within a set distance of the cluster (128 slots by default in Agave 4.4.0, set with --health-check-slot-distance), and comparing its slot with a second source catches smaller lags. Add disk space, disk wear, memory and the plugin's Prometheus metrics, and run the monitor on another machine, as Anza advises for watchtower: a monitor on the same box goes down with it.

Falling behind under load

An RPC node keeps up with the chain and answers your calls with the same hardware. Anza's Geyser page says validators "under heavy RPC loads, such as when serving getProgramAccounts calls, can fall behind the network", and that a slow plugin does the same: "any delay may cause the validator to fall behind the network". A node that falls behind serves stale data until it catches up.

getProgramAccounts and SPL Token queries scan the whole account set unless you build in-memory indexes with --account-index (program-id, spl-token-owner, spl-token-mint). Anza's 512 GB figure for RPC nodes is for all of them. If you only query a few programs or owners, --account-index-include-key limits an index to the keys you name.

Ledger history

An RPC node doesn't keep the whole chain. --limit-ledger-size caps what it stores; Agave 4.3.0 deprecated that flag in favour of --limit-blockstore-size, which counts more precisely. In Agave 4.4.0, getBlock, getTransaction and getSignaturesForAddress return an error unless the node runs with --enable-rpc-transaction-history, which its help text says "will cause an increase in disk usage and IOPS". History older than your ledger needs an external store; Anza's RPC node page points to a Solana Bigtable instance.

Failover: one node is not a service

Every upgrade is a restart, every restart means loading state and catching up, and a node that falls too far behind may need a new snapshot. Meanwhile a single node serves nothing, or stale data. For uptime you need a second node and a way to switch: a health-checked load balancer in front of both, or client code that fails over on getHealth and slot lag. Upgrade one node at a time.

What you gain

• Control. Your flags, indexes, client version and upgrade timing.
• No shared rate limits. The limits are your hardware's, plus any Yellowstone filter_limits you set.
• Custom plugins and indexes. Anza's Geyser page describes sending chain data to "relational databases, NoSQL databases or Kafka". Only your own node will load your plugin.
• Your bot on the same box. With --private-rpc and no --rpc-bind-address, Agave binds RPC to 127.0.0.1. Bind the plugin there too, and the bot's calls and stream never leave the machine.
• Your own replay window. The plugin's replay_stored_slots sets how far back from_slot reaches: 150 slots by default (about 30 seconds at today's slot time of about 200 ms), with a logged warning below 150; the sample config's 0 turns replay off.

What it doesn't give you: a fast send path

sendTransaction on your own node forwards to upcoming leaders over QUIC under the node's own identity. Unless that identity has stake, or a staked validator lists it with --staked-nodes-overrides and you point --rpc-send-transaction-tpu-peer at that validator, the connection is unstaked, and unstaked traffic is throttled first when a leader is busy. SWQoS vs Jito vs a relay explains why and what to use instead.

Early data is similar: the open-source Yellowstone plugin returns UNIMPLEMENTED for SubscribeDeshred. For transactions before execution, read shreds.

What it costs: the parts, not the prices

No figures here; they depend on your region, your provider and your team. The parts:

• Servers. At least two machines that meet the RPC column, rented, or bought and racked.
• Disks. High-TBW NVMe for accounts, ledger and snapshots, and replacements as they wear.
• Bandwidth. A symmetric link for each node, including snapshot downloads and catch-up.
• A monitoring machine. Separate from the nodes.
• History storage. A larger ledger disk, or Bigtable, if you need old blocks and transactions.
• Engineer time. Upgrades, plugin rebuilds and their testing, resyncs, alerts at any hour, and cover for holidays.
• A staging node. Somewhere to test each Agave and Yellowstone pair before production.

Which one fits

A minimal self-hosted setup

This is a starting point, not a tuned config. It is Anza's mainnet example turned into an RPC node with the flags from Anza's RPC node page (--no-voting, --full-rpc-api for every RPC method, --private-rpc), plus history, account indexes and the Yellowstone plugin. Every flag was checked against the agave-validator 4.4.0 source; nothing here was benchmarked.

The validator

#!/bin/bash
# validator.sh: a mainnet RPC node with Yellowstone gRPC. A starting point, not a tuned config.
# Based on Anza's mainnet example and RPC node page; flags checked against agave-validator 4.4.0.
exec agave-validator \
    --identity /home/sol/rpc-identity.json \
    --known-validator 7Np41oeYqPefeNQEHSv1UDhYrehxin3NStELsSKCT4K2 \
    --known-validator GdnSyH3YtwcxFvQrVVJMm1JhTS4QVX7MFsX56uJLUfiZ \
    --known-validator DE1bawNcRJB9rVm3buyMVfr8mBEoyyu73NBovf2oXJsJ \
    --known-validator CakcnaRDHka2gXyfbEd2d3xsvkJkqsLw2akB3zsN1D2S \
    --only-known-rpc \
    --entrypoint entrypoint.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint2.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint3.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint4.mainnet-beta.solana.com:8001 \
    --entrypoint entrypoint5.mainnet-beta.solana.com:8001 \
    --expected-genesis-hash 5eykt4UsFv8P8NJdTREpY1vzqKqZKvdpKuc147dw2N9d \
    --no-voting \
    --full-rpc-api \
    --private-rpc \
    --rpc-port 8899 \
    --rpc-bind-address 127.0.0.1 \
    --enable-rpc-transaction-history \
    --account-index program-id \
    --account-index spl-token-owner \
    --account-index spl-token-mint \
    --ledger /mnt/ledger \
    --accounts /mnt/accounts \
    --snapshots /mnt/snapshots \
    --log /home/sol/agave-rpc.log \
    --dynamic-port-range 8000-8020 \
    --wal-recovery-mode skip_any_corrupted_record \
    --limit-blockstore-size \
    --geyser-plugin-config /home/sol/yellowstone/config.json

• Identity, no vote account. solana-keygen new -o rpc-identity.json makes the identity; an RPC node needs no vote account.
• Known validators. The four keys Anza lists for mainnet, all operated by Anza; --only-known-rpc uses only their RPC services at startup.
• --private-rpc and --rpc-bind-address. The RPC port isn't published in gossip, and 127.0.0.1 is already the default with --private-rpc. If your bot runs on another machine, bind a private address, never a public one.
• --enable-rpc-transaction-history. Needed for getBlock, getTransaction and getSignaturesForAddress; leave it out if you never call them.
• --account-index. Drop the indexes you don't query: each one costs RAM.
• Disks and ledger size. Accounts, ledger and snapshots on separate NVMe drives, as in Anza's table. Anza's examples still use --limit-ledger-size; on 4.3 and later, --limit-blockstore-size with no value keeps the default limit.
• systemd. Run it as a service, as the non-root sol user, with the file limits from Anza's validator setup page.

The Yellowstone plugin config

{
  "libpath": "/home/sol/yellowstone-grpc/target/release/libyellowstone_grpc_geyser.so",
  "log": { "level": "info" },
  "grpc": {
    "listen": [{ "address": "127.0.0.1:10000" }],
    "x_token": "replace-with-a-long-random-string",
    "replay_stored_slots": 150,
    "filter_limits": {
      "accounts": { "any": false },
      "transactions": { "any": false }
    }
  },
  "prometheus": { "address": "127.0.0.1:8999" }
}

• Build. Check out the release tag whose +solana. suffix matches your Agave version, build it in release mode with the Rust version its release notes name, and point libpath at the library in target/release/.
• Check. The README's cargo run --bin config-check -- --config with your file's path validates the config before the validator loads it; unknown fields are rejected.
• listen. Replaces the deprecated grpc.address. Each listener can add tls and an auth mode; on any address other than 127.0.0.1, add TLS.
• x_token. Every connection must send this value in the x-token header, or gets "No valid auth token".
• filter_limits. With any false, a client can't subscribe to every account or transaction with an empty filter. Leave the section out and there are no limits.

The validator loads the file through --geyser-plugin-config, as in the script. Upstream's sample config shows the other options, from compression and channel capacities to thread affinity.

Alpenglow and your node

Alpenglow went live on mainnet on October 21, 2026; what it changed for RPC and gRPC users covers commitment levels and bank_id in detail. For someone running the node:

• Votes are no longer transactions. Validators send votes to each other and aggregate them into certificates. Agave 4.3.0 lets unstaked nodes "receive consensus messages via votor from any staked node".
• Geyser is bank-aware. Agave 4.3.0 added Geyser methods that carry bank_id, and the Yellowstone plugin streams it, so a client can tell two candidate blocks for one slot apart. One more reason to keep plugin and validator matched.

Managed RPC, gRPC and servers at AllenHark

If you'd rather not run the node, or want your own server next to ours:

• Solana RPC. JSON-RPC and WebSocket in Frankfurt or Amsterdam, from an allowlisted IP address or with an API key. Standard RPC allows 100 requests per second, and the docs limit getProgramAccounts and getSignaturesForAddress to 30 calls per 60 seconds per IP. Dedicated RPC has no rate limits. As on a self-hosted node, sendTransaction "is forwarded to the node as is; nothing is staked or prioritised", so send through AllenHark Relay, which lands transactions in the same block, at 0.1 ms over QUIC.
• Yellowstone gRPC. Frankfurt or Amsterdam, by allowlisted IP or an API key sent as x-token (new subscriptions). from_slot replays about 48 hours, and streams carry Alpenglow's bank_id. On Standard, a connection is one Subscribe stream with 500 accounts per subscription; Dedicated gRPC has no rate limits and no account limit. Setup is in the gRPC docs.
• Co-location. Single-tenant AMD bare metal, listed in Frankfurt, Amsterdam and Chicago when we checked, and cloud VPS, paid monthly in USDC, USDT or SOL. The Frankfurt page puts its servers beside AllenHark's own ShredStream, gRPC and RPC endpoints and says to check a build's memory and NVMe "against the current validator requirements" before running a node on it. It gives no latency figures for the servers: measure from the box.
• Managed validator. A voting validator run for you under your name, with a 99.9% uptime SLA, on dedicated bare metal in Frankfurt or Amsterdam. It's for staking businesses, not a replacement for an RPC node.

Plans and prices are on the pricing page.

FAQ

What hardware does a Solana RPC node need?

Per Anza: 16 cores / 32 threads or more at 2.8 GHz or faster, 512 GB or more of RAM for all account indexes, separate NVMe drives for accounts, ledger and snapshots, and a public IPv4 address on a 1 Gbit/s symmetric link. Anza calls these a guide; test your own build.

Is a dedicated RPC node the same as self-hosting?

No. A dedicated plan is still managed: the provider runs, upgrades and resyncs the node, and you get it without shared limits. AllenHark Dedicated RPC and Dedicated gRPC have no rate limits. Self-hosting means all of that is your job.

Do I have to rebuild Yellowstone gRPC after every Agave upgrade?

Plan on it. Each Yellowstone release is built for one Agave version and says which in its tag, so upgrade the plugin with the validator and test the pair before production.

Will my own RPC node land transactions faster?

Not by itself. Its sendTransaction goes out over an unstaked connection unless its identity has stake or a staked validator peers with it. Use a relay or a staked path to send.

Can my validator also be my RPC node?

Anza strongly discourages it: one node "will not be performant enough to do either task well."

Related reading

• Best Yellowstone gRPC providers in 2026
• Alpenglow: what Solana RPC and gRPC users need to change
• Why your Yellowstone gRPC stream lags or misses events
• Reconnect Yellowstone gRPC without missing transactions
• SWQoS vs Jito vs a relay: which Solana sender to use

Sources

Checked November 2, 2026.

• Anza, Agave docs: validator requirements (hardware, network, OS, cloud, Docker, firewall), setup an RPC node (flags, public-internet warning, Bigtable, account indexes), setup a validator (disks, system tuning, catch-up), best practices (upgrades, snapshots), monitoring, available clusters (mainnet example and known validators), Geyser plugins, what is an RPC node and validator or RPC node.
• Agave on GitHub: releases (v4.4.0, October 28, 2026), RELEASE.md (branch cadence), CHANGELOG (4.3.0 and 4.4.0 changes), run arguments, RPC arguments, blockstore arguments, rpc.rs (history check), Cargo.toml and rust-toolchain.toml.
• Solana docs, getHealth.
• Yellowstone gRPC: README (config, auth, filter limits, SubscribeDeshred), releases, CHANGELOG, and at the v16.2.0+solana.4.3.2 tag: config.rs, grpc.rs and Cargo.toml.
• AllenHark: RPC and RPC docs, gRPC and gRPC docs, co-location, bare metal in Frankfurt, managed validator, Relay.