Base Node: Run Base Node with Docker
/node
Base Node is the Docker Compose setup in base/node for running your own execution and consensus clients against the Base L2 network. It pairs base-reth-node with base-consensus and expects you to supply an Ethereum L1 RPC and beacon endpoint yourself. Run it if you need direct, unrestricted access to Base chain state; skip it if a hosted RPC endpoint already covers your traffic, since the README ships the software with no warranty attached.
What is a Base Node?
Base Node is the name for base/node's Docker setup that runs a full Base L2 node using base-reth-node as the execution client and base-consensus as the consensus client. It connects to an Ethereum L1 RPC and beacon endpoint that you supply yourself, rather than bundling an L1 node of its own, and covers both the Base mainnet and Base Sepolia networks.
Key Features for Node Operators
- ✓Docker Compose stack pairing base-reth-node (execution) with base-consensus (consensus), so the two clients start together instead of being wired up by hand.
- ✓Mainnet and Base Sepolia testnet support, switched between .env.mainnet and .env.sepolia via the NETWORK_ENV variable.
- ✓Flashblocks mode: setting RETH_FB_WEBSOCKET_URL switches the execution client into Flashblocks mode, queryable through eth_getBlockByNumber with a pending block tag on port 8545.
- ✓Follow mode through BASE_NODE_SOURCE_L2_RPC, for syncing from another L2 RPC source instead of the network's own peers.
- ✓Pruning control via RETH_PRUNING_ARGS to limit how much chain history the execution client retains.
- ✓Snapshot-assisted sync, with restore links and steps documented at docs.base.org instead of syncing from genesis.
Getting Started with Base Node
Clone base/node, then pick a network: use .env.mainnet for Base mainnet or .env.sepolia for Base Sepolia. Set BASE_NODE_L1_ETH_RPC and BASE_NODE_L1_BEACON in that file to point at an Ethereum L1 RPC and beacon endpoint you already control — base/node doesn't bundle an L1 node, so you need one first. Then run `docker compose up --build` for mainnet, or `NETWORK_ENV=.env.sepolia docker compose up --build` for Sepolia. Docker and Docker Compose both need to be installed on the host beforehand. For faster sync, docs.base.org documents how to restore from a chain snapshot instead of syncing from genesis.
Configuring Your Base Node
Four settings drive the node: BASE_NODE_L1_ETH_RPC and BASE_NODE_L1_BEACON point at your L1 node, while BASE_NODE_NETWORK and RETH_CHAIN pick the network — both set to `base` for mainnet or `base-sepolia` for Sepolia. Each network has its own sequencer endpoint too (mainnet-sequencer.base.org or sepolia-sequencer.base.org). Beyond that baseline, three optional variables change behavior: RETH_FB_WEBSOCKET_URL turns on Flashblocks mode, BASE_NODE_SOURCE_L2_RPC enables follow mode against another L2 RPC, and RETH_PRUNING_ARGS trims how much history the execution client keeps. The full list of options lives in .env.mainnet and .env.sepolia, not in the README itself.
Strengths
- ✓One Docker Compose stack pairs base-reth-node and base-consensus, so you aren't wiring an OP Stack execution/consensus pair together by hand.
- ✓Production hardware is documented concretely (AWS i7i.12xlarge, RAID 0 of local NVMe drives, ext4) rather than left vague.
- ✓Flashblocks, follow mode, and pruning are each exposed as a single environment variable instead of requiring config-file surgery.
- ✓Snapshot support cuts initial sync time versus starting from genesis.
- ✓MIT license, so there's no restriction on how you deploy or modify the setup.
Hardware and Software Requirements
- △Minimum spec is a modern multicore CPU, 32GB RAM (64GB recommended), and an NVMe SSD — no low-resource install path is documented.
- △Storage isn't a fixed number: it's sized as roughly twice the current chain size plus the snapshot size plus a 20% buffer, so you calculate it yourself against base.org/stats and basechaindata.vercel.app.
- △Docker and Docker Compose are hard prerequisites; there's no documented bare-metal or non-container install path.
- △You need your own Ethereum L1 RPC and beacon endpoint before you start — base/node doesn't include an L1 node.
- △The README's disclaimer offers the software with no warranty, calling it an 'as is' release with no assurance around protecting assets or their security, and notes usage falls under whatever laws apply to you.
Alternatives to Self-Hosting a Node
Frequently Asked Questions
Base Node's documented minimum is a modern multicore CPU, 32GB RAM (64GB recommended), an NVMe SSD, Docker plus Docker Compose, and storage sized at roughly twice the current chain size plus the snapshot size plus a 20% buffer.
Base Node supports both Base mainnet and Base Sepolia testnet, switched by choosing .env.mainnet or .env.sepolia and setting BASE_NODE_NETWORK and RETH_CHAIN to base or base-sepolia.
Base Node can sync from a snapshot instead of from genesis, which shortens the initial sync; docs.base.org lists the snapshot links and restore steps.
Base Node runs base-reth-node as the execution client and base-consensus as the consensus client, bundled together in the repository's Docker Compose setup.
Base Node ships with no warranty: the README's disclaimer offers it as an 'as is' release, giving no assurance around asset protection or security, with usage subject to whatever laws apply.
Base Node's README directs operators to the node-operators channel on its Discord server, or to opening a new issue on the GitHub repository if Discord isn't an option.
The problem it solves
Running Base-dependent infrastructure without your own node means trusting a third party for every read against Base state, and matching whatever client version and configuration that provider chooses to run. base/node packages base-reth-node and base-consensus into one Docker Compose stack pointed at your own L1 endpoints, so operators who need direct control over sync state, historical queries, or Flashblocks pending-block data aren't stuck wiring an OP Stack node pair together from scratch.
Best use cases
- •Teams running Base-dependent infrastructure (indexers, block explorers, bridges) that need direct RPC access instead of routing every call through a third-party provider.
- •Developers testing Flashblocks pending-block responses by setting RETH_FB_WEBSOCKET_URL and querying eth_getBlockByNumber with the pending tag.
- •Operators running Base Sepolia locally for testnet development, switching networks with NETWORK_ENV=.env.sepolia.
- •Anyone syncing from a chain snapshot instead of genesis to cut initial sync time, per the docs.base.org restore steps.
Who should try it — and who should skip
Try Base Node if you're operating infrastructure that reads Base chain state constantly — an indexer, a bridge, a block explorer — and the recurring cost or rate limits of a hosted RPC provider outweigh running your own 32GB+ RAM, NVMe-backed box. Skip it if you just need occasional Base RPC calls for a small app: standing up an L1 RPC and beacon endpoint plus the storage math the README lays out is a lot of infrastructure to own for light traffic. Treat the disclaimer's lack of warranty as a real operational fact, not boilerplate, if you're running this anywhere near production.
Curious whether node is right for you?
Let ChatGPT, Claude, or Perplexity look into it — click below and see what AI actually says about node.