--- title: "1. Running a Radix Node" url: "https://radix.wiki/developers/infrastructure/01-running-a-node" version: "2.2.0" updated: 2026-08-21 last_verified: 2026-08-21 license: CC-BY-4.0 license_url: "https://creativecommons.org/licenses/by/4.0/" --- # 1. Running a Radix Node ## Overview A Radix node connects to the peer-to-peer network, syncs ledger state, and (if registered as a validator) participates in [Cerberus consensus](/contents/tech/core-protocols/cerberus-consensus-protocol). You can run a node to power your own [API endpoints](/developers/infrastructure/02-radix-apis), support the network, or earn [staking emissions](/contents/tech/core-concepts/network-emissions) as a validator. ## Hardware Requirements | Resource | Minimum | Recommended (Validators) | | --- | --- | --- | | CPU | 4 vCPU | 8 vCPU (e.g., AWS c5.2xlarge) | | RAM | 16 GB | 32 GB+ | | Storage | 500 GB SSD | 1 TB+ NVMe | | OS | Ubuntu 22.04 LTS (Jammy Jellyfish) | | | Network | Port 30000/tcp open for gossip | | Validators need reliability Validators should run on dedicated hardware or high-availability cloud instances. Downtime reduces your share of [emissions](/contents/tech/core-concepts/network-emissions) and may cause delegators to move their stake. ## Installation Radix provides two installation methods: ### Option A: CLI-Guided Install (Recommended) The `babylonnode` CLI tool walks you through configuration interactively: ```bash wget -O babylonnode https://github.com/radixdlt/babylon-nodecli/releases/latest/download/babylonnode-ubuntu-22.04 chmod +x babylonnode sudo mv babylonnode /usr/local/bin/ # Run guided setup babylonnode docker install ``` ### Option B: Docker Manual Setup For more control, use `docker-compose` directly with the official images from [radixdlt/babylon-node](https://github.com/radixdlt/babylon-node). ### Option C: Systemd Run the node process directly on the host, managed by systemd. Better for servers shared with other services. All methods are documented at [docs.radixdlt.com/docs/node-setup](https://docs.radixdlt.com/docs/node-setup). ## Which Node Version the CLI Installs The `latest/download` URL above has not moved since [babylonnode 2.2.4, published on 13 January 2025](https://github.com/radixdlt/babylon-nodecli/releases/tag/2.2.4), and the only commit on the tool's main branch since is [CI housekeeping in March that year](https://github.com/radixdlt/babylon-nodecli/commits/main). That tells you nothing about the node you will end up running, because the CLI does not carry a node version at all. Instead it [resolves the node, nginx and Gateway tags at run time](https://github.com/radixdlt/babylon-nodecli/blob/main/node-runner-cli/github/github.py) from `ghproxy.radixdlt.com`, a Radix-operated mirror of the GitHub releases API, and installs whatever tag comes back. Asked on 21 August 2026, it returns [babylon-node v1.3.0.5](https://github.com/radixdlt/babylon-node/releases/tag/v1.3.0.5) – a release that shipped nearly seventeen months after the CLI binary did. A frozen installer and a current node are not in tension here; the indirection is the point. Two consequences are worth knowing before an unattended rebuild depends on it: - **It is a single external dependency.** If that proxy does not answer, the CLI prints the failing URL and exits – there is no fallback to the GitHub API it mirrors. - **You can pin past it.** Setting `RADIXDLT_APP_VERSION_OVERRIDE` – or `RADIXDLT_NGINX_VERSION_OVERRIDE` and `RADIXDLT_GATEWAY_VERSION_OVERRIDE` for the other two – makes the CLI use that exact tag without asking anyone, which is what a reproducible validator rebuild wants. The published binaries cover Ubuntu 20.04 and 22.04 only, with no 24.04 build – which is why 22.04 is the operating system named in the table above rather than the newer [LTS](https://ubuntu.com/about/release-cycle). Operators on a distribution the CLI does not ship for take the Docker or systemd path instead. ## Becoming a Validator Once your node is synced, you can register it as a validator to participate in consensus and earn emissions. 1. **Register** – submit a validator registration transaction (costs 5-30 XRD in fees) 2. **Configure** – set your validator name, website URL, fee percentage, and delegation policy 3. **Attract stake** – the top 100 validators by total delegated stake are active each epoch 4. **Maintain uptime** – missed proposals reduce your emissions share See the [validator setup guide](https://docs.radixdlt.com/docs/node-setup) for detailed steps. ## Monitoring Use the standard Prometheus + Grafana stack for observability: 1. Install **Node Exporter** for system metrics (CPU, RAM, disk, network) 2. Configure **Prometheus** to scrape your node's metrics endpoint 3. Set up **Grafana** dashboards to visualize node health, sync status, and proposal statistics The node also exposes a **System API** for diagnostics – connection status, health checks, and performance metrics. See [Radix APIs](/developers/infrastructure/02-radix-apis) for details. ## Maintenance - **Protocol updates** – update your node software when new protocol versions are released; validators must signal readiness - **Backups** – the ledger can be rebuilt from the network, but backing up your validator key is critical - **Snapshots** – daily ledger snapshots are available at [snapshots.radix.live](https://snapshots.radix.live) for faster initial sync ## Next Steps - [Radix APIs](/developers/infrastructure/02-radix-apis) – what your node exposes, and when to use it instead of a public Gateway ## External Links - [Node introduction](https://docs.radixdlt.com/docs/node) - [Node setup guide](https://docs.radixdlt.com/docs/node-setup) - [Validator setup](https://docs.radixdlt.com/docs/node-setup) - [Maintenance guide](https://docs.radixdlt.com/docs/running-infrastructure) - [babylon-node GitHub](https://github.com/radixdlt/babylon-node) - [babylon-nodecli GitHub – the `babylonnode` tool](https://github.com/radixdlt/babylon-nodecli)