Skip to main content
The Deploy node wizard provisions a new blockchain full node onto one of your connected executors. It has up to five steps — Target, Resources, Network, Connections, and Review — and each step constrains the next, so your options narrow as you go. The Connections step appears only when the node needs it: an L2 that reads an Ethereum L1 (Base, Robinhood Chain) needs its parent endpoints, and a Tron node can stream events to a MongoDB destination. Chains with neither skip straight to Review. 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; Ethereum also offers blob-serving (a full node whose beacon keeps every blob, for serving an L2 — see Ethereum), 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. Every declared volume is shown and needs a size before you can continue — an Ethereum blob-serving node with Reth, for example, gets recommended defaults and its execution storage here too.
  • 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.
The step shows an Executor capacity check that compares your request with the latest capacity the selected executor reports. On a bare-metal Agent that’s the host’s free CPU, memory, and disk; on a Kubernetes (Operator) executor it’s the cluster’s schedulable CPU and memory headroom (allocatable minus what’s already requested — storage isn’t checked there). Each resource reads Fits or the amount it’s short by (for example 4 CPU short), with what’s needed and what’s available; a resource the executor doesn’t report is left out of the check. If recent metrics aren’t in yet it reads Capacity unavailable and you can continue unverified. What a shortfall does depends on the organization’s Resource limit enforcement setting (Settings → General, owner-only, on by default): with it on, Next and Deploy stay blocked until you reduce the request or pick another executor; with it off, the shortfall is a warning — the affected rows turn red, the warning repeats on Review, and you can deploy at your own risk, though the executor may reject the node or it may not start cleanly. (The platform can also enforce the same check server-side.) While the capacity request is still in flight, Next waits for the result.
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

Connections

Shown only when the node needs it — an L2 that reads an Ethereum L1, or a Tron node’s optional event streaming. See Connections below for the full step.
  • L1 endpoints (Base, Robinhood Chain) — point the node at an Ethereum execution RPC and a beacon endpoint: enter External URLs (Base and Robinhood Chain), or, for Robinhood Chain, pick an Existing node or create a New node. Every declared connection must be assigned.
  • Event streaming (Tron) — optionally stream chain events to a MongoDB destination. Off by default.
5

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.

​
Connections

The Connections step configures the parent endpoints and destinations a node depends on. It appears only when the chosen chain needs it, and what it contains depends on the chain.

​
L1 endpoints (Base, Robinhood Chain)

An L2 like Base or Robinhood Chain derives its chain from Ethereum L1 and can’t sync from L2 peers alone. There’s no public L1 fallback, so you provide the endpoints — an Ethereum execution RPC and an Ethereum beacon endpoint on the network the L2 reads. Choose where they come from:
  • Existing node — pick an Ethereum node from your organization; it supplies both endpoints. It must be a blob-serving node on the network the L2 reads, with its execution RPC and beacon API exposed Direct without RPC-key auth. A node that’s still syncing can be picked, and the deployment waits for it. Nodes that can’t serve the connection are disabled, with the reason.
  • New node — choose a host and create the Ethereum node as part of this deployment. Offered when one of your executors can deploy it.
  • External URLs — enter the execution RPC and beacon URLs of a node you run elsewhere or a provider’s; each must work without a password or API key.
Robinhood Chain offers all three. Base takes External URLs only — the step shows just that choice. The beacon endpoint must come from a consensus client that keeps every blob — on Lighthouse that’s --supernode or --semi-supernode; a beacon node running without one of them can’t feed the L2. An Ethereum node you deploy on Novacula gets that flag when you pick the blob-serving node type in the wizard, so that’s the node to pick (or create) for an L2. For external URLs to such a node, expose its execution RPC and beacon API without RPC-key auth and enter those URLs. Every declared connection must be assigned before you can continue; the requirements have no optional slots. You can change these later on the node’s Connections tab — see Edit a running node.

​
Event streaming (Tron)

A Tron node always shows this step so you can optionally stream chain events to a MongoDB destination. It’s off by default; see Tron event streaming for the streams, filters, and how a historical backfill resumes. Enabling it needs a reachable MongoDB (host, port, database, username, password) and java-tron 4.8.2 or newer.

​
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, and afterwards as Runtime in the node’s Node metadata (Systemd or Docker; Kubernetes for a node on an Operator). 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.