All articles
solanavalidatorhardwarenetworkingagaveoperationsstakingbuilders

What it takes to be a Solana validator

Hardware, network, and cost of running a Solana consensus validator: Anza Agave requirements (CPU, RAM, NVMe, ports), bandwidth tiers, vote SOL burn, stake reality, and how this differs from an RPC node. Rough cost ranges and ops checklist.

devrels.xyz/a/216short link

Running a Solana consensus validator means participating in voting and (with stake) leader slots — not serving public JSON-RPC. The bar is operational: keep a high-performance machine on a fat pipe, never empty the identity account that pays votes, and attract stake so the node is worth running.

Canonical requirements live in Anza’s Agave docs: Validator requirements, Validator vs RPC, Setup guide. Community hardware shortlist: solanahcl.org.

Consensus validator vs RPC node

Pick the job before you buy metal
Consensus validatorRPC node
Votes / earns protocol rewardsYes (with vote account + stake story)No
Primary userThe network (and your delegators)Apps / traders hitting JSON-RPC
Hardware skewCPU clock, disk IOPS, networkMore cores/RAM, bigger ledger, indexes
Public RPC portsGenerally keep closed on mainnet stakeOpen and scaled as a product

This article is about consensus validators. RPC shops need the heavier column in Anza’s table and a different business model.

Hardware requirements

Anza publishes recommendations, not a single SKU. Operators are expected to benchmark. Summary of the official validator column:

Agave hardware recommendations (validator)
ComponentGuidance
CPU≥2.8 GHz base; prefer higher clocks over more cores. SHA extensions; AMD Gen 3+ or Intel Ice Lake+. AVX2 for official binaries (else self-compile). AVX-512 helpful. 12 cores / 24 threads or more
RAM256 GB or more; ECC suggested; motherboard headroom toward 512 GB capacity is common planning
DiskPCIe Gen3 x4 NVMe (or better), high TBW, preferably separate volumes:
• Accounts — 1 TB+
• Ledger — 1 TB+
• Snapshots — 500 GB+
• OS — 500 GB+ optional (SATA OK)
Accounts + ledger on one disk works but is not recommended under load
RPC extras16c/32t+, 512 GB+ RAM if full account indexes, larger ledger for history — not required for a pure voter

Software: Agave targets Ubuntu 24.04. Prebuilt binaries have historically assumed x86_64 + AVX2; building from source is the durable path. Docker is not recommended for live cluster validators. Cloud VMs need serious tuning; Anza warns not to expect sympathy if you choose that path and struggle.

Second clients (e.g. Firedancer / Frankendancer) have their own preferred CPU layouts — see solanahcl categories before buying for a non-Agave stack.

Network requirements

Connectivity (from Agave requirements)
ItemRequirement
AddressingStable connection with a public IPv4
Unstaked node~1 Gbit/s symmetric can be enough
Staked nodeAt least 2 Gbit/s symmetric; 10 Gbit/s available bandwidth recommended for stable operation
NATNot recommended; you own all debugging if you insist
OutboundNo filtering from validator to the internet

Firewall

Ports
DirectionProto / portsNotes
Required inboundTCP + UDP 8000–8030Gossip, turbine, repair, etc. Remap with --dynamic-port-range if needed
RecommendedSSH (e.g. TCP 22) from your static management IP onlyLock down admin plane
Optional / cautionRPC 8899 / 8900Do not casually expose on staked mainnet validators

Colocation next to other Solana operators and good peering matters as much as raw “up to 10G” marketing. Packet loss and jitter show up as skip rate and delinquency faster than a slow disk does.

SOL requirements

From Anza: there is no strict minimum amount of SOL to run an Agave validator on Solana. Practical floors:

