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, Network, 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.)
  • Runtime (Agent only) — whether the agent runs this node as Systemd services or in Docker containers. Most chains only ever run as system services, so the field is fixed on Systemd; it becomes a real choice on the chain and network combinations that support containers. See Runtime below.
  • Chain — only the chains this executor supports appear. See Supported chains.
  • Network — for example mainnet, signet, sepolia, chapel. The list depends on the chain.
  • Node type — usually Full; Bitcoin and BSC also offer Pruned (less disk, no full history), Tron offers Lite, and Stable offers Pruned and Archive (it has no Full). 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

Network

Choose how each of the node’s components is reachable — Local (internal only), Direct (publish the port on the executor’s own network), or Public domain (a managed gateway with a domain, TLS, rate limit, and optional RPC-key auth). Local is the safest default; pick a public domain for production traffic. P2P and metrics aren’t proxied, and you can change exposure any time after deploy from the node’s RPC tab.On a bare-metal Agent with an unmanaged firewall, the step reminds you to expose only the endpoints you intend to publish.See RPC exposure for the full model, the Agent-vs-Operator differences, and how to read the resulting endpoint.
4

Review

A summary panel shows the node you’re about to create. An Advanced section holds optional settings for recovery and naming — all pre-filled with safe defaults:
  • 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.

​
Runtime (Agent only)

On a bare-metal Agent, a node’s processes run either as systemd services or as Docker containers, and the Target step’s Runtime field is where that’s decided. Kubernetes executors have no such field — everything is a pod there. Systemd is the default and the only option for most chains. Docker becomes selectable when both of these hold:
  • The executor is an Agent running release 0.1.11 or newer.
  • The chain and network you picked support the container runtime. Ethereum (mainnet, sepolia) and Tempo (mainnet, moderato) can run either way; Igra (mainnet, galleon-testnet) and Ink (mainnet) are container-only, so they always use Docker.
When only one runtime applies, the field is locked and reads “Docker is not available for this Agent version or network”. Changing chain or network re-evaluates it, and a runtime that no longer applies falls back to Systemd.
Igra and Ink are container-only — their clients ship as images, not binaries — so on an Agent they can only run in Docker. Pick one and the Runtime field locks itself to Docker; Systemd isn’t offered, so there’s nothing to get wrong.
The chosen runtime is shown as Runtime on the Review step, so you can confirm it before deploying. It’s fixed for the life of the node: to move an existing node between runtimes, redeploy it. The first Docker node on a host also triggers the Docker engine install — see Docker prerequisite.

​
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, see Edit a running node — resources and RPC exposure can change in place, and the version has its own flow in Update a node’s version.