Software updates

JasperNode can update its own runtime in place. The node checks for a newer build, downloads it, verifies it is signed by the JasperX release key, and installs it — after which the process restarts briefly. Your tags, logic, connector configuration and Node ID are preserved across an update.

You control which stream of releases a node follows with its update channel, and the node decides whether to install a release using one simple rule: it only ever moves forward.

Running the container image? The node cannot update itself.

Self-update applies to the native Linux install only. A node running from the jaspernode/jaspernode container image never replaces its own program files — you update it from the host by pulling the newer image and recreating the container. See Updating a container node below.

The two channels

Channel	What it contains	Use it for
Stable (default)	Finished production releases (e.g. 2.1.0, 2.1.1).	Field devices and anything running a live process. Recommended.
Beta	Pre-release test builds (e.g. 2.1.0-beta.3) as well as stable releases.	Trying new features early, on a bench or a non-critical node.

Beta builds are newer and give you features before they reach Stable, but they have had less testing and may be less stable.

A brand-new node starts on the channel it was installed from: install it with JN_CHANNEL=beta and it comes up on Beta, so it keeps receiving test builds instead of quietly waiting for Stable to catch up. Otherwise it starts on Stable — unless the build it was given is itself a test build, in which case it starts on Beta so it does not strand itself on a pre-release. Whatever you then choose in System Config wins from that point on; re-running the installer never moves a node off the channel you picked.

See what changed in each release: What’s new covers Stable releases, and What’s new in test builds covers the Beta channel.

Switching channel

Open Account → System Config → Software updates and choose Stable or Beta (test builds) from the Update channel selector, then Save. The change takes effect on the node’s next update check — no restart is needed.

Advanced users can set the same thing directly in the node configuration: the updateChannel field ("stable" or "beta") in __sys/node/user/config. The node fills this field in on its first boot — from the JN_CHANNEL line the installer left in /etc/jaspernode.env, or, if there is none, from whether the build it is running is itself a test build — and never touches it again.

The node checks for updates automatically on a timer, and you can check on demand from Account → System Updates.

How the node decides to update — forward-only

A node only installs a build that is strictly newer than the one it is already running, judged by standard version-number order. This has one important consequence:

Switching channels never downgrades a node.

Changing the channel only changes which stream the node watches for a newer release. It never rolls the node back to an older version. If the channel you switch to is currently offering something older than what you already run, nothing happens — the node keeps running its current build until that channel ships something newer.

Two examples

You are running	You switch to	What happens
2.1.0-beta.13	Stable, currently at 2.0.2	Nothing. 2.1.0-beta.13 is already newer than 2.0.2, so the node stays put. It moves only once Stable ships something newer than what you run (e.g. 2.1.0 or above).
2.1.2	Beta, currently at 2.1.30-beta.2	The node updates to 2.1.30-beta.2 — an ordinary forward step onto the beta line, because that build is newer than 2.1.2.

So moving a test node from Beta back to Stable is safe: it will simply sit on the build it has until Stable catches up and overtakes it, rather than jumping backwards.

A note on version order

For the curious: a beta of a version counts as older than that version’s final release. For example, 2.1.0-beta.13 is considered older than 2.1.0 — the beta builds lead up to the final 2.1.0, so the finished release wins. This only ever matters when the main x.y.z numbers are the same; when they differ, the higher x.y.z is always the newer one (2.1.30-beta.2 is newer than 2.1.2).

Updating a container node

A node running from the jaspernode/jaspernode container image — the macOS and Windows path in Getting started, with Docker or Podman — does not update itself. Its program files come from the image, and anything the node swapped in would be thrown away the next time the container is recreated. Self-install is therefore disabled, and the image tag on the host is the single source of truth for the version the node runs.

The node still checks its channel and reports newer builds: Account → System Updates shows the available version, together with a note explaining that a container node cannot install it itself.

To update, pull the newer image on the host and recreate the container:

docker pull jaspernode/jaspernode:latest-beta
docker stop jaspernode
docker rm jaspernode
docker run -d --name jaspernode -p 9009:9009 \
  -v jaspernode-data:/var/lib/jaspernode \
  jaspernode/jaspernode:latest-beta

The same commands work with podman in place of docker. For the last step, reuse the exact docker run command you first started the node with — the one from Getting started, plus any flags you added to it.

Three things to know:

• Your node survives because of the volume. Tags, logic, connector configuration and the Node ID all live under /var/lib/jaspernode, which the documented run command keeps on the jaspernode-data named volume — recreating the container replaces only the program files. Without that volume mapping, recreating the container erases the node. Check your run command has -v jaspernode-data:/var/lib/jaspernode (or your own mount) before removing anything, and back up first.
• The image tag picks the release stream. :latest-beta follows the Beta channel, so pulling it gives the newest test build. In a container the update-channel setting in System Config only changes which stream the node watches and reports — it never installs anything.
• Connectors update as normal. Connectors are not part of the core image — they install from the signed connector catalogue into the node’s data directory, so adding or updating a connector in the Connector Manager works exactly as on a native install, and installed connectors survive the container being recreated.