How to Run Your Own Base Node

A Base node gives you a private, unmetered endpoint on chain ID 8453. Like every OP Stack chain it runs two services — an execution client and a rollup/consensus driver — plus one dependency people underestimate: a synced Ethereum L1 endpoint (execution and beacon) that your node reads constantly. This guide is the official Docker-based mainnet setup on Ubuntu.

Hardware requirements

Step 1: clone the official repo and configure L1

Base ships its node as a docker-compose project (standalone binaries exist on the releases page if you prefer bare-metal, but the documented path is Docker):

git clone https://github.com/base/node.git base-node && cd base-node

# .env.mainnet — set your L1 endpoints:
BASE_NODE_L1_ETH_RPC=<your Ethereum execution RPC>
BASE_NODE_L1_BEACON=<your Ethereum beacon endpoint>

The L1 endpoints are not a formality: your node reads L1 continuously to derive the Base chain, and the docs warn that initial sync “will consume a vast amount of your requests quota” on third-party L1 providers — a flat-rate Ethereum RPC endpoint (or your own Ethereum node) saves real money here. One security note: the committed .env.mainnet ships a default, publicly known JWT secret for the internal engine API — fine inside the compose network, but generate your own if you ever expose those ports.

Step 2: bootstrap from a snapshot

Don’t sync from genesis — the docs push snapshots hard, and downloads now go through the client CLI (the old tarball endpoints are being decommissioned). Pick your node type carefully — it cannot be changed after the initial sync:

mkdir ./reth-data
base-reth-node download --chain base --full --datadir ./reth-data --resumable

Step 3: start and verify

docker compose up --build -d

# latest block from the execution client:
curl -s -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":0,"method":"eth_getBlockByNumber","params":["latest",false]}' \
  http://localhost:8545

# how far behind the chain tip (rollup RPC on 7545):
echo Behind by: $((($(date +%s)-$(curl -s -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":0,"method":"optimism_syncStatus"}' \
  http://localhost:7545 | jq -r .result.unsafe_l2.timestamp))/60)) minutes

# right chain?  0x2105 = 8453
curl -s -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]}' http://localhost:8545

Ports: execution RPC on 8545 (WS 8546), the rollup RPC on 7545 (not op-node’s old 9545), p2p ingress on 30303 and 9222 (TCP+UDP). Keep the RPC ports private. Note your node is a follower: it forwards transactions to Base’s sequencer and cannot build blocks itself — that’s the OP Stack trust model, not a misconfiguration.

What it really costs to run

• Mandatory upgrades on a monthly cadence. Mid-2026 alone: Azul (May 28 deadline), Beryl (June), and a required storage migration by mid-August. Each release names a date; miss it and your node stops following the chain.
• Storage migrations sometimes mean re-downloading. Base’s own guidance for the recent Reth storage change: a fresh snapshot is faster than migrating your existing data. Budget for multi-TB re-bootstraps as a recurring event, not a one-off.
• You’re running Ethereum infrastructure too. The L1 execution + beacon dependency means either a second server (your own Ethereum node) or a paid L1 endpoint whose quota your sync will chew through.
• The node-type decision is permanent. Archive ↔ full ↔ minimal conversions are unsupported — choose wrong and you re-sync from scratch.
• One node is a single point of failure. Production wants redundancy, health checks, and a freshness check — see Self-Hosted Node vs RPC Provider for the full math.