Skip to main content
Gnosis Chain is an EVM chain with the same post-merge shape as Ethereum. Every Gnosis 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. Gnosis is a container-only chain — both of its clients ship as images rather than binaries, so both roles always run as containers:
  • On a Kubernetes Operator executor, as pods in the cluster, like every other chain.
  • On a bare-metal Agent executor, as Docker containers on the host rather than as systemd services.
Deploying onto an Agent, the wizard’s Runtime field locks itself to Docker — Gnosis’s only valid runtime — so there’s nothing to choose. On an Agent Novacula installs the Docker engine for you before the node’s first launch, the same way it does for Igra. See Runtime.
To deploy, open Deploy Node, pick Gnosis, then choose a network. The wizard offers exactly the networks, clients, and versions your target executor declares.

​
Networks

Gnosis nodes run as Full nodes.

​
Clients

One client per role today: Reth (the Gnosis build, gnosis-reth) as the EL and Lighthouse (gnosis-lighthouse) as the CL.

​
Resources

Defaults are set per client and per network; the node’s footprint is the EL client plus the CL client. The wizard pre-fills these and lets you adjust CPU and memory before deploying.

​
Ports

These are the endpoints you consume: JSON-RPC on :8545 from the EL (the eth and net namespaces) and the beacon API on :5052 from the CL. The Engine API the two roles use to talk to each other is internal and managed by Novacula. In a pool, the EL JSON-RPC is the role the pool serves.

​
Sync

  • Snapshot bootstrap (EL) — before its first start, a fresh Reth downloads a recent full-node snapshot into its data directory, so it starts from recent chain data instead of syncing from genesis. The node reads Downloading snapshot while it runs, on an Agent and an Operator alike; an interrupted download resumes where it left off. See Snapshot bootstrap.
  • Checkpoint sync (CL) — always on, managed automatically. Lighthouse fetches a recent finalized state from a public Gnosis checkpoint provider; Novacula keeps more than one per network in preference order.

​
Configuration

Gnosis runs with a managed, network-pinned configuration — there are no client config overrides to set when you deploy. Novacula writes the data directories, ports, Engine API, JWT, and metrics settings for you.

​
Monitoring

The node page shows per-role status, sync progress, peers, CPU, memory, and disk for both the EL and CL — see Node monitoring. While Reth is still backfilling, its sync progress is read from its pipeline stages rather than from eth_syncing, which can report 100% before the pipeline has finished; block height follows the same reading until the RPC serves a real height.

​
What you can build

  • RPC provider — the Reth EL paired with the Lighthouse CL, serving JSON-RPC on :8545, on its own or behind a pool.
  • 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.

​
Where to next