How to Set Up an Ethereum Node (2026 Guide)

An Ethereum node gives you direct access to the network: your own JSON-RPC endpoint, no rate limits, no third party reading your queries. This guide takes you from a blank Ubuntu server to a synced node with copy-paste commands — Geth as execution client, Lighthouse as consensus client, both managed by systemd. It also covers what most tutorials skip: hardware in 2026, sync duration, monthly cost, and when you are better off with an API.

What is an Ethereum node?

An Ethereum node is a computer that runs Ethereum client software, stores a copy of the blockchain, checks every incoming block against the protocol rules, and exposes a JSON-RPC interface that wallets and applications use to read the chain and send transactions.

Since the Merge in September 2022, “the client” is actually two programs that must run side by side. The execution client (Geth, Nethermind, Besu, Erigon or Reth) holds the state, executes transactions and answers JSON-RPC calls. The consensus client (Lighthouse, Prysm, Teku, Nimbus or Lodestar) handles proof of stake: it follows the beacon chain and tells the execution client which block is the current head. The two talk over an authenticated local port (8551) and identify each other with a shared JWT secret. One without the other is not a working node. This detail trips up most first-time operators.

Three storage profiles exist. A full node keeps recent state and prunes old data; Geth needs around 1.2–1.4 TB in mid-2026. An archive node keeps every historical state — well over 10 TB on Geth’s classic hash-based layout, or roughly 2–3 TB on clients built for it such as Erigon and Reth. A light node downloads headers only; it sounds attractive, but almost no peers serve light clients on mainnet, so it is not a practical access path.

Ethereum node requirements

The numbers below describe a full node in 2026. An archive node is a separate project, and a validator adds no hardware on top of a solid full node.

Two rows deserve explanation.

Storage must be NVMe. Syncing writes small random chunks at high rates. SATA SSDs regularly get stuck in Geth’s state-heal phase for days, and cloud volumes with default IOPS often never finish at all. A TLC NVMe drive with DRAM cache is the safe pick. On capacity: Geth’s database sits around 1.2 TB and Lighthouse adds roughly 200–250 GB, so 2 TB works today but leaves thin headroom — 4 TB buys you years.

Traffic adds up too. A node moves on the order of 1 TB per month. Home connections handle that fine; VPS plans with tight traffic caps do not.

Linux, macOS and Windows all work. Every command below assumes Ubuntu 24.04, a common server default.

Ways to run a node

You do not have to assemble everything by hand. Plug-and-play boxes such as DappNode and Avado are preconfigured machines with a dashboard: buy one, connect it, follow the wizard. ARM boards work as well — Ethereum on ARM publishes ready-made images for Raspberry Pi 5 class hardware with NVMe storage, cheap to run but slower to sync. Launchers automate the manual route: eth-docker (Docker-based, terminal knowledge required), Stereum (installs clients on a remote server over SSH with a GUI), NiceNode (pick a client, start in a few clicks) and Sedge (a CLI wizard by Nethermind that generates a Docker configuration).

Cloud or local? A VPS is fine for development. If censorship resistance is part of your motivation, run on hardware you own — a node inside a big cloud region inherits that provider’s jurisdiction and terms of service.

The rest of this guide does the manual setup. It teaches you the most, and everything you learn transfers to the launchers.

Step by step: Geth + Lighthouse on Ubuntu

1. Prepare the server

sudo apt update && sudo apt upgrade -y
sudo useradd --no-create-home --shell /usr/sbin/nologin geth
sudo useradd --no-create-home --shell /usr/sbin/nologin lighthouse
sudo mkdir -p /var/lib/geth /var/lib/lighthouse
sudo chown geth:geth /var/lib/geth
sudo chown lighthouse:lighthouse /var/lib/lighthouse

Open the peer-to-peer ports and nothing else:

sudo ufw allow 30303 comment 'geth p2p'
sudo ufw allow 9000 comment 'lighthouse p2p'
sudo ufw allow 9001/udp comment 'lighthouse quic'

Ports 8545 (JSON-RPC) and 8551 (engine API) stay closed to the outside; both bind to localhost in the units below.

2. Install Geth

