Skip to main content
Ethereum is the only multi-process chain in Novacula. 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.

​
Clients

Ethereum runs one EL client and one CL client, deployed together. The offered pair is Geth (EL) and Lighthouse (CL): geth 1.17.3 + lighthouse 8.1.3 → geth 1.17.4 + lighthouse 8.2.0 is a supported in-place update step, 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.

​
Ports

These are the endpoints you consume: JSON-RPC on :8545 / :8546 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, so one provider disappearing doesn’t break a deploy.
  • 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) — the Geth EL paired with the Lighthouse CL, serving JSON-RPC on :8545 / :8546.
  • 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.