Running your own Solana node: infrastructure for MEV and trading

Running a Solana node yourself has historically been a commitment. Agave (the Anza-maintained successor to the original Solana Labs validator client) isn’t exotic software, but it is demanding software. Official hardware guidance calls for 256–512 GB of ECC RAM depending on whether account indexing is enabled, accounts and ledger split across separate high-endurance NVMe drives because their I/O patterns are incompatible — ledger writes are sequential and append-only, account access is heavy random I/O — and a CPU chosen for clock speed over core count. Get any of that wrong and Solana doesn’t degrade gracefully: a node that falls behind the network’s ~400ms slot cadence falls behind and stays behind, since there’s no cheap way to catch up on a chain that never stops producing blocks. Teams handling trade execution, custody, or settlement on Solana took on that hardware and operations burden because they had to — the value of direct, low-latency access to chain state outweighed the DevOps cost. Teams without those requirements didn’t.

The operational math has shifted. What made running a Solana node hard was rarely Agave itself — it’s a mature, actively developed client with years of mainnet hardening behind it. The hard part was everything around the node: hardware sizing, snapshot bootstrap, monitoring, upgrades, failover. Chainstack Self-Hosted now supports Solana Mainnet and Devnet, which means that operational layer becomes software you consume rather than a stack you build.

This piece is about who actually benefits from a Solana node on their own infrastructure, what running one looks like day-to-day, and how the newer answer compares to the older one.

Why running a Solana node used to be a project

Agave is the reference implementation validators and RPC operators run to serve the network. It’s what exchanges, market makers, and DeFi protocols on Solana all run under the hood in some form. When you run your own node, you get the same feature set they do:

• The full Agave JSON-RPC surface against your own state — account data, program state, transaction and block history, slot and epoch info — with no rate-limit ceiling beyond your own hardware.
• WebSocket subscriptions for real-time account, program, signature, and slot updates. No polling loop guessing when state changed.
• Direct transaction submission with full control over compute unit pricing and priority fees. Solana doesn’t have a persistent, chain-wide mempool the way Bitcoin or Ethereum do — transactions are forwarded straight into the current slot leader’s incoming queue — so submitting from your own node means you control that forwarding path instead of depending on someone else’s.
• Independent verification of balances and program state. For anyone holding customer SOL or SPL tokens, or settling against on-chain state, the answer to “how do you verify this?” is “we query our own node.” Everything else is trust in a third party.

Unlocking that feature set on your own infrastructure meant building the ops layer around Agave yourself: sourcing hardware sized for hundreds of gigabytes of RAM and multiple NVMe drives, bootstrapping from a snapshot (attempting a genesis replay is not something anyone does in practice — the ledger is too large and the replay too slow to be worth it), standing up monitoring tight enough to catch drift within a slot or two, and planning for Agave’s frequent version cadence. That’s the setup burden this article is really about. The teams that took it on did so for very specific reasons — worth naming, because they’re where the case for a self-hosted Solana node actually lives.

Who actually runs their own Solana node, and why

• Market makers and MEV/priority-execution infrastructure. Jito Labs built the dominant MEV and priority-fee infrastructure layer on Solana. Its Block Assembly Marketplace (BAM) reached roughly a third of Solana’s stake-weighted network share by Q2 2026, per Solana Foundation data. Firms competing on transaction ordering and inclusion at that layer need direct, low-latency access to leader schedules and priority-fee markets — routing that through a shared, rate-limited RPC tier defeats the point.
• Exchanges and custodians. Coinbase runs its own Solana validator infrastructure at real scale: 23 validators across two independent bare-metal providers, staking 41.63 million SOL — about 9.72% of all staked SOL — on a multi-client setup spanning Firedancer, Jito, JitoBAM, and Harmonic, as of its Q2 2026 validator performance report. Exchanges processing SOL and SPL-token deposits and withdrawals at that volume need independent balance verification and rate limits that don’t buckle during a busy window — an auditor doesn’t accept “we trust a third-party explorer” as an answer.
• DeFi protocols and DEX aggregators. Jupiter, Solana’s dominant swap aggregator, handles over 90% of aggregator volume and roughly half of all Solana DEX trading volume, several billion dollars a day in 2026. Raydium and Orca sit underneath that flow as the AMMs doing the actual settlement. At that scale, application logic that depends on real-time account and program state can’t tolerate a shared provider’s latency or rate-limit envelope — a stale price feed or a delayed confirmation is a direct PnL problem.
• Stablecoin and payments platforms. Circle minted over $64 billion of USDC on Solana during 2026 alone (gross issuance, not standing circulating supply). Platforms settling USDC and other SPL-token transfers at that volume verify balances against their own node rather than a third-party balance API, for the same reasons a TRON or Ethereum stablecoin processor does.
• Compliance and analytics platforms. Chainalysis and Elliptic run Solana infrastructure for transaction tracing and monitoring, the same way they do for every major chain they cover. Serving chain data as a compliance product means needing full, direct, and redundant access to it.

