Update a node's version

Novacula updates a node one supported step at a time. Each chain ships a catalogue of verified version sets and the steps between them; a node is offered the single next step out of the set it is currently running, and nothing else. You don’t pick an arbitrary version — you review the step the catalogue blesses and apply it, and the executor carries it out without tearing the node down.

​

Find the update

Open the node from Nodes and stay on the Overview tab. The panel that lists the node’s components — one row per role, with its client and running version — is where updates surface: a role with a newer supported version shows it in brackets after the current one, for example 1.17.3 (1.17.4 available). If the update also changes the client, the client name is shown too. When an update is available, the panel header carries an Update node version button. Under the component rows the panel shows how urgent the update is:

​

When no update is offered

Instead of a button, the panel explains why: A node whose chain ships no update catalogue, or which is already at the newest version for its line, shows nothing at all.

​

Review and apply

Update node version opens a dialog that spells out exactly what will change before you commit:

• A table of Role, Current, and New version — one row per affected role, so a multi-process node (Ethereum’s execution + consensus pair, say) shows both.
• Update impact, per role:

  Impact	What happens
  Restart required	The affected process restarts on the new version. All node data is preserved; the interruption is that of a normal restart.
  Data wipe and resync	The data format changed one-way. Local data for the affected roles is deleted and those roles are unavailable while they resync.
  Update blocked	The step can’t be applied.
  Additional action required	The Hub reported an impact this version of the UI doesn’t recognize; the raw value is shown alongside.

• If the node is more than one step behind, a line saying so — “This node is N updates behind” — and a reminder that updates are applied one version at a time, so this one installs only the next supported version. Repeat the flow to keep going.

Confirm with Apply update. The node’s status moves to Upgrading while the executor works through it, and you get a Node version update requested confirmation. The executor picks the change up on its next check-in.

​

If the step wipes data

A Data wipe and resync step needs explicit consent. The dialog says which roles lose their data, and you must tick “I understand that affected node data will be deleted and the node will be unavailable while it resyncs.” before the button — now reading Wipe data and update — becomes usable. The node’s status shows Resyncing while it rebuilds. Sibling roles that the step doesn’t touch keep their data, and node identities and secrets are preserved either way. Your acknowledgement is recorded in the audit log against your account.

​

If the dialog refuses

The gate validates the step against what the node is actually running, not against what was last requested, so it fails closed rather than guessing:

​

Supported update paths today

Every step shipped today is Restart required — no current step wipes data. BSC and Igra have a catalogue with a single verified set and no steps yet, so their nodes report nothing to do. HyperLiquid, Monad, and Sui ship no catalogue at all; change versions there by redeploying. New steps arrive in executor releases. To pick one up, update the executor — which you’d need to do anyway, since a step is only offered by an executor on the newest release.

​

When there’s no supported path

For a chain without a catalogue, an unrecognized running set, or a version change the catalogue doesn’t bless, changing the version means redeploying:

1. Delete the node. On the node detail page, choose Delete and confirm. This tears down the running node; deletion cannot be undone and the data directory is not preserved.
2. Redeploy with the version you want. Nodes → Deploy node. In the Target step, each role’s version dropdown lists exactly the versions the chosen executor declares for that chain and client, filtered by any per-network constraint.

Because the data directory isn’t kept, the redeployed node syncs again — from genesis, from a checkpoint (Ethereum consensus clients), or from a snapshot where the chain supports one. Plan for the resync time, especially on mainnet. Rolling back works the same way: the catalogue only moves forward, so to go back to an older version, redeploy onto it.

​

If the version you want isn’t offered

A node can only run what its executor supports — both the deploy wizard and the update offer are limited to what that executor declares. If the target version isn’t there, update the executor first; newer executor releases ship newer client coverage. Review what an executor currently supports on its Capabilities tab — see Executors.

​

Related

• Update an executor — do this first; a step is only offered by an executor on the newest release.
• Edit a running node — resize CPU, memory, or storage without a version change.
• Node lifecycle — the Upgrading and Resyncing states you’ll see while a step is applied.
• Audit log — where a resync acknowledgement is recorded.
• Deploy a node — the wizard you’ll use when there’s no supported path.