base/node: The Archived Docker Setup for Running a Self-Hosted Base Node

What base/node Was and Why It Is Now Archived

Base is an Ethereum Layer 2 network built on Optimism's OP Stack. The OP Stack is a modular blockchain framework that separates execution and consensus into distinct components, which is why the Docker Compose setup in this repository runs two services. base/node was the Docker build repository that allowed developers and node operators to run their own Base node, pairing the base-reth-node execution client with a base-consensus container. The README opens with a caution block: the repository is archived and all development has moved to base/base. New installations and upgrades should use releases from that repository. The last push to base/node was on 2026-09-08. The most recent releases before the migration were v1.2.0 on 2026-07-22 and v1.1.1 on 2026-06-19. Running a node from this repository is no longer supported by the Base team; the documentation at docs.base.org covers the current node setup process.

The Docker Architecture: Execution and Consensus as Separate Services

base/node uses Docker Compose to run two containers from the same Dockerfile. The execution service runs the base-reth-node binary via bash ./execution-entrypoint, exposing port 8545 for RPC, 8546 for WebSocket, 7301 mapped to internal port 6060 for metrics, and 30303 for peer-to-peer traffic on both TCP and UDP. The node service runs the base-consensus binary via bash ./consensus-entrypoint, exposing port 7545 for RPC, 9222 for peer-to-peer, 7300 for metrics, and 6060 for pprof. Both services restart unless stopped. The docker-compose.yml uses an env_file directive pointing to NETWORK_ENV, which defaults to .env.mainnet and can be overridden to .env.sepolia. The Dockerfile builds both binaries from source using Rust with the mold linker for link-time performance, and it verifies each binary's commit hash before completing the build to confirm the exact source revision was used.

Configuring and Starting a Node

The README's Quick Start lists the required steps. First, obtain an Ethereum L1 full node RPC and beacon endpoint from your preferred provider, then set those values in the appropriate .env file:

BASE_NODE_L1_ETH_RPC=<your-preferred-l1-rpc>
BASE_NODE_L1_BEACON=<your-preferred-l1-beacon>

Then start the node. For mainnet:

docker compose up --build

For testnet (Sepolia):

NETWORK_ENV=.env.sepolia docker compose up --build

The four required configuration variables are BASE_NODE_L1_ETH_RPC, BASE_NODE_L1_BEACON, BASE_NODE_NETWORK (set to base or base-sepolia), and RETH_CHAIN (set to base or base-sepolia). The mainnet sequencer is at https://mainnet-sequencer.base.org and the Sepolia sequencer at https://sepolia-sequencer.base.org, as shown in the .env.mainnet and .env.sepolia files. The L1 RPC and beacon endpoints are not provided by the repository; operators must source them independently.

Hardware Requirements and Storage Projections

The README specifies minimum requirements for running a node: a modern multicore CPU, 32 GB of RAM (64 GB recommended), an NVMe SSD, and Docker with Docker Compose. The storage formula given is: two times the current chain size, plus the snapshot size, plus 20 percent buffer. Chain size is tracked externally at base.org/stats and snapshot size at basechaindata.vercel.app; both are referenced in the README but not quoted as fixed numbers. For production, the README documents that the Base team uses AWS i7i.12xlarge instances with a RAID 0 array of all local NVMe drives formatted as ext4. The i7i.12xlarge is a storage-optimized instance with multiple NVMe drives, chosen for the sustained random read and write throughput that a busy Base node requires. Running a node on insufficient RAM or rotating disk will degrade sync performance; the README states these hardware figures without documenting performance regression thresholds.

Optional Modes: Flashblocks, Follow, and Pruning

The repository supports three optional operating modes beyond the default. Flashblocks mode enables by setting RETH_FB_WEBSOCKET_URL; when set, the execution client runs in Flashblocks mode, which allows querying a pending block via the eth_getBlockByNumber RPC method with the pending parameter:

curl -X POST \
  --data '{"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["pending", false],"id":1}' \
  http://localhost:8545

Follow mode enables by setting BASE_NODE_SOURCE_L2_RPC, pointing the node at a source L2 RPC to follow. Pruning mode enables by setting RETH_PRUNING_ARGS with pruning arguments. All three are documented in the README under Configuration. When RETH_FB_WEBSOCKET_URL is not set, the execution client runs in standard mode without Flashblocks.

Snapshots and the Sync Time Trade-off

Starting a Base node from genesis requires syncing the full chain history, which takes considerable time depending on hardware and network conditions. The README documents that snapshots are available to reduce sync time, pointing to docs.base.org for snapshot links and restore instructions. Using a snapshot means starting from a known chain state and syncing only the blocks produced since the snapshot was taken. The storage sizing formula accounts for the snapshot as a separate term: operators need space for the chain data, the snapshot during restore, and a buffer. The README does not document the exact snapshot restore procedure inline; it defers to docs.base.org. Operators running a full archive node who need to verify chain history from genesis cannot use a snapshot without additional verification steps to confirm the snapshot's integrity matches the canonical chain state, since snapshots represent a trusted starting point rather than a cryptographically verified one.

Running Your Own Node versus Using Base's Public RPC

Base provides public RPC endpoints: mainnet at https://mainnet-sequencer.base.org and testnet at https://sepolia-sequencer.base.org, as defined in the repository's configuration. An application that only needs to read from or write transactions to the Base network does not need to run a node. Running a self-hosted node is relevant for several specific scenarios: an operator who needs guaranteed uptime independent of the public sequencer endpoints; an operator who needs to inspect local chain state without the rate limits that apply to shared public endpoints; or an infrastructure provider that needs to serve archive queries requiring full historical data. Self-hosting also means no dependency on a third-party RPC provider's reliability or pricing. The hardware and operational overhead is substantial: 32 GB RAM minimum, NVMe storage scaled to current chain size, and ongoing maintenance as the chain grows. The repository's disclaimer states the software is provided as-is with no warranty and no guarantees about asset protection or security, and that usage is subject to applicable laws and regulations.

Editorial conclusion

Anyone looking to run a Base node today should not start from base/node. The README explicitly directs new installations to the releases page of base/base. The base/node repository is archived and the last push was on 2026-09-08. Operators who built infrastructure from this repository should plan migration to base/base. The Docker architecture documented here, and the configuration variables it defines, may still be useful as a reference for understanding the separation of execution and consensus services, but the repository will not receive further updates.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes