Deploying an Avalanche Node

Synchronizing an Avalanche node can take up to a day if state sync is not configured. An incorrect archive mode configuration can fill the disk in a week. We deploy Avalanche nodes turnkey: from selecting the node type (full node, validator, archive) to setting up monitoring and integrating with your applications. With 5 years on the market, we have completed over 30 successful deployments on mainnet and Fuji testnet. We guarantee 99.9% uptime by SLA and provide maintenance documentation. Time savings on synchronization — up to 3 days thanks to state sync and optimized mirror repositories.

Avalanche is not a single network but three interconnected chains plus a Subnets mechanism for custom blockchains. Before deploying a node, you need to understand its purpose: interaction with C-Chain (EVM-compatible, where most DeFi lives), P-Chain (platform, validator and Subnet management), X-Chain (UTXO, asset exchange), or validating your own Subnet. State sync in AvalancheGo is 10x faster than a full replay from genesis, so we always use state sync mode.

AvalancheGo: a single client for all chains

Avalanche nodes run AvalancheGo — the official Go client. One process handles all three chains simultaneously.

System requirements

C-Chain archive node stores the full EVM state history — needed for eth_call on historical blocks and debug_traceTransaction. An archive node requires 4x more disk space than a full node.

# Official install script (recommended) curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-docs/master/scripts/avalanchego-installer.sh \ | sh -s -- --ip dynamic --rpc-port 9650 --http-host 0.0.0.0 

// ~/.avalanchego/configs/node.json { "network-id": "mainnet", "http-host": "127.0.0.1", "http-port": 9650, "staking-port": 9651, "db-dir": "/data/avalanchego", "log-level": "info", "log-dir": "/var/log/avalanchego", // Only if public RPC is needed "http-allowed-hosts": "your-domain.com,localhost", // For C-Chain archive mode "chain-config-dir": "/data/avalanchego/configs/chains" } 

// /data/avalanchego/configs/chains/C/config.json { "eth-apis": ["eth","eth-filter","net","web3","internal-eth","internal-blockchain","internal-transaction"], "pruning-enabled": false, // archive mode "tx-lookup-limit": 0, "snapshot-async": true, "rpc-gas-cap": 50000000, "rpc-tx-fee-cap": 100 } 

[Unit] Description=AvalancheGo Node After=network.target [Service] User=avalanche ExecStart=/home/avalanche/avalanche-node/avalanchego \ --config-file=/home/avalanche/.avalanchego/configs/node.json Restart=always RestartSec=10 LimitNOFILE=65536 StandardOutput=append:/var/log/avalanchego/node.log StandardError=append:/var/log/avalanchego/error.log [Install] WantedBy=multi-user.target 

How do we deploy an Avalanche node turnkey?

The deployment process includes five stages:

1. Analysis — determine the load, whether archive mode is needed, plan resources.
2. Design — prepare node.json and C-chain configs, configure firewall, open ports (9650 for RPC, 9651 for staking).
3. Installation — deploy AvalancheGo via install script, create a systemd service, start synchronization.
4. Monitoring — deploy Prometheus + Grafana, configure alerts on key metrics.
5. Handover — provide RPC access, a dashboard, documentation, and 30 days of support.

What you get as a result

Contact us for a consultation — we will select the configuration for your project.

What is an Avalanche validator and how to become one?

A validator ensures network security: it checks transactions and signs blocks. Minimum stake — 2000 AVAX. Uptime requirement — 80%: if the node drops too often, you lose validation rewards.

To get the Node ID, execute a request to RPC: curl -X POST --data '{"jsonrpc":"2.0","id":1,"method":"info.getNodeID"}' -H 'Content-Type: application/json' http://127.0.0.1:9650/ext/info. The Node ID is then used when adding a validator via the P-Chain in core.app or Ledger.

For a validator, the staking port (9651) must be publicly open — it's mandatory for P2P. We guarantee failover setup and uptime monitoring to meet conditions.

Why is an archive node needed for decentralized applications?

An archive node stores the full EVM history — without it, a dApp cannot process eth_call on old blocks or execute debug_traceTransaction for debugging. Comparison:

• Full node: ~600 GB, synchronization 2–6 h, suitable for basic RPC.
• Archive node: ~4 TB, synchronization 12–24 h, mandatory for indexers, block explorers, analytics.

We recommend archive nodes for production services and full nodes for test environments.

Node monitoring

Key metrics are exposed via Prometheus format. We configure alerts:

• avalanche_network_peers < 50 — loss of peers
• avalanche_{chainID}_handler_chits_sum — slow consensus
• Disk I/O > 80% — risk of throttling

A ready-made Grafana dashboard can be found in the official Avalanche repository.

Subnet: custom blockchain network

A Subnet is a custom chain with its own validation rules, VM, gas token. Subnet validators must also validate the Primary Network (same 2000 AVAX stake).

# Install Avalanche CLI for Subnet management curl -sSfL https://raw.githubusercontent.com/ava-labs/avalanche-cli/main/scripts/install.sh | sh # Create a new Subnet with EVM (Ethereum-compatible) avalanche subnet create mySubnet # Choose: SubnetEVM, configure chainId, gas token, genesis 

SubnetEVM is a fork of go-ethereum adapted for Avalanche. It supports all EVM tools: MetaMask, Hardhat, Foundry — just add a custom RPC endpoint.

We will assess your project: help deploy a node for Subnet validation or set up monitoring. Order Avalanche node configuration — get a ready infrastructure with documentation and uptime guarantee.