At a glance:

Audience	Use case	What running your own unlocks	Examples
Market makers & MEV infra	Priority transaction execution and inclusion	Low-latency leader access, priority-fee control, no shared rate limits	Jito Labs
Exchanges & custodians	Custody SOL/SPL, process deposits & withdrawals	Independent balance verification, audit-grade infrastructure control	Coinbase
DeFi protocols & DEX aggregators	High-volume swap routing and on-chain logic	Real-time account/program state without shared-tier latency	Jupiter, Raydium, Orca
Stablecoin & payments platforms	Settle USDC and SPL-token transfers	Independent verification of balances and transfers	Circle-issued USDC on Solana
Compliance & analytics	Transaction tracing and monitoring	Full, direct, redundant chain access	Chainalysis, Elliptic

The pattern across all of these: when Solana data is load-bearing for your business — trade execution, custody, settlement, compliance — you don’t rent it.

What running your own actually costs

The operational reality is heavier than most chains on this platform, and the costs are specific enough to plan around rather than guess at.

• Initial sync. Syncing a Solana node from genesis isn’t something operators attempt in practice — replaying the full transaction history and rebuilding state from block zero is untenable given how large and fast-growing the ledger is. Snapshot-based bootstrap is close to mandatory: you download a recent verified state and catch up to the chain head from there, typically in minutes to a few hours depending on snapshot size and network conditions, rather than the days a genesis replay would take.
• Storage growth. An unpruned Solana ledger has passed 400 TB and grows on the order of 80–95 TB a year — nobody runs that. Production nodes run pruned, keeping a rolling window of recent state and history, which is why a properly sized Mainnet RPC deployment lands around 3–4 TB rather than in the hundreds. NVMe is not optional here: Solana’s write pressure will bottleneck SATA SSDs and make rotational storage unusable.
• Updates. Agave ships on an aggressive cadence — roughly a six-week major release rhythm from Anza, with the gap between minor versions now under three months. New protocol behavior activates through feature gates that require a supermajority (roughly two-thirds) of stake to adopt before turning on; for minor-version floors specifically, the network raises the required version two epochs after 95% of stake has moved to it. Fall behind that curve and you risk running an incompatible client right as an activation crosses the line, not a slow drift you can fix at leisure.
• Monitoring and reliability. Solana’s slot cadence runs at roughly 400ms today, with a feature-gated path to 200ms shipped in Agave 4.2 once the network activates it. A node that’s a few slots behind on a chain moving that fast isn’t in a mild degraded state — it’s on its way to being functionally useless for anything latency-sensitive, and it stays that way without a snapshot re-bootstrap. Solana is less forgiving of undersized infrastructure than most chains: undersize the hardware and a node doesn’t slow down gracefully, it falls behind and stays behind.
• The “set it and forget it” myth. Plenty of Agave nodes do run for stretches without intervention. They also fall off the pace the moment a peer connection degrades, a disk fills up, or a mandatory version bump passes, and unlike a chain with a multi-minute block time, there’s very little slack to notice and recover before the gap compounds. For evaluation or low-stakes use, that’s tolerable. For anything trade- or settlement-adjacent, it’s a quiet path to a broken Saturday.

What changed: Chainstack Self-Hosted now supports Solana

The historical reason teams reached for managed RPC over self-hosting Solana wasn’t that they preferred managed RPC — it was that sourcing and correctly sizing Solana-grade hardware, then building the snapshot, monitoring, and upgrade discipline around it, was too much operational overhead to justify unless the workload demanded it.

Chainstack Self-Hosted is what happens when you separate “own the node” from “build the operational stack around it.” Self-Hosted now supports Solana on Agave v4.2.0, running non-voting RPC nodes on both Mainnet and Devnet, with the same deployment workflow as the rest of the platform: pick the protocol, pick the network, deploy (Supported deployments). Full rollout details are in the announcement.

