Avalanche node requirements in 2026: AvalancheGo and validators

An Avalanche validator needs 4 cores/8 threads, 16 GB of RAM, a 1 TB local NVMe SSD and 100 Mbps symmetric at low stake, or 8 cores/16 threads, 32 GB, 2 TB and 1 Gbps at high stake, per Avalanche’s documentation as of October 2026. A C-Chain archive node needs 12.5 TB or more.

Those figures come from the Avalanche Builder Hub’s System Requirements page, revised in early October 2026 for the Helicon upgrade, active on Mainnet since September 22, 2026. Helicon left the hardware tiers alone but changed disk maintenance and the staking rules. This guide covers hardware, disk planning and setup; it is not staking or financial advice.

The short version

The L1 row gives low, medium and high throughput tiers. Every tier lists Ubuntu 22.04 LTS or macOS 12 or later, every node must accept inbound TCP on port 9651, and a Primary Network validator stakes at least 2,000 AVAX.

Validator hardware: why stake sets the tier

Avalanche sizes Primary Network validators by stake weight: “Validators with higher stake receive more traffic and must process more data, requiring better hardware.” Validators sample each other with a probability proportional to stake, so a heavily delegated node answers more queries. The docs give example parts, a Ryzen 5 or Core i5 for low stake and a Ryzen 7/9 or Core i7/i9 for high stake, but no threshold between the tiers, and advise starting low and upgrading on CPU, memory or network saturation.

Three official sources give minimums:

Read as hardware threads, the README’s 8 vCPUs match the low-stake tier. The sources differ on storage type: the requirements page says validators must use local NVMe, because cloud block storage “introduces latency that causes poor performance, missed blocks, and potential benching”, while ACP-256 would tolerate network-attached storage for validators that keep their stored state under 500 GB. On a dedicated server with NVMe in the chassis, the question does not arise.

How much disk an Avalanche node needs

For a Primary Network node, the docs size the disk by the C-Chain’s EVM state:

Plan for the middle row. With the default hash state scheme, a pruned node writes a state sync snapshot every 4,096 blocks for other nodes to sync from, and “most long-running validators operate in this state”. A node that starts at 500 GB can pass 1 TB within months. The docs set disk alerts at 80% and 90% and call disk usage “the most common issue for validators”.

Helicon removed the in-place fix. Offline pruning used to delete those snapshots on the same machine. Since Helicon, the C-Chain in AvalancheGo v1.15.0 and later ignores offline-pruning-enabled, and the docs call a fresh state sync “the only way to remove accumulated snapshots”. This periodic state sync runs a second node until it is synced, then stops both and moves staker.crt, staker.key and signer.key to the new one, which validates under the same NodeID after a stop of usually 5 to 15 minutes. Subnet-EVM L1 chains can still prune offline.

Disk size sets how often you resync. Starting at 500 GB, growing 150–200 GB a month and acting at the 80% alert (our arithmetic):

• 1 TB: a resync every 1.5 to 2 months.
• 1.92–2 TB: every 5 to 7 months.
• 3.84 TB: every 13 to 17 months.

How current are these sizes? The docs repository dates them: the 12.5 TB archive figure to December 18, 2025 (it replaced “~3 TB+”), the ~13 TB figure to December 22, and the growth rates to February 4, 2026, when the archival estimate rose from about 250 to 500 GB a month. The Helicon revision changed none of them. Applied to the December figure, those rates put a full archive at roughly 15 to 18 TB by mid-October 2026: our extrapolation, not a measurement, and the reason we size archive servers for 20 TB or more.

State sync and bootstrapping after Helicon

State sync, on by default for the C-Chain and recommended for new validators, downloads the latest state from other validators instead of replaying every block since genesis: hours rather than days. The v1.15.0 release notes add three limits:

• Restarting a node mid-sync “will restart the sync from the beginning”, so finish OS updates and reboots first.
• Disabling state sync after a partial sync “may result in an unrecoverable FATAL error”; recovery means deleting the database.
• The experimental Firewood state scheme cannot state sync, so a Firewood node on Mainnet executes every block from genesis.

C-Chain archive node requirements