sudo add-apt-repository -y ppa:ethereum/ethereum
sudo apt update
sudo apt install -y ethereum
geth version

3. Install Lighthouse

Lighthouse ships as a static binary. This snippet always fetches the latest release:

LH=$(curl -s https://api.github.com/repos/sigp/lighthouse/releases/latest | grep -m1 '"tag_name"' | cut -d '"' -f 4)
curl -LO "https://github.com/sigp/lighthouse/releases/download/${LH}/lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
tar xzf "lighthouse-${LH}-x86_64-unknown-linux-gnu.tar.gz"
sudo mv lighthouse /usr/local/bin/
lighthouse --version

Verify the download: each release page lists SHA-256 checksums and a PGP signature; run sha256sum and compare, or import Sigma Prime’s key and use gpg --verify. Swapped binaries are a real attack vector, and the check takes a minute.

4. Create the JWT secret

sudo mkdir -p /var/lib/jwt
openssl rand -hex 32 | sudo tee /var/lib/jwt/jwt.hex > /dev/null

Both clients read this file. If they see different secrets, they refuse to talk to each other (see troubleshooting).

5. systemd unit for Geth

Create /etc/systemd/system/geth.service:

[Unit]
Description=Geth execution client (mainnet)
After=network-online.target
Wants=network-online.target

[Service]
User=geth
Group=geth
Type=simple
Restart=always
RestartSec=5
TimeoutStopSec=600
ExecStart=/usr/bin/geth \
  --mainnet \
  --syncmode snap \
  --datadir /var/lib/geth \
  --http --http.addr 127.0.0.1 --http.port 8545 \
  --http.api eth,net,web3,txpool \
  --authrpc.addr 127.0.0.1 --authrpc.port 8551 \
  --authrpc.vhosts localhost \
  --authrpc.jwtsecret /var/lib/jwt/jwt.hex

[Install]
WantedBy=multi-user.target

TimeoutStopSec=600 matters: Geth flushes state to disk on shutdown, and killing it early is the classic way to corrupt the database.

6. systemd unit for Lighthouse

Create /etc/systemd/system/lighthouse.service:

[Unit]
Description=Lighthouse consensus client (mainnet)
After=network-online.target geth.service
Wants=network-online.target

[Service]
User=lighthouse
Group=lighthouse
Type=simple
Restart=always
RestartSec=5
ExecStart=/usr/local/bin/lighthouse bn \
  --network mainnet \
  --datadir /var/lib/lighthouse \
  --execution-endpoint http://127.0.0.1:8551 \
  --execution-jwt /var/lib/jwt/jwt.hex \
  --checkpoint-sync-url https://mainnet.checkpoint.sigp.io \
  --http

[Install]
WantedBy=multi-user.target

The checkpoint sync URL lets Lighthouse start from a recent finalized state instead of replaying the beacon chain from genesis: seconds instead of days. You trust that endpoint for your starting point; cross-check the state root against a second source such as beaconstate.info if that bothers you.

7. Start and watch

sudo systemctl daemon-reload
sudo systemctl enable --now geth lighthouse
journalctl -fu geth

Geth first logs header downloads, then an endless stream of “Imported new chain segment” lines; Lighthouse reports synced slots within minutes. Check sync progress:

curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"eth_syncing","params":[],"id":1}' \
  http://127.0.0.1:8545

{"result":false} means fully synced. While syncing, you get a progress object instead.

How long does the sync take?

Ethereum has no official database snapshots to download, and it does not need them — the fast paths are built into the clients.

Lighthouse with checkpoint sync reaches the chain head in under a minute and backfills historical blocks in the background. Geth in snap sync mode (the default) pulls roughly 800 GB to 1 TB from the network and then rebuilds the state trie locally. On the recommended hardware, plan one to two days; on minimum hardware with a mediocre disk, three to five. The tail end is the “state heal” phase, and if it runs for days without finishing, your disk is too slow — see troubleshooting.

After the initial sync, things calm down. Since version 1.13, Geth prunes state on the fly (path-based state storage), so the database no longer grows without bound the way older guides warn. Geth 1.16 and later can also drop pre-merge history (--history.chain postmerge), which frees a few hundred GB if space gets tight.

