Node lifecycle

A node moves through a small set of states, and you drive it with four actions: Start, Stop, Restart, and Delete. These change whether the node is running — not how it’s configured. To change what can be changed on a running node, see Edit a running node.

​

Take an action

Open a node’s detail page (Nodes → pick a node) and use the action buttons in the header. The same actions are available from each row in the Nodes list. Only the actions that make sense for the node’s current state are shown — you can’t Stop a node that’s already stopped, for example. Editing a node’s configuration restarts it automatically when needed, so you rarely need Restart by hand. Applying a version update is its own flow with its own states — Upgrading, or Resyncing when the step clears data — see Update a node’s version. Actions take effect on the next reconcile cycle (typically within a few seconds), not instantly. The status badge updates as the executor reports progress.

​

Node states

Every node shows a colored status badge. The label tells you exactly where the node is:

​

Snapshot bootstrap

Chains that seed from a snapshot surface the bootstrap as its own Downloading snapshot state on first deploy, instead of sitting in an opaque Starting state during a long download. While it runs, the node page shows download progress: downloaded bytes, speed, attempts, resumes, and any failure detail the executor reports. This progress reads the same way whether the node runs on an Agent or an Operator, and some chains split the bootstrap into two visible phases — downloading the snapshot, then preparing the downloaded state locally before sync (Sui, for example). Bootstrap is recoverable. The snapshot is extracted into a staging directory and promoted into the data directory only once complete, so a failed or interrupted bootstrap never leaves a partial tree behind. Agent-side downloads also resume from where they left off when the remote server supports HTTP range requests. If a snapshot bootstrap fails, the failure is surfaced clearly on the node — even when the node then falls back to syncing from genesis — so you can see what happened rather than guessing. Snapshot download progress also appears as a chart on the Monitoring tab. If the data directory already holds a synced database, the snapshot step is skipped. See each chain’s page for whether and how it bootstraps from a snapshot.

​

Stopping vs. deleting

These look similar but are very different for your data. Stop is reversible. It halts the node’s processes and leaves everything else in place — the data directory and on-disk chain state are untouched. Starting the node again picks up where it left off, so you don’t resync from scratch. Delete is permanent and destroys the node’s data on both backends — the on-chain state is gone and a same-name re-deploy resyncs from scratch:

• On bare-metal, deleting removes the node and its data directory. See the bare-metal recipe for details.
• On Kubernetes, deleting removes the node and its storage — the StatefulSet’s persistent volume claims are deleted (and a persistent volume left behind by a Retain reclaim policy is cleaned up too), along with the node’s config and any RPC ingress/certificates. See the Kubernetes recipe.

If a delete lands while a snapshot is still downloading, the in-flight download is aborted and its temporary files are removed too, so nothing is left occupying disk or bandwidth. Deleting a node also removes the alert rules that target it — the confirmation dialog tells you how many will go before you commit. Rules scoped to the organization, a chain, or an executor aren’t touched; only rules pointed at this node are cleaned up with it.

​

Recovering from an error

When a node is in the Error state, the detail page shows what went wrong. From here the available action is Start, which relaunches the node’s processes — the right move once you’ve addressed a transient cause (a flaky start, a one-off crash). If the node comes back healthy, it leaves the Error state on its own. If the error keeps coming back, check the node’s logs for the underlying cause before starting it again.

​

Permissions

Start, Stop, Restart, and Delete all require the Owner or Admin role. Members have read-only access and can view a node’s state but not change it. See Roles and permissions.