An archive keeps the state at every block, for questions such as an account’s balance at block 1,000,000; the docs reserve it for “block explorers, indexers, and specialized analytics applications”. It needs "pruning-enabled": false and "state-sync-enabled": false in the C-Chain config, then a full sync from genesis. Converting an existing node requires a fresh bootstrap.

A lighter variant, state sync with pruning off, gives an “archival RPC” node with full state from its sync height: 750 GB–1 TB at first, then archival growth. It cannot answer queries about earlier blocks, but costs a fraction of a genesis archive.

Avalanche gives no CPU or RAM figures for archives. ACP-256 calls local NVMe mandatory for them, and v1.15.1, released on October 1, 2026, fixed block execution lagging “on large hashdb archives”, so run the current release.

Validator staking rules after Helicon

The Primary Network rules on Mainnet, as of October 2026:

Rewards are all or nothing, with no slashing: a validator under the threshold keeps its principal but forfeits its rewards. Uptime is judged by the other validators, weighted by stake, so check info.uptime and the Validator Health dashboard. The 10% allowance is 4.8 hours on a 48-hour validation and 33.6 hours on two weeks. A validator staking for less than two weeks cannot receive delegations, since a delegation must last two weeks and fit inside the validator’s period.

Helicon also added auto-renewed staking (ACP-236): a validator sets a cycle length and a restaking share, and renews at each cycle boundary while it meets the uptime requirement; setting the period to 0 stops it. A classic validation cannot be changed or withdrawn early once issued.

L1 validators after ACP-77 (Avalanche9000)

The Etna upgrade, also called Avalanche9000, activated ACP-77 on Mainnet on December 16, 2024 and separated L1 validation from the Primary Network. An L1 validator:

• Does not stake 2,000 AVAX or validate the C-Chain and X-Chain. The L1’s own validator manager sets its staking rules, and ACP-267’s 90% uptime rule does not apply.
• Pays a continuous fee to the P-Chain from a prepaid balance: at least 512 nAVAX per second, about 1.33 AVAX a month, while no more than 10,000 L1 validators are active. Above that target the rate rises exponentially, and a validator whose balance runs out is deactivated.
• Syncs only the P-Chain with --partial-sync-primary-network=true. Without the flag, the node also syncs the X-Chain and C-Chain, and the docs say to add the Primary Network requirements.

With partial sync, requirements scale with traffic: 2 cores, 4 GB and 100 GB below about 10 TPS; 4 cores, 8 GB and a 500 GB SSD up to 100 TPS; 8+ cores, 16 GB+ and 1 TB+ of NVMe beyond.

Ports and bandwidth

A validator with an unreachable port 9651 or a wrong advertised address risks low uptime; the staking guide’s fix is --public-ip plus an open port. The installer asks whether RPC should be public or private and warns that validator nodes “SHOULD NOT have their RPC port open”.

Avalanche states bandwidth as link speed and gives no monthly traffic figure. Each PowerDedi server has its own 10 Gbps unmetered port, so neither validator traffic nor a 500 GB resync appears on the bill. Always-on network DDoS mitigation sits in front of port 9651, and a routed IPv6 /64 is included.

Which PowerDedi server for an Avalanche node

All configurations below have local NVMe and month-to-month billing; our acceptable use policy allows nodes and validators, not mining. Two-drive servers default to RAID 1, a mirror with the capacity of one drive; RAID 0 or No RAID can be chosen when you order or reinstall, as our software RAID guide explains. Four-drive servers default to RAID 10 and also offer RAID 5 and RAID 0.

Four caveats:

• Striping versus a mirror. Chain data can be synced again, so RAID 0 is a fair trade for capacity if the staking keys are backed up off the server. But a failed drive then costs hours of state sync, and the 90% rule leaves only 4.8 hours on a 48-hour validation. On short validations, keep the mirror.
• The resync needs a second machine. The documented procedure syncs a new server while the old one validates; in-stock configurations are delivered about 15 minutes after the payment confirms on-chain. Our suggestion: alternate two servers, clearing the old node’s keys and database after each swap. Never run two nodes with the same staking keys at once.
• The archive server is mostly disks. Only the EPYC 9965 holds a genesis archive with headroom, so you rent 192 cores to get 30.72 TB of raw NVMe. RAID 5 adds parity writes; RAID 0 gives all of it, unprotected. Our storage servers keep their bulk capacity on hard drives, which the local NVMe requirement rules out.
• Location. Avalanche’s docs set no location requirement, so choose the city that suits your operations.