Hardware sizing reflects Solana’s real appetite. Mainnet takes 16 vCPU, 256 GiB of RAM, and roughly 3.5 TB of storage; Devnet takes 8 vCPU, 64 GiB of RAM, and roughly 2.2 TB (System requirements). Both networks bootstrap from a pre-built snapshot rather than syncing from genesis — unlike TRON and Bitcoin on this platform, there’s no multi-day genesis sync to plan for on Solana. Provision for roughly 2× the steady-state storage figure during the deploy itself, since the compressed snapshot archive and the extracted state briefly coexist on disk before cleanup.

The exposed endpoint is Agave’s standard HTTP JSON-RPC on port 8899, plus WebSocket JSON-RPC on port 8900 — the same interface every Solana SDK and RPC client speaks (Supported deployments).

• Snapshot-based bootstrap ships for both Mainnet and Devnet out of the box — you’re not doing a genesis sync on either network, which is a meaningfully better starting position than TRON or Bitcoin get on this platform today.
• What you get is Kubernetes-level self-healing: if the node pod crashes, the deployment automatically restarts it and resumes from its last state on the persistent volume.
• Agave version upgrades still require you to redeploy the node on the new client version yourself — Self-Hosted doesn’t currently auto-update client versions for you, and given Agave’s release cadence, that’s a more frequent chore on Solana than on most other protocols here.
• Multi-endpoint failover to a Chainstack-managed Solana endpoint is planned but not yet shipped, the same status it has across the rest of Self-Hosted (Self-Hosted FAQ).
• Only non-voting RPC nodes ship today. Validator support is explicitly on the roadmap but not expected before late 2026, pending Chainstack’s approach to uptime guarantees, slashing protection, and key management (Self-Hosted FAQ).
• You still own the node. The data never leaves your perimeter. You can point any Agave-compatible RPC client at it and query it like any other Solana JSON-RPC endpoint. The difference is you didn’t build the snapshot, deployment, and monitoring stack around it yourself.

When to self-host Solana, and when not to

The decision isn’t religious. It’s a workload question.

Run your own Solana node if:

• Your application makes more than a few hundred thousand RPC calls a day. Managed RPC pricing scales with call volume; your own node runs at a flat hardware cost regardless of throughput.
• You’re executing trades, routing swaps, or running MEV-adjacent infrastructure where latency to the current leader directly affects outcomes.
• You custody SOL or SPL-token assets at exchange or institutional scale and need independently verifiable balances.
• You’re building a DeFi protocol, indexer, or analytics platform whose logic depends on real-time account or program state.
• Compliance, audit, or regulatory frameworks require infrastructure control over how you access and verify chain data.

Reach for managed Chainstack Solana instead if:

• You want to avoid the hardware cost and upfront commitment of Solana-grade infrastructure. 256+ GB of RAM and multi-NVMe storage is real capital and lead time before you’ve served a single request; Chainstack Solana nodes skip that entirely.
• You’re running at low-to-moderate volume in general — a production workload that doesn’t yet justify owning dedicated hardware, or you’re still learning and prototyping.
• You need Geyser/Yellowstone gRPC streaming for program-account monitoring without building it yourself. That ships built-in through Chainstack’s managed Solana nodes; on Self-Hosted you’d need to run the Yellowstone plugin yourself on top of your own Agave node.

The middle ground — production workloads that wanted their own Solana node without committing to sourcing and babysitting 256 GB-RAM, multi-NVMe hardware themselves — used to have no clean answer. DIY self-hosting worked, but the hardware research, snapshot tooling, and upgrade discipline around Agave was itself a quarter of DevOps work, arguably more given how punishing Solana is of getting the sizing wrong. Chainstack Self-Hosted is what removes that barrier: your infrastructure, none of the setup marathon.

If your Solana workload is heading toward “load-bearing for the business” — and on a chain where a single aggregator routes several billion dollars a day, that threshold arrives faster than most teams expect — running your own node was always the right answer. What’s new is that the path from “I should probably do this” to “it’s deployed and monitored” doesn’t require becoming a Solana hardware specialist first.

FAQ

Additional resources

Chainstack Self-Hosted documentation:

• Introduction to Chainstack Self-Hosted
• Supported clients and protocols
• System requirements
• Quick start
• Solana developer tooling docs

External:

• Agave GitHub repository (Anza)
• Agave 4.2 release overview (Solana Foundation)
• Coinbase Q2 2026 Solana Validator Performance Report

Related reading — Running your own node:

• Running your own Polygon node
• Running your own Bitcoin node
• Running your own TRON node
• Running your own Base node