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. You can apply a step yourself, or let the Hub apply qualifying steps for you with automatic updates.

​

Find the update

Open the node from Nodes and stay on the Overview tab. The Node metadata panel lists the node’s components — one row per role, with its client and running version — and that’s 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 that is already at the newest version for its line — or whose chain has only one verified set so far — 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: While an automatic update is running on the node, a manual version change is refused until it finishes.

​

Automatic updates

Instead of applying each step by hand, you can let the Hub apply them. With automatic updates on, the Hub updates the node to the next supported version its executor offers — the same single step you would see under Update node version, one step at a time — and only one node per organization is updated at a time. Automatic updates are set per node, on the node’s Overview tab: the Automatic updates card sits in the right-hand column, below Node metadata. Its badge reads On, Off, or Unavailable (when the settings can’t be loaded).

​

Turn them on

Owners and Admins see Turn on (or Edit, once they’re on). It opens a dialog:

• Update this node automatically — the switch that turns automatic updates on or off.
• Which updates — the least urgent kind of update the Hub may apply. Each choice includes everything more urgent:

  Choice	Applies
  Urgent security updates only (default)	Security fixes and mandatory network changes.
  Recommended and urgent updates	Also updates the Hub recommends applying soon.
  All updates	Also minor updates you could apply at your convenience.

• Maintenance window — turn it on to limit when an update may start: a Start time, an End time, and a Time zone (an IANA name such as Europe/London). A window may cross midnight; equal start and end times mean no update can ever start. With the window off, an update may start at any time.

The dialog also spells out, under What an automatic update does to this node, what you’re agreeing to:

• The updated components restart, so the node stops serving while it restarts and catches up with the chain.
• If the update fails or the executor rejects the new versions, those versions are blocked from further automatic updates on that chain and network, for every node in your organization (see If an automatic update fails).
• A step that wipes and resyncs data is never applied automatically. It waits for you to apply it from Node metadata, with the usual consent.

Confirm with Turn on automatic updates, Save (for changes while they’re on), or Turn off automatic updates — turning them off keeps your choice of updates and window for next time. Members see the card’s current state with the note “An Admin or Owner can change automatic updates.”

​

When the Hub starts an update

While automatic updates are on, the card shows Updates (your choice of which updates), Window (the maintenance window, or Any time), and Next possible start — the earliest time the window allows. That’s not a scheduled update: it happens “Only when an eligible update is available.” The Hub starts an update only when all of these hold:

• The node isn’t stopped or failed.
• Every component reports running exactly the versions the node is configured for — the node has settled after any previous change.
• An update step is available: the running versions are on the supported update path, the executor doesn’t need updating first, and the target versions aren’t blocked.
• The step is at least as urgent as your Which updates choice.
• The current time is inside the maintenance window.

When something holds the node back, the card says why — for example the node is stopped, the Hub has no update advice for it yet, its running versions are outside the supported update path, its executor must be updated first, the next step wipes and resyncs data (apply it yourself from Node metadata), or the available step is below your threshold.

​

While an update runs

The card shows Update in progress with when it started, and the node’s status moves to Upgrading as for a manual update. Turning automatic updates off prevents the next update but doesn’t stop this one. To end it, Stop the node: the node stops serving, the Hub records the update as Stopped, and the new versions stay in the node’s configuration — nothing is rolled back. See Node lifecycle. The Hub waits up to 6 hours for the node to report the new versions:

​

If an automatic update fails

A failed or rejected update blocks its target versions for automatic updates on that chain and network across your organization, so the Hub doesn’t push the same broken step to the next node. The block lifts on its own once any node reaches those versions — for example after you apply the step by hand from Node metadata and it succeeds. The console has no button to clear a block early.

​

History

The card’s History lists the node’s automatic updates, newest first: Succeeded, Failed, Stopped, In progress, Not started (the Hub passed over a step because its versions are blocked or it wipes data), or Outcome unknown (no outcome was recorded before the next update started), with when each started and finished, each role’s client version from → to, and the failure reason or the node’s error text where there is one. Show older pages back further. On a stopped node, the compact overview shows the card only if automatic updates are on, an update is running, or there is history to show. Changes to a node’s automatic-update settings are recorded in the audit log as node.upgrade_policy.changed.

​

Supported update paths today

All steps below are Restart required unless noted. Recommendations: urgent is Update as soon as possible, recommended is Update recommended, optional is Update when convenient. In the Sui row, each version carries the network prefix of its line (mainnet- or testnet-). Base, Gnosis Chain, and Robinhood Chain have a single verified set and no steps yet, so their nodes report nothing to do, as does HyperLiquid mainnet. 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 blocked step, 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 and automatic-update settings changes are recorded.
• Deploy a node — the wizard you’ll use when there’s no supported path.