Sync modes: snap, full and archive

The --syncmode flag in the Geth unit decides how much of the chain you verify yourself and how much disk you pay for. Three modes exist, and the right one follows from the questions you want the node to answer.

Snap sync is the default and what this guide uses. Geth downloads the current state directly from peers, verifies block headers back to genesis, then heals the state trie. Result: a serving full node in one or two days and a database of roughly 1.2–1.4 TB in mid-2026, growing from there.

Full sync (--syncmode full) re-executes every transaction since 2015 instead of downloading state. The end result on disk is the same pruned database, but the sync runs for weeks even on strong hardware. You choose it for one reason: you refuse to trust the state download and want the entire history recomputed on your own machine. That is a research position, not an operational requirement.

Archive mode sits on another axis: --gcmode archive on top of a full sync keeps every intermediate state instead of pruning. Only an archive node answers “what was this balance at block 15,000,000” or runs deep traces without recomputation, which indexers, tax tools and analytics platforms need. On Geth’s classic hash-based layout that costs well over 10 TB. Erigon and Reth store history differently and land archive nodes in the 2–3 TB range as of mid-2026, so nearly every new archive deployment starts with one of those two; Geth’s newer path-based archive mode plays in the same size class but has less production mileage.

For a payments backend, snap sync answers everything: current balances, new blocks, transaction receipts. Archive is for the day you need to reconstruct the past.

Client choice and diversity

Geth plus Lighthouse is a solid default, and its popularity is exactly the catch. Ethereum’s safety model assumes no client controls too much of the network: a consensus bug in a client with more than two thirds of validators could finalize a broken chain, the one failure the protocol cannot undo cleanly. Even a one-third share is uncomfortable, because that client failing alone would stop finality.

Where the network stands in mid-2026: Geth still leads the execution layer with a share that measurements put between a third and roughly 40 percent, Nethermind follows in the twenties to thirties, Besu and Reth hold low double digits, Erigon a few percent. On the consensus side, Lighthouse has grown past the one-third comfort line by most counts, with Prysm second and Teku and Nimbus behind. The network gets safer every time an operator picks a minority client, and the operator gives up little — all execution clients speak the same JSON-RPC, all consensus clients the same beacon API.

Late 2025 made the argument concrete. Shortly after the Fusaka upgrade, a bug in one widely used consensus client forced emergency patches, while nodes on the other clients kept validating without interruption. Operators on minority pairings read about that incident instead of managing it.

For a first node, the pairing in this guide is fine. For a second node, or anything professional, pick a minority pairing such as Nethermind with Teku or Reth with Nimbus. The setup above translates almost one to one — every pairing needs the same JWT secret and engine-API wiring; only binaries, flags and data directories change.

What running an Ethereum node costs

No exact prices here; they change monthly and vary by country. Instead, the calculation to run yourself.

Own hardware: a mini-PC in the requirements class (8 cores, 32 GB RAM, 2–4 TB NVMe) is a one-off purchase in the mid hundreds of euros. Power draw sits around 30–60 W. The math: 0.03–0.06 kW × 720 h ≈ 20–45 kWh per month; multiply by your electricity rate. At 0.30 €/kWh that is 6–13 € per month on top of the internet connection you already pay for.

Rented server: VPS plans with an honest 2 TB of NVMe are rare, so in practice you land on an entry-level dedicated server. That puts you in the low three-digit euro range per month — an order of magnitude, not a quote. Cloud instances with provisioned IOPS cost noticeably more than the equivalent dedicated box.

Your time: first setup is an afternoon with this guide; ongoing, client updates and an occasional look at the logs, call it an hour per month. If you bill your time, that line belongs in the total too.

Monitoring and health checks

Three questions cover node health: is the process running, is it synced, does it have peers. systemd answers the first with systemctl is-active geth lighthouse. The other two have endpoints on both layers:

# execution: peer count as hex; eth_syncing from step 7 covers sync state
curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","method":"net_peerCount","params":[],"id":1}' \
  http://127.0.0.1:8545

# consensus: HTTP 200 = synced, 206 = still syncing
curl -s -o /dev/null -w '%{http_code}\n' \
  http://127.0.0.1:5052/eth/v1/node/health

