Skip to main content
The Deploy node wizard provisions a new blockchain full node onto one of your connected executors. It has four steps — Target, Resources, Custom config, and Review — and each step constrains the next, so your options narrow as you go. The wizard only ever offers what the chosen executor declares: its chains, networks, clients, and versions. If a combination you want is missing, upgrade the executor first.

​
Before you start

To open the wizard, go to Nodes and select Deploy node.

​
Steps

1

Target

Choose where the node runs and which network it joins.
  • Executor — pick the executor to host the node. Offline executors are disabled. (Hidden when you start the wizard from a specific executor — it’s already chosen.)
  • Chain — only the chains this executor supports appear. See Supported chains.
  • Network — for example mainnet, signet, sepolia, nile. The list depends on the chain.
  • Node type — usually Full; Bitcoin and BSC also offer Pruned (less disk, no full history). When a chain has only one type, this is fixed for you.
Then, under Client (or Clients for multi-role chains like Ethereum), pick the client and Version for each required role. Ethereum, for example, has separate execution-layer and consensus-layer roles, each with its own client and version. When a role offers a single client or version, it’s filled in and locked.
2

Resources

The Storage and Resources sections come pre-filled with recommended values for your chain, network, node type, and client — recommended is selected automatically, and mainnet is consistently heavier than testnets.
  • Storage — on a Kubernetes executor, choose a Storage class for the disk. Each declared volume has a size; keep the recommended value or switch on customize to set your own.
  • Resources — per role, set the CPU request and Memory request. Switch on customize to also set separate CPU and memory limits (otherwise limits match requests). These map to Kubernetes resource requests/limits on the Operator and to process limits on the Agent.
On a bare-metal Agent the wizard checks the host’s live capacity. If your requests exceed what’s available, it shows a capacity warning naming the resource, what’s needed, and what’s free. You can still deploy, but the node may not start cleanly.
3

Custom config

Optional. Overrides are validated against the selected chain; Novacula-managed settings (data directory, RPC bindings, ports) can’t be overridden. Chains that expose no override surface show a short notice and you can skip ahead.
  • Config files — set keys in a chain-specific file (for example bitcoin.conf). Use Browse known keys for documented keys with guided values, or Custom key for anything else. Some formats accept only known keys — those panels are tagged allowlist. Toggle a panel between Guided and Raw to paste raw file text instead.
  • CLI arguments — append extra process arguments with Browse known flags or Argument. They’re added after Novacula’s managed flags; allowlist-only processes accept known flags only.
For the exact keys and flags each chain accepts, see its page — for example Bitcoin or Ethereum.
4

Review

A summary panel shows the node you’re about to create. An Advanced section holds optional settings for exposure, recovery, and naming — all pre-filled with safe defaults:
  • Network exposure — choose how the node’s RPC is published: Local (internal only), Direct (publish the port, optionally restricted to an IP allowlist), or Public domain (serve it through a managed gateway with a domain, TLS, rate limit, and optional RPC-key auth). P2P and metrics aren’t proxied. You can set this here and change it any time afterward. See RPC exposure for the full model, the Agent-vs-Operator differences, and how to read the resulting endpoint.
  • Restart policy (Agent only) — restart behaviour for the underlying processes: On failure (default), Always, or Never.
  • Node ID — leave empty to generate one from chain and network (plus a short random suffix), or type your own.
On a bare-metal Agent, the Review step warns if the same chain already runs on the same physical host — including via a different Agent executor sharing that host — because two same-chain nodes on one host tend to collide on ports, resources, or data directories. Deploy stays blocked until the host’s node inventory has loaded and you acknowledge the warning. Operator (Kubernetes) deployments aren’t affected, since each node runs in its own pod.
Select Deploy. The target executor picks up the new node on its next sync — typically within seconds — and starts running it.

​
After you deploy

The node detail page is where you watch and manage the node:
  • Status — reported by the executor and refreshed each sync.
  • Logs — streamed live from each process. See Node logs.
  • Monitoring — sync progress, peers, and per-process metrics. See Node monitoring.
To change anything later — resources, config, or version — see Edit node configuration and Upgrade a node.