How to run an Avalanche node: setup outline

The quickest path on a fresh Ubuntu server is Avalanche’s installer script, which supports Debian- and RHEL-family distributions on amd64 or arm64 and installs the latest AvalancheGo as a systemd service: v1.15.1 as of mid-October 2026, and Mainnet needs v1.15.0 or later since Helicon. Commands from the docs:

# 1. Download the installer
wget -nd -m https://raw.githubusercontent.com/ava-labs/builders-hub/master/scripts/avalanchego-installer.sh
chmod 755 avalanchego-installer.sh

# 2. Validator: fixed IP, local-only RPC, state sync on
#    (public API node: --rpc public, behind a firewall)
./avalanchego-installer.sh --ip static --rpc private --state-sync on

# 3. Follow the bootstrap, then check the C-Chain
sudo journalctl -u avalanchego -f
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.isBootstrapped","params":{"chain":"C"}}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info

# 4. NodeID, BLS public key and proof of possession, needed to stake
curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.getNodeID"}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/info

For a full archive, the installer’s --archival flag turns pruning off. In the script we downloaded on October 15, 2026, combining it with --state-sync off writes the two settings without a comma between them, which is not valid JSON. Until that is fixed, stop the service after installation (sudo systemctl stop avalanchego), make ~/.avalanchego/configs/chains/C/config.json match the block below, check it with python3 -m json.tool and start the service again:

{
  "pruning-enabled": false,
  "state-sync-enabled": false
}

Then back up staker.crt, staker.key and signer.key from ~/.avalanchego/staking off the server: losing staker.key gives the node a new NodeID, and losing signer.key leaves a BLS key that no longer matches your registered validator. Firewall everything except SSH and port 9651 using our first-hour hardening checklist, and register the validator through Core web, platform-cli or the Builder Console staking tool.

Common questions

Do I need my own node to stake AVAX? No. Delegating to an existing validator takes 25 AVAX for at least two weeks and no hardware; the validator keeps a fee of at least 2% of your rewards.

Can I run a validator on a VPS or a cloud instance? Only with local NVMe: the requirements page rules out cloud block storage such as AWS EBS or GCP Persistent Disk.

Does AvalancheGo run on Windows? No longer: v1.13.3, released on July 22, 2025, removed Windows support.

For other EVM chains, see our Ethereum node hardware guide. Current stock and locations are on our blockchain node hosting page, and every configuration can be paid for in BTC, ETH, XMR, USDT on TRON or SOL.

Sources

• System Requirements — Avalanche Builder Hub (revised October 2026)
• Chain State Management and Periodic State Sync — Avalanche Builder Hub
• Introduction and How to Stake — Avalanche Builder Hub
• Helicon Upgrade — Avalanche Builder Hub; Helicon: Improved Staking Economics and Continuous Execution — Avalanche Builder Hub blog (September 8, 2026)
• C-Chain Configs and AvalancheGo Config Flags — Avalanche Builder Hub
• Installing AvalancheGo, Node Config and Maintenance and Preparing Your Environment — Avalanche Builder Hub; avalanchego-installer.sh — ava-labs/builders-hub on GitHub (read October 15, 2026)
• ACP-77: Reinventing Subnets and ACP-256: Hardware Recommendations — Avalanche Builder Hub
• Motivation behind Avalanche9000 — Avalanche Builder Hub blog
• AvalancheGo README — ava-labs/avalanchego on GitHub
• AvalancheGo Releases — Avalanche Builder Hub; release notes for v1.15.0, v1.15.1 and v1.12.0 (Etna) — ava-labs/avalanchego on GitHub
• History for system-requirements.mdx and commits 291f09e, 972995c and 48c5190 — ava-labs/builders-hub on GitHub