Ethereum

Every Ethereum node is two roles: an execution-layer (EL) client and a consensus-layer (CL) client, deployed and managed together. They talk over the JWT-authenticated Engine API, which Novacula sets up and secures for you; the node page shows them as two roles. To deploy one, open Deploy Node, pick Ethereum, then choose a network, an EL client, and a CL client. The wizard offers exactly the networks, clients, and versions your target executor declares — if a client or version isn’t listed, that executor can’t run it.

​

Networks

Ethereum nodes run as Full nodes; see Node types for the blob-serving variant.

​

Node types

• Full (full) — the default: recent state, the standard RPC surface.
• Blob-serving (blob-serving) — the same full node, but Lighthouse runs with --supernode so the beacon keeps every blob. Pick it for an Ethereum node that will serve as the L1 of a Base or Robinhood Chain node — an L2 can’t derive from a beacon that has dropped blobs. Everything else (clients, versions, resources, ports) is the same as Full. For a beacon you run elsewhere, --semi-supernode is enough too; Lighthouse’s blobs guide explains both flags.

​

Clients

Ethereum runs one EL client and one CL client, deployed together. Pick Geth or Reth as the EL; the CL is Lighthouse: Reth runs as a full node and serves HTTP JSON-RPC with the eth and net namespaces. On mainnet a fresh Reth node bootstraps from a recent snapshot published by the reth project before its first start, so it begins from recent chain data instead of syncing from genesis — the node reads Downloading snapshot while that runs (see Snapshot bootstrap). On sepolia a fresh Reth 2.6.0 node bootstraps from a PublicNode snapshot (older Reth versions there sync without one): if PublicNode has none for the node’s exact Reth version, the newest complete snapshot with the same major.minor and a newer patch is used, and if there’s none of those either, the bootstrap fails. Supported in-place update steps exist along both EL lines, so a deployed node can be moved forward without redeploying — see Update a node’s version.

​

Resources

Defaults are set per client and per network; total node footprint is the EL client plus the CL client. The wizard pre-fills these and lets you adjust CPU and memory before deploying. EL and CL each take a share of the node’s data volume. The wizard pre-fills these defaults and shows the exact numbers for your selection; for Reth it won’t accept less than 16 GiB of memory.

​

Ports

These are the endpoints you consume: HTTP JSON-RPC on :8545 from the EL, and the CL beacon API on :5052. The Engine API the two roles use to talk to each other is internal and managed by Novacula.

​

Sync

• Checkpoint sync (CL) — always on, managed automatically. The CL fetches a recent finalized state from a trusted checkpoint provider, then the EL completes a snap sync, so a new node syncs in hours rather than days. Novacula keeps several public endpoints per network in preference order and picks the first one that actually serves the finalized block and state as SSZ (each is probed for up to 10 seconds; the choice is reused for 5 minutes), so one provider disappearing or misbehaving doesn’t break a deploy. If none passes, the node fails with no usable checkpoint sync endpoint for <chain>/<network>; all candidates failed Lighthouse block/state probes rather than starting against a provider that can’t serve it.
• Use your own checkpoint provider — set the CL’s checkpoint sync URL override (see below) to point at a provider you trust instead of the one Novacula picks. This swaps the provider; it does not turn checkpoint sync off.

​

Configuration overrides

Ethereum clients are configured through command-line arguments — each role has its own argument list, set when you deploy the node. Novacula manages the data-dir, ports, Engine API, JWT, and metrics flags; try to set one and the form rejects it as “managed by Novacula”. Any other flag passes straight through to the client. The one CL flag the UI knows about by name is the checkpoint sync URL:

• Lighthouse: --checkpoint-sync-url

​

What you can build

• RPC provider (the common case) — a Geth or Reth EL paired with the Lighthouse CL, serving JSON-RPC on :8545.
• Beacon endpoint for an external validator — run the EL + CL pair, then point a separately-operated validator client at the CL beacon API on :5052. Novacula runs the node beneath your validator; it does not manage the validator client itself.

​

Monitoring

The node page shows per-role status, sync progress, peers, CPU, memory, and disk for both the EL and CL. See Node monitoring.