Run a Validator Node on Ubuntu: A Guide

You can run a validator node on Ubuntu with Docker, even if you have never run a blockchain node before, as long as you start on testnet and follow the steps in order. This guide gives you a practical, generic setup: server, Docker, firewall, node with Docker Compose, sync checks, keys, and troubleshooting. It does not replace the official docs for your specific chain - every chain has different binaries, ports, and stake rules - but it gives you the workflow that works across most chains, so you are not starting from a blank terminal.

The answer in one paragraph: rent or prepare an Ubuntu server with enough CPU, RAM, and disk for your chain, install Docker and Docker Compose, open only the ports your node needs, start the node with a Compose file that stores data in a volume, wait for sync, check logs and sync status, create validator keys only on testnet first, and monitor from day one. If any step fails, stop and read the log - do not keep restarting blindly.

Hardware and server requirements

Requirements vary by chain, so check your chain's official docs on the day you set up. As a general starting point for a testnet full/validator node, many guides suggest at least 4 CPU cores, 16 GB RAM, and 500 GB-1 TB of fast SSD storage, plus a stable internet connection. Solana and some high-throughput chains need much more - faster disks, more RAM, and more CPU - while smaller testnets need less. Do not guess: if your chain's docs say 32 GB RAM and NVMe, a 4 GB VPS will not work, no matter how cheap it is.

For a beginner, a VPS (virtual private server) is easier than a home PC, because it stays online, has a stable IP, and is easier to monitor. In India, choose a VPS region with good latency to your chain's peers, and make sure you can pay in a way that works for you. For mainnet, use a dedicated server or a well-specified VPS, not a shared hosting plan.

Step 1: Prepare Ubuntu

Start with a fresh Ubuntu server (22.04 LTS or 24.04 LTS are common choices; check your chain's supported versions). Update it, create a non-root user, and enable a firewall. Do not run a node as root if you can avoid it.

sudo apt update && sudo apt upgrade -y
sudo adduser nodeuser
sudo usermod -aG sudo nodeuser
sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

Log in as the new user for the rest of the setup. This is a small step that prevents a large class of security mistakes.

Step 2: Install Docker and Docker Compose

Docker lets you run a node in a container, with its data in a volume on your host. That makes updates, backups, and moves much easier than installing binaries directly on the host for a beginner.

sudo apt install -y ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu $(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin
sudo usermod -aG docker nodeuser
docker --version
docker compose version

Log out and back in after adding your user to the docker group, or the docker commands will ask for sudo every time.

Step 3: Create a Compose file (generic template)

This is a template, not a chain-specific config. Replace the image, ports, and volumes with the values from your chain's official docs. Never copy an image name from a random blog without checking it on the official docs or Docker Hub page for that project.

# docker-compose.yml - TEMPLATE, replace image/ports with your chain's docs
services:
  node:
    image: <chain-node-image>:<version>
    container_name: validator-node
    restart: unless-stopped
    ports:
      - "30303:30303"
      - "30303:30303/udp"
    volumes:
      - ./node-data:/data
    command: ["--chain", "testnet", "--datadir", "/data"]

Start it, then watch the logs:

mkdir -p ~/validator && cd ~/validator
# save the compose file above as docker-compose.yml, edited for your chain
docker compose up -d
docker compose logs -f --tail=100

If the container exits immediately, the log is your first clue. Common causes are a wrong image tag, a port already in use, or a missing volume permission. Fix the cause, do not just restart in a loop.

Step 4: Check sync, peers, and health

A node that is running is not necessarily synced. Check sync status using your chain's tool - for many chains, that is an RPC call, a CLI status command, or a log line about block height. Compare your node's block height to a public explorer for the same chain and network (testnet vs mainnet - do not mix them up).

# Generic health checks - replace with your chain's CLI/RPC
docker compose ps
docker compose logs --tail=50
df -h
free -h

Healthy signs: steady new blocks, peer count above zero and stable, disk use growing slowly, and no repeated errors. Unhealthy signs: block height stuck, peer count at zero, disk at 100%, or the same error repeating every few seconds. If block height is stuck, check peers, firewall, and whether you are on the right network and client version.

Step 5: Keys, validator creation, and testnet first

Only create validator keys after the node is synced on testnet, and only after reading your chain's key and staking docs. In general, the flow is: generate keys in a safe place, back them up offline, fund a testnet account from a faucet, and create the validator from the testnet docs. Never generate mainnet keys on a server you have not secured, and never share a seed phrase or private key.

A safe testnet workflow is: node synced → keys generated → faucet funds received → validator created on testnet → validator appears on the testnet explorer → monitoring set up → upgrade tested on testnet. Only after that workflow works end-to-end should you even consider mainnet, and mainnet stake amounts, commission, and slashing rules must be read from official docs on that day.

Troubleshooting: the 5 problems beginners hit

1. Sync stuck: Check peers, firewall ports, client version, and disk. A node with no peers cannot sync, and a node with a full disk cannot write new blocks.
2. Container exits: Read docker compose logs, check image tag and volume permissions, and check if a port is already used by another service.
3. Disk full: Check df -h, prune if your chain supports it (and you understand what pruning does), or move to a larger disk before the node stops.
4. High CPU or memory: Check if you are syncing (high use during sync is normal) or if you are under-provisioned for your chain. Do not just add swap and hope.
5. Validator not voting: Check sync, keys, and whether the validator is actually in the active set. A validator that is not in the active set will not vote, no matter how healthy the node is.

Monitoring from day one

Set up at least: block height lag alert, disk alert at 80%, peer count alert, and a log check you actually read. Grafana and Prometheus are a good next step (see Day 2, Post 4 in this plan), but even a simple script that checks sync and sends you a message is better than no monitoring. A validator that goes offline at night and is discovered in the morning has already lost rewards and trust.

When to hire help

If this guide feels like a lot, that is normal - validator operations are a 24/7 job, not a weekend project. DevOpsBY sets up and runs validators, full nodes, archival nodes, and private RPC for Web3 teams, with monitoring, upgrades, and incident response included. Start with a free infra audit, and we will tell you honestly whether your setup is ready for testnet, mainnet, or neither yet.

CTA: Hire DevOpsBY to set up and run your validator node, or get a free infra audit at /contact. Bring your chain name and testnet goals, and we will scope the server, setup, and monitoring for you.