Learn how to set up an Avalanche node with AvalancheGo, meet validator staking requirements, maintain uptime, and monitor your node for rewards.
Running your own Avalanche node gives you direct access to one of the fastest, most scalable blockchain networks in crypto — whether to validate, power a private RPC endpoint, or contribute to decentralization. Spinning up an AVAX node is more accessible than most people assume, provided you respect the hardware and staking requirements.
This guide covers the full process: choosing hardware, installing AvalancheGo, syncing the network, and optionally becoming a validator to earn AVAX rewards.
An Avalanche node is a server running AvalancheGo, the official Go-based client maintained by Ava Labs. Every node participates in the Avalanche consensus protocol — a probabilistic, leaderless system that achieves finality in roughly one to two seconds under normal conditions.
The Avalanche network is composed of three built-in blockchains:
A full node syncs all three chains. Validators additionally register on the P-Chain, lock a minimum AVAX stake, and participate in consensus to earn staking rewards.
Nodes also serve as RPC endpoints. Many teams run private full nodes to avoid relying on third-party providers — an approach covered in our guide to the Best RPC Node Providers for Web3 Developers (2026).
Avalanche’s throughput expectations are higher than most blockchains, and your hardware must reflect that. Ava Labs publishes minimum and recommended specs in its official documentation; always check the current requirements at docs.avax.network before provisioning hardware, since requirements evolve with network upgrades.
As a practical baseline for a full node:
| Component | Minimum | Recommended |
|---|---|---|
| CPU | 4 cores / 8 threads | 8+ cores |
| RAM | 8 GB | 16 GB |
| Storage | 1 TB NVMe SSD | 2 TB NVMe SSD |
| Network | 5 Mbps stable | 25 Mbps+ |
| OS | Ubuntu 20.04+ / macOS | Ubuntu 22.04 LTS |
Storage is the most critical variable. Avalanche state grows over time, and spinning-disk HDDs will cause your node to fall behind during peak load. An NVMe SSD is strongly recommended for validators, where uptime directly affects rewards.
Pruning modes exist to reduce storage footprint, though archive nodes retain full historical state and require substantially more disk space.
Ava Labs maintains an official install script that handles binary download, systemd service creation, and basic configuration in a single command. Run it on a fresh Ubuntu server:
wget -nd -m https://raw.githubusercontent.com/ava-labs/avalanche-docs/master/scripts/avalanchego-installer.sh
chmod 755 avalanchego-installer.sh
./avalanchego-installer.shThe script prompts you to choose your network (mainnet or Fuji testnet), detects your architecture, and sets up a systemd service that restarts on failure. The script outputs the exact binary path on completion.
For developers who want full control or need a custom build:
git clone https://github.com/ava-labs/avalanchego.git
cd avalanchego
./scripts/build.shCheck the go.mod file in the repository for the exact Go version requirement, as it advances with each major release. Building from source takes several minutes on a modern server.
Ava Labs publishes official Docker images (avaplatform/avalanchego) suitable for containerized environments. A docker-compose setup lets you run the node alongside monitoring agents without polluting your host environment.
AvalancheGo is configured via command-line flags or a JSON config file at ~/.avalanchego/configs/node.json. Key parameters:
--network-id: mainnet or fuji (testnet)--http-host: 127.0.0.1 for local RPC only; 0.0.0.0 to expose externally (use a firewall)--http-port: default 9650 for RPC--staking-port: default 9651 for peer-to-peer — this must be reachable from the public internet for validators--db-dir: path to your fast NVMe volumeIf exposing the RPC endpoint externally, place a reverse proxy (nginx, Caddy) in front with TLS. Never expose an unauthenticated RPC on a public IP if the node holds any private keys.
The first time AvalancheGo starts, it bootstraps — downloading and validating the blockchain history from peers. On mainnet, this can take anywhere from a few hours to over a day depending on hardware and bandwidth.
Monitor progress via the local API:
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/infoOnce "isBootstrapped": true for all three chains (X, C, P), your node is fully synced.
State sync downloads a recent state snapshot rather than replaying full history, dramatically reducing initial sync time. It is not suitable for archival purposes but is ideal for validators who simply need to participate in consensus.
A full node can operate purely as an RPC server, but many operators want to earn AVAX staking rewards by becoming a validator.
Avalanche requires validators to lock a minimum amount of AVAX on the P-Chain for a defined period. According to Ava Labs’ official documentation at docs.avax.network, the minimum validator stake is 2,000 AVAX and the minimum delegator stake is 25 AVAX. These figures are governed on-chain and can change — always confirm against current documentation before committing funds.
Key staking principles:
Validator registration happens through the P-Chain. You can use:
You will need your node’s Node ID, derived from its TLS certificate and unique per installation. Retrieve it with:
curl -X POST --data '{
"jsonrpc":"2.0",
"id" :1,
"method" :"info.getNodeID"
}' -H 'content-type:application/json;' 127.0.0.1:9650/ext/infoThe P-Chain transaction to add a validator requires a small fee and your staked AVAX.
Avalanche’s validator rewards are contingent on uptime, not just elapsed time. The protocol samples validators periodically, and the minimum threshold has been raised via governance proposal ACP-267.
Primary Network validators must now maintain at least 90% uptime to remain eligible for rewards in a given validation period (up from 80% under the prior threshold). Always confirm the requirement that applies to your specific validation period at docs.avax.network before staking.
Practical implications:
Production validators should run a monitoring stack alongside AvalancheGo. The node exposes Prometheus-compatible metrics at:
http://127.0.0.1:9650/ext/metricsA standard observability setup:
Key metrics to watch:
avalanche_network_peers — should remain stable and non-zeroavalanche_{X,C,P}_blks_accepted_count — should grow continuouslyavalanche_health_checks_failing_count — should always be zeroFor teams running multiple nodes or subnets, a log aggregator like Loki or Datadog gives cross-node visibility and simplifies debugging during network upgrades.
One of Avalanche’s most powerful features is Subnets — customizable, sovereign blockchains that share validators from the primary network. Validators can optionally validate additional subnets and earn extra fees.
Running a subnet validator requires staying in good standing as a primary network validator, installing the subnet’s custom VM plugin alongside AvalancheGo, and registering on that subnet’s P-Chain record. Subnets are used by gaming projects, DeFi protocols, and institutions needing dedicated throughput or custom execution environments. For a comparable workflow on a different network, see How to Run a Hyperliquid RPC Node.
Running a validator with real staked capital demands serious operational security:
9650 (RPC) behind a firewall or VPN if not intended to be public.9651 (staking) open to the internet — validators cannot communicate without it.Rotate TLS certificates with care: a node ID change mid-validation period disrupts your validator registration.
Last updated: June 2026