Update the agent

The agent is a single binary, so updating is just replacing that binary and restarting the service. Your identity and certificate are stored separately (in the config directory), so updating never re-enrolls and there is nothing to reconfigure.

Update now

sudo demerzel-agent --update
sudo systemctl restart demerzel-agent   # adopt it in the running service

--update verifies and installs the new binary, then exits — it never restarts anything on its own. If you are already on the latest release it says so and does nothing.

The dashboard shows the version every host reports, so you can see at a glance which agents are behind.

Auto-update is off by default

The agent does not update itself unless you tell it to.

Software that replaces its own binary on your production server should be a decision you make, not a default you have to discover and switch off. Plenty of teams need to know exactly which build is running on which host — for change control, for a maintenance window, for an audit. So the default is: nothing changes on your server unless you asked for it.

Turning it on

Add --auto-update to the service’s ExecStart line:

sudo systemctl edit --full demerzel-agent

# ExecStart=/usr/local/bin/demerzel-agent --auto-update

sudo systemctl daemon-reload
sudo systemctl restart demerzel-agent

Or set it in the environment instead, which is often easier to manage from a configuration tool:

# /etc/systemd/system/demerzel-agent.service.d/override.conf
[Service]
Environment=DEMERZEL_AUTO_UPDATE=1

With auto-update on, the agent checks for a newer release at startup and every 6 hours. When one verifies, it replaces its own binary and restarts into it. Your identity and certificate are untouched.

To turn it back off, remove the flag (or set DEMERZEL_AUTO_UPDATE=0) and restart the service.

How a release is verified

An update is installed only if it proves who built it. This matters more than it might sound: an update channel is, by construction, a way to run new code on your server. So the agent treats the machine it downloads from as untrusted.

Every release ships a manifest — the version, and the SHA-256 of every binary in it — carrying an Ed25519 signature. Before anything is installed, the agent:

1. downloads the manifest and its signature, and verifies the signature against a public key compiled into the agent you already have — not against anything fetched from the download host;
2. checks that the version the signed manifest declares is strictly newer than the one running;
3. downloads the binary and checks that it hashes to exactly what the signed manifest says it should.

If any of those fails, the update is refused and the agent keeps running the binary it already had.

What this buys you: whoever controls get.demerzel.cloud cannot make your server run their code. They do not hold the signing key, so they cannot forge a manifest, they cannot point a real version at a binary of their own, and they cannot replay an old signed release to walk you back onto a version with a known hole — the version number is inside the signature. The worst they can do is stop serving updates.

Verifying a release yourself

The manifest and its signature are attached to every GitHub release, so you can check a binary against a source that is not the download host:

sha256sum demerzel-agent-linux-amd64
# compare with the hash for that file in manifest.json

The signing and verification code is open source and ships with the agent — the manifest format in internal/selfupdate/manifest.go, the signing tool in tools/signmanifest.

Update in place (manual)

Re-run the installer — it fetches the latest release, verifies it, and overwrites the binary in /usr/local/bin:

curl -fsSL https://get.demerzel.cloud/install.sh | sh
sudo systemctl restart demerzel-agent

Confirm the version now running:

demerzel-agent --version

Pin a specific version

To move to (or stay on) an exact version instead of the latest:

curl -fsSL https://get.demerzel.cloud/install.sh | sh -s v0.4.1
sudo systemctl restart demerzel-agent