Self-hosting a Yellowstone Geyser gRPC node: hardware and setup

Yellowstone gRPC (also called "Dragon's Mouth") is the streaming interface most serious Solana traders, indexers, and RPC operators reach for when JSON-RPC polling is too slow or too expensive. This guide walks through what the plugin actually is, how to size hardware honestly, and the operational details that separate a node that works in a demo from one that survives mainnet load.

What Yellowstone Geyser gRPC actually is

As of June 2026, the rpcpool/yellowstone-grpc README describes Yellowstone gRPC as "a fully functional gRPC interface for Solana, built and maintained by Triton One," built around Solana's Geyser interface. In practice it is a plugin, not a separate service: it compiles to a dynamic shared library (a .so on Linux) that the validator loads at startup.

According to Triton One's 2026 streaming guide, the plugin registers callbacks directly with the node's AccountsDb and Bank. Data is captured in validator memory before it is written to disk, serialized to Protobuf, and pushed out over gRPC. That is the entire point: it bypasses the JSON-RPC HTTP layer, so you are reading state as the validator sees it rather than polling an endpoint after the fact.

You enable it by pointing the validator at the plugin's config file, for example solana-validator --geyser-plugin-config yellowstone-grpc-geyser/config.json (rpcpool README, as of June 2026). Because it runs inside a full Solana node, a Yellowstone node is fundamentally an RPC-class node plus extra streaming load, not a lightweight standalone process.

What it streams

As of June 2026, the rpcpool repo and its geyser.proto document the following subscription types: slots, accounts, transactions, blocks, blocks-meta, and entries, each available at processed, confirmed, or finalized commitment. Filtering is granular:

• Account filters: by account (Pubkey), by owner, or with getProgramAccounts-style filters (dataSize / Memcmp). An accounts_data_slice option lets you receive only byte ranges instead of full account data.
• Transaction filters: vote, failed, signature, account_include, account_exclude, and account_required.
• Unary helper methods: Ping, GetLatestBlockhash, GetBlockHeight, GetSlot, IsBlockhashValid, and GetVersion.

One caveat worth knowing before you build: according to the rpcpool repo, the deshred (pre-execution) subscription, SubscribeDeshred, is a Triton extension only. As of June 2026, the open-source server returns UNIMPLEMENTED for it; that implementation lives on the master-triton-ext branch. If pre-execution transaction streaming is the reason you are self-hosting, confirm which branch you are building.

The gRPC port and version compatibility

Port 10000 is a default, not a rule

As of June 2026, the example config in the rpcpool repo listens on "grpc": { "address": "0.0.0.0:10000" }, so port 10000 is the convention nearly everyone uses. QuickNode's guide uses the same YELLOWSTONE_PORT = 10000, and managed providers typically front it on TLS port 443. It is set in config, though, not fixed by the protocol, so you can change it. Plan your firewall and any load-balancer rules around whichever port you choose.

Match the plugin to your Agave version

This is the single most common self-hosting mistake. As of June 2026, the repo builds against agave-geyser-plugin-interface = "4.0.0" and solana-* crates in the 3.x to 4.x range (rpcpool Cargo.toml); treat that pin as an example at time of writing and check the current Cargo.toml for the version your build needs. The Geyser ABI is version-sensitive: the plugin .so must be compiled against the same Agave/Solana version as the validator that loads it. There is no published compatibility matrix, so the safe rule is to rebuild the plugin from source whenever you upgrade the validator, pinning to the matching interface crate. A mismatched .so can fail to load or, worse, behave unpredictably.

Hardware: start from the RPC baseline, then add headroom

There is no official, Geyser-specific hardware spec anywhere primary. The honest approach is to treat the node as a full RPC-class Solana node and then add headroom for streaming. The floor is Anza's (official Solana) published requirements.

Documented Anza baseline

As of June 2026, the Anza operations requirements page specifies:

