Skip to main content
Four ideas cover almost everything you’ll see in the Novacula UI. Read them in order — each one builds on the previous.

​
Executor

An executor is the Novacula software you install on your own infrastructure to run blockchain nodes. It connects outbound to Novacula and converges to the work you assign it — there are no inbound ports to open. You install one executor per host or cluster, and it comes in two flavors:
  • Agent — for a bare-metal server or VM. It runs each node’s processes as systemd services on the host.
  • Operator — for a Kubernetes cluster. It runs each node’s processes as pods.
Pick the one that matches where you want your nodes to live. When an executor connects, it tells Novacula which chains, networks, clients, and versions it can run — and the deploy wizard offers exactly those, so you never pick a combination this executor can’t serve.

​
Node

A node is your unit of management in the UI: one blockchain full node attached to one network — for example, “Ethereum mainnet, Geth + Lighthouse, full”. Novacula runs and keeps the node healthy so you can point your apps, indexers, or other RPC consumers at it. One node can be several processes under the hood. Some chains are single-process (Bitcoin, Tron). Ethereum is two: an execution layer client (Geth) plus a consensus layer client (Lighthouse). Logs, metrics, and lifecycle controls are surfaced per process in the UI.

​
Desired-state model

You don’t tell an executor “start this process now”. Instead you describe what you want in the UI — this chain, this network, this client and version, these resources — and the executor reconciles its world to match, on every check-in, until reality matches your intent.
Coming from Kubernetes? It’s the same pattern as kubectl apply plus a controller: you write the desired state, and something running close to the workload converges to it. Here, you are the one writing desired state in the UI, and the executor is the controller.
Because the executor is the controller running next to your nodes, the Hub is only a coordinator — not a runtime dependency. Your nodes run as local services on your own infrastructure, so if the Hub is unreachable or goes away entirely, your nodes keep running and keep serving RPC. Only convergence to a new desired state — deploying, config and version changes, and lifecycle actions — pauses, and resumes on the executor’s next check-in.

​
Chain · Network · Client

When you deploy a node, you make three picks, in this order:
  • Chain — which blockchain (Bitcoin, Ethereum, Monad, Tron, …).
  • Network — which network on that chain (mainnet, testnet, …).
  • Client — which node software to run, and its version. For Ethereum you pick both an execution-layer and a consensus-layer client.
The wizard only shows what the target executor declared it can run, so unsupported combinations never appear. If a chain, version, or client you want isn’t listed, upgrade the executor to a release that supports it.