Lighthouse’s REST API listens on port 5052 through the --http flag already in the unit. The /eth/v1/node/health endpoint encodes sync state in the HTTP status code, which makes it a natural probe for scripts and load balancers; /eth/v1/node/syncing returns the distance in slots if you want the number. A cron job running these checks plus df -h /var/lib/geth, mailing on anomalies, is complete monitoring for a personal node.

For dashboards, add --metrics to Geth (Prometheus endpoint on port 6060) and --metrics to Lighthouse (port 5054), keep both on localhost, and import the Grafana dashboards both projects publish. Whatever you build, set two alerts before all others: disk usage above 85 percent, and block height flat for ten minutes. Those two catch nearly every real failure before your users do.

Maintenance and upgrades

Client updates are not optional. Hard forks require new software, and a node on an old version simply stops following the chain at the fork block. Subscribe to the Geth and Lighthouse release feeds on GitHub and to the Ethereum Foundation blog — the network currently ships about one major upgrade per year, with client releases in between.

The procedure stays short. Geth from the PPA updates with sudo apt upgrade and sudo systemctl restart geth; confirm with geth version. Lighthouse is a single binary: repeat the download from step 3, replace /usr/local/bin/lighthouse, restart the unit. Read the release notes before restarting — flags get renamed occasionally, and a renamed flag in a systemd unit means a service that refuses to start at 2 a.m.

Budget for disk growth as well. A Geth full node adds on the order of 10–15 GB per week in mid-2026; Lighthouse grows more slowly. On a 2 TB drive that is a countdown you can reset — pre-merge history expiry frees a few hundred GB (see troubleshooting), and a fresh snap sync rebuilds a fully compacted database in one or two days. On 4 TB, growth is an annual line item instead of a quarterly problem. The node does not have to be online every second, but the longer it is offline, the longer it needs to catch up.

A full node is not a validator

The 32 ETH everyone has heard about belongs to staking, not to node-running. The node in this guide needs no ETH at all — it validates blocks in the sense of checking them, which costs hardware, not stake.

A validator is a third program next to the two clients: it holds signing keys, produces attestations and blocks, and earns rewards for it, with a fee-recipient address configured for the income. The 32 ETH is collateral the protocol can slash for provable misbehavior. The operational bar moves too — an RPC node that spends a weekend offline just catches up on Monday, while a validator offline bleeds small penalties every epoch.

With less than 32 ETH, pooled staking is the entry: Rocket Pool and similar protocols let permissionless operators run validators with a smaller bond, and some pool setups run on exactly the node built above. A plain full node earns nothing. You run it for independence and privacy, for development, or as the base a validator stands on later.

Security: the port layout is the policy

The whole security model of this setup is visible in the firewall rules from step 1. Ports 30303 and 9000/9001 are open because peer-to-peer needs strangers; 8545 and 8551 bind to 127.0.0.1 because nothing outside the machine has business there. The JWT secret authenticates the engine API on 8551, but treat it as a second layer, not as a reason to expose the port.

An open 8545 is the worse mistake, because JSON-RPC has no authentication at all. Scanners find exposed Ethereum RPC ports fast, and the damage goes beyond freeloading: with the wrong namespaces enabled, outsiders get debugging internals and mempool contents they should never see. Keep --http.api at the four namespaces from the unit; admin, debug and personal stay off any machine whose RPC port might ever be reachable.

When other machines legitimately need the RPC, tunnel instead of exposing: WireGuard or an SSH tunnel for yourself, nginx or Caddy with TLS and an IP allowlist for a small team. The clients already run as no-login system users from step 1, so a compromised client process has no shell account to inherit. Add unattended-upgrades for OS patches, and the boring part of server security takes care of itself.

Troubleshooting

Lighthouse cannot reach Geth (“Unable to connect to execution endpoint”)

Either Geth is down (systemctl status geth) or the JWT secrets differ. Confirm both units point to the same jwt.hex path. When in doubt, regenerate the secret once and restart both services.

Geth hangs in “State heal in progress” for days

The state-heal phase chases the chain head, and a disk with weak random-write performance never catches up. Benchmark with fio; you want tens of thousands of 4k IOPS. SATA SSDs and default cloud volumes are the usual culprits. The fix is real NVMe storage — no flag rescues a slow disk.