• CPU: 2.8 GHz base or faster; AMD Gen 3 or newer, or Intel Ice Lake or newer; SHA extensions and AVX2 required. Anza explicitly notes that higher clock speed is preferable over more cores.
• RAM: a motherboard with 512 GB capacity is suggested, with ECC suggested.
• Storage: accounts NVMe 1 TB or more (high TBW), ledger NVMe 1 TB or more, snapshots 500 GB or more, PCIe Gen3 x4 NVMe or better. Anza recommends not sharing a disk between accounts and ledger due to high IOPS, and states RPC-class nodes (which a Geyser node is) should not share them.
• RPC uplift: for RPC-class nodes (which is what a Geyser node is), Anza recommends 16 cores / 32 threads or more, 512 GB or more RAM for account indexes, and a larger ledger disk for history.

Geyser-specific deltas (and what is uncertain)

As of June 2026, Triton One's streaming guide says it runs Yellowstone on dedicated "streaming-only" bare-metal nodes, separate from voting validators, "tuned specifically to handle the massive I/O load of streaming." That is a qualitative statement; Triton publishes no numeric Geyser spec. Various third-party 2026 validator guides (earnpark.com, everstake.one, thegoodshell.com) cite production figures of a 24-core CPU at 3.5 GHz or faster (AMD EPYC 9354/9355 are commonly mentioned), 384 to 512 GB ECC RAM, 2 TB or more of Gen4 high-IOPS NVMe, and 10 Gbps symmetric networking. Treat those as commonly repeated, not authoritative; they describe general validator/RPC builds, not a measured Geyser requirement.

The practical takeaway: plan above the RPC baseline on RAM (aim for 512 GB or more) and especially on network egress and CPU, because the plugin fans account and transaction state out to many subscribers. Exact NVMe IOPS and bandwidth numbers for Geyser specifically are not documented in any primary source, so size with margin rather than to a precise target.

How that maps to OrbitServers bare metal

OrbitServers recommends Solana RPC nodes at 192 GB or more RAM, 16 or more cores, and 2 TB or more NVMe, with bare metal starting at $299.99/mo. For a streaming node specifically, here is how the lineup lines up against the role:

CPU	Cores / clock	Best fit for a Yellowstone node
AMD EPYC 7763	64c / 128t, 2.45 GHz base / 3.5 GHz boost, 256 MB L3, 8-channel DDR4 ECC to 512 GB+	The closest match to a full RPC/streaming node: high core count and 512 GB+ RAM ceiling for account indexes and many concurrent subscribers.
AMD EPYC 4584PX	16c / 32t, 4.2 GHz base / 5.7 GHz boost, 128 MB 3D V-Cache L3, DDR5 ECC to 192 GB	Cache-sensitive workloads such as indexers and some RPC paths benefit from the large L3, within the 192 GB RAM ceiling.
AMD EPYC 4564P	16c / 32t, 4.5 GHz base / 5.4 GHz boost, 64 MB L3, DDR5 ECC to 192 GB	High-clock all-rounder for RPC and trading infrastructure where Anza's "clock over cores" guidance applies.
AMD Ryzen 9 9950X	16c / 32t, 4.3 GHz base / 5.7 GHz boost, 64 MB L3, DDR5 ECC to 192 GB	Highest single-thread clock, aimed at MEV/arbitrage send paths and trading bots rather than the streaming node itself.

Note the RAM ceilings: the single-socket DDR5 platforms top out at 192 GB, which meets OrbitServers' RPC sizing recommendation but sits below Anza's 512 GB suggestion for a busy RPC-class node. If you are aiming for the higher end of the third-party validator figures, the EPYC 7763 with its 512 GB+ DDR4 capacity is the platform that gets there. Every OrbitServers dedicated server ships with full root access, IPMI/KVM out-of-band management, a dedicated IPv4, and included DDoS protection, with up to 100 Gbps networking available. You can browse the full lineup on the bare metal hub or compare the role-specific builds on the RPC nodes and Solana validators pages.

Bandwidth is the heavy part