SOL you actually need
ItemAmount / note
Vote account rent-exempt reserveAbout 0.02685864 SOL locked in the vote account
Voting feesUp to about 1.1 SOL per day (docs also cite ~1.0 SOL/day) — paid from the validator identity account
Identity working balanceKeep a multi-day buffer (many operators hold tens of SOL+ so a refill outage does not halt voting)
Protocol minimum stake to existNone — but without delegation you rarely cover costs
Economic stakeRewards scale with active stake and performance (vote credits, leader slots). New validators usually need self-stake, SFDP/stake pools, or private delegation — plan this before buying iron

Income side (high level): inflation rewards via vote credits; when leader, a share of transaction fees on produced blocks (protocol splits apply). Commission is your cut of staker rewards. Model with community tools (e.g. Cogent’s validator profit calculator) using your expected stake and commission — do not assume break-even at zero delegation.

Related builder context on stake mechanics: Solana staking.

Cost of the stack (order-of-magnitude)

Exact quotes move with CPU generations and colo markets. Use these as planning bands, then get current bids.

Rough cost buckets (USD, indicative)
BucketWhat you pay forBallpark
Server hardware12–32c class CPU (or Threadripper/EPYC), 256–512 GB ECC, 3–4× enterprise NVMe, NICOften mid four-figures to low five-figures to buy once; refresh cycle every few years
ColocationRack unit, power, remote handsHundreds of USD per month depending on power and facility
Bandwidth1–10 Gbit commit / burst, good transitCan dominate opex at 10G; 1–2G is cheaper but staked mainnet wants headroom
Vote SOL~1–1.1 SOL/day at market priceContinuous opex in SOL terms — budget monthly at your price assumption
People / opsOn-call, upgrades, key ceremony, monitoring (agave-watchtower, paging)Non-zero even for a “single box” — delinquency is a full-time failure mode
OptionalSpare parts, second location, Jito-Solana client ops, extra toolingAdds both cost and complexity

Bare metal in a Solana-dense colo still beats “random large cloud VM” for most serious operators. If you rent a managed validator bare-metal product, compare total monthly cost against self-build + colo + your time.

Skills and operations

  • Linux performance tuning (disks, sysctl, CPU governor, NIC)
  • Agave install/upgrade discipline aligned with cluster versions
  • Key management: identity, vote authority, withdraw authority separation
  • Monitoring and alerting — agave-watchtower and external explorers (e.g. validators.app)
  • Stake marketing / SFDP or pool applications if you need external SOL
bash
# Conceptual — not a full runbook
# 1) Ubuntu 24.04 bare metal, public IPv4, disks split
# 2) Install Agave / client of choice (see docs.anza.xyz)
# 3) Create identity + vote account; fund identity for votes
# 4) Open 8000-8030; lock SSH to admin IP
# 5) Start validator, wait for catchup, never empty identity
# 6) agave-watchtower --monitor-active-stake --validator-identity <PUBKEY>

Checklist before you commit

  1. Consensus validator or RPC business? (Different box and P&L.)
  2. Hardware meets Anza floor; disks split; ECC RAM planned.
  3. Colo + ≥2 Gbit/s (prefer 10G headroom) + public IPv4, no flaky NAT.
  4. Vote rent + identity buffer for many days of ~1 SOL/day votes.
  5. Stake plan: self-stake and/or external delegation path.
  6. On-call and upgrade process before mainnet keys go live.

Related

Summary

Becoming a Solana validator is mostly systems work: a fast multi-core machine with 256 GB+ RAM and serious NVMe, a public IPv4 path at multi-gigabit (10G recommended once staked), open P2P ports, and continuous funding of vote transactions at roughly a SOL per day. There is no protocol minimum stake, but without delegation the hardware and vote burn rarely make sense. Buy for IOPS and network first, keep RPC off the staked box unless you know why, and treat ops as part of the cost of securing the network.

Keep reading

Get new articles in your inbox

Technical deep-dives on Solana tooling, infrastructure, and ecosystem. No noise.

What it takes to be a Solana validator | devrels.xyz