Blog / How-to guides

Keep your node current: check for and apply the latest release

12 October 2026 · Semurg · 3 min read · Markdown

Verified: every command below ran on a fresh node of r11.78.20261012.bc0d94f (how)

updateinstalloperationshow-to

Semurg ships new releases often, and updates are free for every node, the free first node included. A node does not need you to download anything by hand: it checks Semurg's signed release manifest, downloads the release it names, verifies it, swaps it in, checks that the new release came up healthy, and puts the old one back if it did not. Your data and your settings are never touched.

Applying an update downloads the bundle the signed manifest names, checks it, stages the new release beside the live one, snapshots, swaps and restarts, then waits for the expected version and health; if it does not come up it rolls back to the snapshot and says why.A newer release ispublishedDownload the bundlethe manifest namesStage beside the livereleaseSnapshot, swap,restartExpected version,healthy?AppliedRolled back to thesnapshot, with thereasonchecksum matchesyesno

This guide is for a node installed with the one-line installer. A node upgrading from r11.52 or an older release runs its old updater once more, and the fixed one takes over from the next update.

Is there a newer release?

bash
sudo semurg update --check

It prints where the node is and where the latest published release is, and its exit code is meant for scripts:

  • 0: this node runs the latest release.
  • 10: a newer release is published. This is the only state in which applying is honest.
  • 20: the node could not tell, for example because it could not reach the manifest. It never means "up to date".
  • 2: the command could not reach the node itself. --apply and --status use the same code for the same case.
  • 30: this node runs a release newer than the published one.

The same question over HTTP, with the node's API token:

bash
export SEMURG_API_TOKEN=<your token>
curl -sS "http://localhost:4000/v1/cluster/update?format=text" \
  -H "Authorization: Bearer $SEMURG_API_TOKEN"

Expected: one of current, behind, could_not_judge or installed_is_newer, with the installed and the latest release

Apply it

bash
sudo semurg update --apply

The node takes it from there:

  1. It downloads the installer bundle named by the signed manifest and checks its checksum against the manifest; the bundle's own signature is checked again when it unpacks.
  2. It stages the new release beside the live one and confirms the staged release is the one the manifest names, before anything live moves.
  3. It snapshots the live release, swaps the new one in and restarts the node.
  4. It waits for the new release to report the expected version and answer healthy. If it does not, it rolls back to the snapshot and says why.

--apply returns as soon as the update has started (exit 0); the work carries on detached, so it survives the node's own restart. If the node is not behind, or the call is not allowed, it is refused by name (exit 20).

Over HTTP, the same apply is a POST to the same route:

bash
export SEMURG_API_TOKEN=<your token>
curl -sS -X POST http://localhost:4000/v1/cluster/update -H "Authorization: Bearer $SEMURG_API_TOKEN"

Did it work?

bash
sudo semurg update --status

It reads the result the update wrote when it finished: 0 applied, 11 still running, 20 rolled back, failed or refused, with the reason. Over HTTP, the same result is at /v1/cluster/update/status. Every update leaves a result, so "no answer" is never an answer: if the result cannot be read, the command says so.

The update keeps the newest few snapshots of earlier releases, never one that holds data, and it never touches /etc/semurg or your data directory.

What it does not cover yet

  • A node running in Docker has no semurg command, and this guide does not cover updating a container yet.
  • Updating several nodes at once, one after another, is not covered here; talk to us about clusters.
  • Re-running the installer on a node that already has a finished install is refused on purpose, because a plain re-run would rescan the machine and could rewrite its settings. Use semurg update, which keeps them.

Next

How these commands were checked

Our test farm ran each of the 1 command block marked runnable, exactly as written, with the answer checked against the expectation printed under it, against a fresh node of the published release r11.78.20261012.bc0d94f. A post is published only when every one of them passed there.

Related