Skip to main content
Base is an OP-Stack L2 anchored on Ethereum. Every Base node runs two processes: a base-reth-node execution layer and a base-consensus rollup client. They talk to each other over a JWT-secured Engine API that the platform manages — you never set it. Sequencer URL and P2P peers are baked in per network, but the L1 endpoints base-consensus derives the rollup from are yours to provide — there is no public default (see L1 endpoints). Base runs either way on a bare-metal Agent — as systemd services or as Docker containers — and as pods on a Kubernetes Operator executor. Both clients ship as binaries and as images, so you pick the Runtime in the wizard’s Target step (defaults to Systemd). See Runtime.

​
Networks and resources

Base offers a single node type, full. The deploy wizard pre-fills resource and disk defaults per network and role:

​
Clients

One pinned client per role today. The deploy wizard offers exactly the client and version the executor declares.

​
Ports

The execution client answers the node’s primary RPC. The rollup RPC is a control-plane endpoint used by the platform’s health probe.

​
L1 endpoints (required)

base-consensus derives the L2 chain from Ethereum L1 — it does not sync purely from L2 peers. Unlike some rollups, Novacula supplies no public L1 fallback for Base: you must point the node at an Ethereum L1 yourself. A Base node needs two L1 endpoints:
  • Ethereum execution RPC (l1) — the L1 blocks the rollup reads.
  • Ethereum beacon REST (l1beacon) — the L1 consensus data, including blob data.
You supply both in the deploy wizard’s Connections step, and change them later on the node’s Connections tab. In this release the L1 endpoints are entered as external URLs — each must work without a password or API key. The beacon endpoint must come from a consensus client that keeps every blob — on Lighthouse that’s --supernode or --semi-supernode; a beacon node running without one of them can’t feed the L2. An Ethereum node you deploy on Novacula gets that flag when you pick the blob-serving node type in the wizard; expose its execution RPC and beacon API (without RPC-key auth) and enter those URLs. See Connections for the step, and Edit connections for changing them after deploy.
A Base node is only as reliable as the L1 behind it. If base-consensus stops making progress, the L1 endpoints are the first thing to suspect — a rate-limited or lagging L1 stalls the rollup even when the node itself is healthy. Prefer an Ethereum node you control over a shared public endpoint for a production Base node.
The related client flags (--l1-eth-rpc, --l1-beacon, and the Engine API wiring) are managed by the platform.

​
Config overrides

Base exposes no config override surface: the platform manages both clients’ flags — the P2P peers, the Engine API, and the L1 endpoints above — so a Base node is configured entirely by the choices you make in the wizard. See Edit a running node for what can change after deploy.

​
Sync

base-consensus fetches batches from L1 and base-reth-node applies them through the Engine API. The execution client bootstraps from a snapshot on its first start instead of syncing from genesis, which cuts initial sync time; the download runs once per data directory, so a node whose data directory has already been bootstrapped skips the step. A healthy, reachable L1 endpoint is the gating factor for progress after that — if base-consensus can’t reach L1, it can’t advance.

​
Monitoring

Status, height, peers, sync progress, and disk combine both processes’ readings — see Node monitoring. Sync progress reflects the execution layer’s real position, so a node whose base-reth-node is still behind is not reported as fully synced. The node’s Overview tab shows each observed L1 endpoint — its URL, its last check time, and its sync percentage, height, and lag when the upstream reports them. The Connections tab is where you change the endpoints.

​
Common patterns

  • RPC provider for Base mainnet — point the node at your own Ethereum L1, then serve the node’s HTTP RPC to your apps.