---
title: Keep your node current: check for and apply the latest release
slug: update-your-node-to-the-latest-release
date: 2026-10-12
author: Semurg
section: how-to
tags: [update, install, operations, how-to]
summary: Updates are free for every node. A node checks the signed manifest, verifies and swaps in the new release, checks that it came up, and rolls back if it did not. Here is how to drive it from the command line or over HTTP.
status: published
covers: [cli:semurg update, route:GET /v1/cluster/update, route:POST /v1/cluster/update, route:GET /v1/cluster/update/status]
---
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.

> Diagram update-flow: 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.

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 runnable kind=shell-node needs=token
export SEMURG_API_TOKEN=<your token>
curl -sS "http://localhost:4000/v1/cluster/update?format=text" \
  -H "Authorization: Bearer $SEMURG_API_TOKEN"
```

```expect
expect: one of current, behind, could_not_judge or installed_is_newer, with the installed and the latest release
assert: rc=0;out~(current|behind|could_not_judge|installed_is_newer)
```

## 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

- [Look after your node](/blog/look-after-your-node): the calls that tell you how it is doing after the update.