Peer count stays at zero

Port 30303 (TCP and UDP) is blocked or not forwarded through your NAT. Also check the system clock: timedatectl should show active NTP sync, because a skewed clock breaks peer handshakes on the consensus side.

The disk fills up

Find the growth first: du -h --max-depth=2 /var/lib/geth. A datadir created before Geth 1.13 still uses the old hash-based layout; the clean fix is a fresh resync, after which state stays pruned automatically. Enabling pre-merge history expiry frees a few hundred GB more, and the ancient store can move to a cheap HDD via --datadir.ancient.

Geth reports database corruption after a crash

Power loss, kill -9 or an OOM kill mid-write leaves log lines about corruption or missing data at the next start. Sometimes a restart heals it; if the log loops, stop repairing and resync — move the datadir aside, start fresh, and snap sync rebuilds everything in one or two days, usually faster than any recovery attempt. Prevention is in the unit already: TimeoutStopSec=600 gives Geth time to flush, and a clean systemctl stop is the only way the process should ever end.

The OOM killer terminates Geth

journalctl -k | grep -i oom confirms the suspicion. Geth’s --cache defaults to 4096 MB on mainnet and real usage peaks above the setting during sync; add Lighthouse and the operating system, and a 16 GB machine runs out. Set --cache 2048 on small machines and keep a swap file as a buffer — slow beats killed, because a killed Geth flushes nothing and invites the corruption case above.

FAQ

What is an Ethereum node in simple terms?

A computer that keeps its own verified copy of the Ethereum blockchain and lets you read the chain and send transactions without asking anyone’s permission. Technically it is two cooperating programs: an execution client and a consensus client.

How much disk space does an Ethereum node need in 2026?

A full node with Geth and Lighthouse uses about 1.4–1.6 TB combined. A 2 TB NVMe drive is the working minimum, 4 TB the comfortable choice.

Can I run an Ethereum node on a Raspberry Pi?

Yes — Ethereum on ARM images run full nodes on Raspberry Pi 5 class boards with NVMe storage. Expect a slower initial sync and no headroom for heavy RPC loads. As a personal node it works; as production infrastructure it does not.

Does running an Ethereum node pay anything?

No. Rewards go to validators, which require 32 ETH staked on top of a running node, or participation in a staking pool. A plain full node contributes to network health and gives you trustless access, but earns nothing.

Do I have to open ports on my router?

For a healthy peer count, forward 30303 for Geth and 9000/9001 for Lighthouse; without them the node still syncs, just slower. Never expose 8545 or 8551 to the internet.

Run your own node — or use an API?

An honest comparison, since Chaingateway sells the alternative.

The node wins when you need heavy, sustained raw JSON-RPC: archive queries, tracing, mempool watching, or maximum privacy and censorship resistance. A node is a fixed cost with unlimited requests — at the low three-digit euro figure per month from the cost section, it undercuts any metered RPC offering once your volume is high enough. It is also the best way to understand how Ethereum actually works.

The API wins when the node would only be a means to an end, which for most businesses means payments. A synced node gives you eth_sendRawTransaction and event logs. It does not give you deposit addresses per customer, notifications when an ERC-20 payment arrives, key management or retry logic. That is application software you would have to build and operate on top, and it usually costs more hours than the node itself.

Chaingateway’s Ethereum API is that missing layer: create and import addresses (POST /api/v2/ethereum/addresses/import), send ERC-20 tokens (POST /api/v2/ethereum/transactions/erc20), and receive HMAC-signed webhooks for incoming deposits — failed deliveries land in a queryable list (GET /api/v2/ethereum/webhooks/notifications/failed) and can be resent through the retry endpoint. The break-even is arithmetic: server cost plus your build-and-operate hours versus a plan on /pricing/. For payment flows, the API side of that inequality stays smaller until well past hobby scale; for raw RPC consumption, the node side wins early. Start with the quickstart and the webhook guide — the 7-day trial without KYC is enough to test a deposit flow end to end (register here).

Running other chains too? See the guides for BNB Smart Chain and TRON.