Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.novacula.io/llms.txt

Use this file to discover all available pages before exploring further.

The in-UI Upgrade node flow described below is not yet shipped. There is no Actions → Upgrade button, no requestNodeUpgrade GraphQL mutation, and no executor-side handler today. This page documents the path that exists right now plus the target flow that’s on the roadmap.

​
Current path — redeploy

Until the in-UI flow lands, the only way to move a node onto a different client version is:
  1. Delete the existing node from the node detail page → Delete. This tears down the underlying pod (Operator) or systemd unit (Agent) but does not preserve the data directory — the executor cleans it up when the spec disappears.
  2. Redeploy from the wizard with the new client version. The deploy wizard offers every version the target executor’s capabilities declare for the chosen chain + role.
This means a full resync from genesis or from a checkpoint — there is no in-place binary swap that preserves the data directory. If you need a target version that the executor doesn’t yet support, upgrade the executor first — newer executor releases ship newer client coverage.

​
Target flow — coming soon

The planned in-UI experience mirrors the executor self-upgrade pattern that already ships:
  • Per-role version picker on the node detail page — for multi-role chains (Ethereum, Igra, Ink, Monad) you’d upgrade EL / CL / consensus / execution independently.
  • Available versions filtered by the target executor’s capabilities + per-network constraints (e.g. Hoodi requires geth >= 1.15.0).
  • Compare-and-swap on Node.pendingUpgrade — the same safety model the executor upgrade flow uses.
  • In-place reconcile that preserves the data directory: download the new binary / pull the new image, stop the existing process, start the new one, report back. No resync from genesis unless the new client requires a different on-disk layout.
  • Per-fleet rollout — once an executor upgrade publishes new client versions, a fleet-level prompt surfaces every node whose version is behind, with a bulk-apply action.
Until those land:
  • Adopt new versions by deleting + redeploying.
  • Roll back a misbehaving release the same way.