Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.novacula.io/llms.txt

Use this file to discover all available pages before exploring further.

Ethereum is the only multi-process chain in Novacula. Every Ethereum node is two processes: an execution-layer (EL) client and a consensus-layer (CL) client. They communicate over the JWT-authenticated Engine API on 127.0.0.1:8551. The chain adapter generates a JWT secret on first start, configures both processes to use it, and exposes them as two roles in the UI.

​
Networks and resources

NetworkCPURAMDisk (Full)Notes
mainnet4 cores16 GiB2548 GiBEL + CL share one PVC; subdirs /data/el and /data/cl
sepolia2 cores8 GiB300 GiB
hoodi2 cores8 GiB300 GiBNew testnet; minimum client versions enforced
Hoodi enforces these minimum client versions (rejected at deploy time if violated):
ClientMinimum
Geth>=1.15.0
Reth>=2.0.0
Nethermind>=1.31.9
Erigon>=3.0.2
Prysm>=7.1.0
Archive node disk requirement is significantly higher than Full — the adapter pre-fills with the right value when you select Archive in the wizard.

​
Clients

RoleClients
ELgeth, reth, nethermind, erigon
CLlighthouse, prysm, lodestar
Pick one of each independently in the deploy wizard. All EL × CL combinations are supported; pick the pair your team has the most operational experience with.

​
Ports

NamePortOwner
EL RPC (HTTP)8545EL
EL RPC (WebSocket)8546EL
EL P2P30303EL
Engine API8551EL ↔ CL (JWT-secured, localhost)
EL metrics6060EL
CL beacon API5052CL
CL P2P9000CL
CL metrics5054CL
Engine API is bound to 127.0.0.1 and not user-overridable. EL and CL P2P need to be reachable from peers; if you’re behind NAT, configure your firewall accordingly.

​
Init steps

On first reconcile per node:
  1. JWT secret — generated and written to a path both processes can read; injected into both clients’ command lines.
  2. Checkpoint sync URL (CL only, optional) — the adapter knows trusted defaults for mainnet (sigp), hoodi, and sepolia (ethpandaops). Override with the --checkpoint-sync-url (--checkpointSyncUrl for Lodestar, plus --genesis-beacon-api-url for Prysm) free-form arg.

​
Config overrides

Ethereum uses CLI argument overrides per process. The adapter declares managed flags per client (the obvious data-dir / port / Engine API / JWT bindings) and a small set of known flags:
  • All CL clients accept --checkpoint-sync-url (Prysm: --checkpoint-sync-url + --genesis-beacon-api-url; Lodestar: --checkpointSyncUrl) — first-class field in the deploy wizard.
  • Anything else not on the managed list is passed through to the underlying binary.
For the full managed-flag list per client, see the per-client schemas in packages/adapter/src/ethereum/<client>.ts.

​
Sync strategies

  • Full from genesis — slow but no trust assumptions on the CL side.
  • Checkpoint sync (CL) — fast: CL fetches a recent finalized state from a trusted checkpoint URL, then EL syncs using the snap-sync flow. This is the default for new mainnet deployments.
  • Snapshot restore (EL) — replace EL data directory with a pre-synced snapshot from your own infrastructure. Manual step.
The first two are first-class. Snapshot restore is supported but you provide the snapshot.

​
Metrics

Both processes are scraped on each reporter tick. Surfaced:
  • Per-process status (starting / running / syncing).
  • EL: chain head, peer count, sync progress.
  • CL: head slot, current epoch, validator count, peers.
  • Per-process CPU + memory.
  • Disk usage for the shared PVC.
See Node monitoring.

​
Common patterns

  • RPC provider (the typical case) — Geth, Reth, Nethermind, or Erigon in Full mode + the CL of your choice; expose :8545 (HTTP) and :8546 (WS) through your own reverse proxy or load balancer.
  • Archive — Geth or Erigon in Archive mode; substantially larger disk, considerably longer initial sync. Use for historical RPC (eth_getBalance at old blocks, debug/trace APIs).
  • Beacon endpoint for an external validator client — run a Full node here, then point your separately-operated validator client at the CL’s beacon API on :5052. The platform itself does not manage the validator client; it just runs the EL + CL pair beneath it.