If one thing surprises operators self-hosting Yellowstone for the first time, it is data volume. As of June 2026, Triton One's Dragon's Mouth documentation gives a concrete example: the ZK Compression program produces roughly 10 MB per account-update blob, "resulting in several gigabits per second of data," which is why such high-volume programs are excluded from standard streams. There is no published aggregate GB/s figure for a full unfiltered mainnet firehose, so treat that ZK-compression number as an outlier datapoint that illustrates the ceiling rather than a typical load.

The config gives you levers to bound throughput and memory. As of June 2026, the repo's config.json defaults include channel_capacity at 100,000, snapshot_client_channel_capacity at 50,000,000, and max_decoding_message_size at 4 MB, with tokio.worker_threads set to 8 and CPU affinity pinning, plus gzip/zstd compression on both accept and send. Tune these to your subscriber count and the breadth of filters you allow.

Because egress dominates, the location and port matter as much as the CPU. OrbitServers' EU locations, Frankfurt and Amsterdam, include a 10 Gbps port with unlimited bandwidth, which is the cleaner fit for a high-fanout streaming node; see the unmetered 10 Gbps page for details. The US locations, New York and Salt Lake City, are metered with a generous transfer allowance rather than unlimited, so model your monthly egress before committing a firehose there. London rounds out the European edges. All of these are Jito-connected edges with low latency to Jito, which matters if the same infrastructure also feeds your trading bots or Solana trading stack.

Operating it: what differs from a plain RPC node

Separate the role

As of June 2026, Triton's documented practice is not to run Geyser streaming on a voting validator; use dedicated streaming nodes. The account-versus-ledger separate-NVMe recommendation from Anza still applies. If you also run validators, keep the streaming node on its own box rather than co-locating it with consensus duties.

Keepalives and idle streams

As of June 2026, the rpcpool README and Triton docs note that the server sends a Ping every 15 seconds, and clients should reply with the ping field (or send their own roughly every 30 seconds). This is not optional in production: load balancers such as Cloudflare and Fly.io drop idle gRPC streams, so missing keepalives show up as mysterious disconnects.

Known caveats and abuse controls

• Block reconstruction: as of June 2026, validator-generated blocks report entries = 0 (Solana issue #33823). The block_fail_action config defaults to log but can be set to panic if you would rather fail loudly.
• Filter limits: the config exposes filter_limits (max accounts/transactions/blocks per subscription) plus account_reject and owner_reject lists, so you can, for example, reject broadcasting the Token or System programs to protect your egress.
• Auth and TLS: the optional x_token auth and TLS settings are empty or null by default. Both must be set before you expose the node publicly.
• Client side: as of June 2026, QuickNode's guide warns that a single consumer CPU can be overwhelmed by a full-firehose stream and recommends Rust or Go clients, or Node.js cluster/worker for scaling consumption.

Why bother self-hosting at all

The payoff is latency and control. As of June 2026, Triton's own mainnet measurements (vendor-published, network-dependent, not independently verified) report slot updates at roughly p90 5 ms versus around 150 ms for RPC polling and about 10 ms for native WebSockets, and account updates at roughly p90 215 ms versus about 374 ms for native WebSockets, which Triton presents as a meaningful latency advantage over polling and native WebSockets. Your self-hosted numbers will depend on your hardware, filters, and network path, so treat those as directional. Self-hosting also gives you full control over filters, auth, and which programs you broadcast, instead of inheriting a managed provider's policies and rate limits.

A sensible reference build

If you want a starting point rather than a shopping list: a single dedicated bare-metal node at an EU Jito-connected edge, 512 GB-capable RAM where your subscriber count justifies it, separate NVMe for accounts and ledger, the plugin rebuilt against your exact Agave version, port 10000 behind a TLS terminator with x_token set, and conservative filter_limits until you understand your real egress. Start metered, watch the bandwidth, then move to an unlimited 10 Gbps port once you know your steady-state load.

OrbitServers is run by the same team behind the OrbitFlare Solana RPC service, and the bare-metal locations above are all Jito-connected edges built for exactly this kind of low-latency Solana infrastructure. If you are scoping a streaming node, validator, or trading stack, the bare metal, RPC nodes, and network pages are the right places to compare configurations before you deploy.