Base node requirements in 2026: hardware, Reth, snapshots and L1

A Base node needs a modern CPU with 8 or more cores and good single-core performance, at least 32 GB of RAM (64 GB recommended), locally attached NVMe, and an Ethereum L1 RPC plus a beacon endpoint. Reth is now the only supported client. On October 15, 2026, Base’s full snapshot was 902 GB and its archive snapshot 4.2 TB.

The official Base node requirements

Base publishes its hardware guidance on its Node Performance page, with networking and L1 details in the run-a-node tutorial. Verified on October 15, 2026:

For scale, Base runs its own Reth archive nodes on AWS i7i.12xlarge instances or larger, which AWS lists with 48 vCPUs, 384 GiB of memory and 3 × 3,750 GB of local NVMe, striped as RAID 0 with ext4. Base also warns that if you don’t already know why you need your own node, you probably don’t: its public endpoint, mainnet.base.org, works for getting started but is rate-limited and not meant for production apps.

Base node with Reth: the only client left

Base’s performance page calls Reth “currently the most performant client” for Base, and the choice has since become mandatory. The Azul upgrade, live on mainnet since May 28, 2026, is supported only by base-reth-node and base-consensus; nodes on op-geth or Nethermind must start fresh with base-reth-node, ideally from a Reth snapshot, and op-node gives way to base-consensus. Beryl, live since June 25, made Reth V2 the reference execution client; mainnet operators had to migrate to V2 storage by mid-August, and Base is decommissioning V1 snapshots.

The code moved too. As of v1.3.0, the operator node is published from the base/base repository as the ghcr.io/base/node image, and the old base/node repository was archived on September 4, 2026. The current release, v1.5.0, shipped on October 14, 2026.

Base archive node size vs full node: how much disk?

Base publishes snapshots, updated weekly, that skip most of the initial sync. The presets on chain.base.org/snapshots on October 15, 2026, at mainnet block 52,616,526:

Base warns that extracted data is “significantly larger” than the download. Its stats page, which the docs cite for the current chain size, did not expose that figure in a form we could verify, so the last column applies Base’s formula with each snapshot’s size standing in for the chain size, adding 20% to the total. Treat those numbers as floors.

• The node type is fixed at the first sync. Turning an archive node into a pruned one, or a pruned node into a full one, is not supported, and custom pruning through RETH_PRUNING_ARGS requires starting from the archive snapshot.
• How much history “full” keeps is in flux. Base’s snapshot FAQ says Reth’s full preset retains the last 10,064 blocks, about 5–6 hours on Base, while the v1.3.0 release notes of September 1, 2026 say the full preset now keeps one month of history. Check the notes for the release you deploy.
• Historical proofs cost extra. Serving eth_getProof and related methods efficiently needs the proofs extension, which Base says adds hundreds of gigabytes, needs higher I/O and takes 24–48 hours to backfill on mainnet unless restored from a proofs snapshot. Most operators do not need it.

The L1 requirement: an Ethereum RPC and a beacon endpoint

A Base node derives its chain from data posted to Ethereum, so it needs two L1 endpoints in .env.mainnet: BASE_NODE_L1_ETH_RPC, an Ethereum full node RPC, and BASE_NODE_L1_BEACON, a beacon node. Base’s derivation spec fetches batch data posted as blobs through the beacon API’s /eth/v1/beacon/blob_sidecars/ endpoint and recommends a local beacon node for it.

You can rent both endpoints, but Base warns that syncing “may take days” and “will consume a vast amount of your requests quota”. Running your own L1 node avoids the quota, but it must be fully synced first: Base cannot finish syncing until its L1 node has. Its hardware is a separate budget: an execution client and a consensus client with their own NVMe, described in our Ethereum node hardware guide. On one server, add the two disk budgets together.

CPU, RAM and the move to 200 ms blocks

Base asks for 8 or more cores with good single-core performance and 32 GB of RAM, 64 GB recommended. Its troubleshooting guide adds that disk I/O is often the bottleneck when a node syncs slowly, which is why it insists on local NVMe. We would treat RAM above the minimum as headroom for RPC load and the operating system’s file cache rather than as a requirement.

Load per second is about to change. The Denim upgrade replaces one block every two seconds with five canonical blocks per second, and replaces Flashblocks along the way. It activates on Base Sepolia on October 21, 2026, and Base is targeting November 2026 for mainnet. Base gives no new hardware figures for it, so we suggest leaving CPU and disk headroom and re-checking growth after activation rather than sizing for today’s chain.

Ports and bandwidth

Blocking outbound 9200 and 30301 leaves a node with zero peers, and network ACLs, unlike stateful firewalls, also need the ephemeral range 32768–60999 open outbound. Base publishes no bandwidth figure. The one large transfer you can predict is the initial snapshot: at a sustained 1 Gbps the full preset takes about two hours and the archive about nine. Base’s downloader runs 8 parallel transfers by default and suggests twice the number of physical cores on bigger machines, so on an unmetered 10 Gbps port the snapshot server, rather than your link, is likely to set the pace.

Which PowerDedi server for a Base node

Three honest caveats. First, the archive fit is tight. The EPYC 9555P should hold today’s archive with room to spare, since Base’s own archive nodes start at 11.25 TB of NVMe, but it only just clears the formula’s floor, and the extracted chain is larger than the snapshot; adding proofs raises the floor to about 18.4 TB. The only configuration we sell with more NVMe is the EPYC 9965 ($1,790/mo, 4 × 7.68 TB, delivered in 72 hours), whose 2.25 GHz base clock runs against Base’s single-core advice. Second, every fit above assumes striped drives, which Base itself uses: one failed drive means a fresh snapshot restore, so keep your configuration scripted; our software RAID guide covers the layouts. Third, if you only need to read Base or send transactions, an RPC provider is enough.

How to run a Base node: setup outline

These commands come from Base’s documentation and the base/base README; replace the L1 placeholders with your endpoints.

# 1. Install the release binaries, including the base-reth-node CLI
curl -fsSL https://raw.githubusercontent.com/base/base/main/baseup/install | bash

# 2. Get the operator compose file and environment templates
git clone https://github.com/base/base.git
cd base
# In .env.mainnet, set BASE_NODE_L1_ETH_RPC and BASE_NODE_L1_BEACON

# 3. Restore a snapshot (--minimal, --full or --archive)
mkdir ./reth-data
base-reth-node download --full --datadir ./reth-data --chain base --resumable

# 4. Start the node (pin a release with NODE_TAG=vX.Y.Z)
docker compose up

# 5. Check that the RPC answers
curl -d '{"id":0,"jsonrpc":"2.0","method":"eth_getBlockByNumber","params":["latest",false]}' -H "Content-Type: application/json" http://localhost:8545

Follow the logs with docker compose logs -f execution and docker compose logs -f node, keep ports 8545, 8546 and 7545 off the public internet with our first-hour hardening checklist, and see blockchain node hosting for current stock.

Sources

• Node Performance — Base documentation
• Run a Node — Base documentation
• Node Snapshots and Node Troubleshooting — Base documentation
• Snapshots — Base (checked October 15, 2026)
• Node Upgrade Guide and Upgrades — Base documentation
• Derivation (Ecotone upgrade) — Base documentation
• base/base releases (v1.3.0 to v1.5.0) and .env.mainnet — Base on GitHub
• Amazon EC2 I7i instances — Amazon Web Services