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 knownJWT 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 sequencerand 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.