Auto-update and signing

How an update happens

1. 1.Once an hour the agent downloads a small manifest from the API that lists the SHA-256 hash of the current agent build for each architecture.
2. 2.It fetches the manifest’s Ed25519 signature and verifies it against a public key compiled into the agent. If the signature is missing or does not verify, the update is refused and the agent keeps running its current build.
3. 3.It compares the hash in the manifest with the hash of its own binary. If they match, nothing happens.
4. 4.If they differ, it downloads the new binary, checks that its hash matches the signed manifest, replaces the file atomically and re-executes itself in place. systemd keeps tracking the same service, so there is no gap in heartbeats beyond the restart itself.

The signing key is held offline, not on the API servers. A compromised download server alone cannot push a modified agent to your fleet, because it cannot produce a valid signature. The installer runs the same verification on first install and refuses an unsigned or tampered binary.

An update never changes what the agent is allowed to do

Updating the binary does not switch on remote actions or uptime probes. Commands run only on servers you have explicitly enabled in the dashboard, and probes run only on servers where you set OPSERVO_ENABLE_PROBES=true in /etc/infrapilot/config. A fleet-wide update leaves every one of those settings exactly as it was.

Seeing the version in the dashboard

The fleet table on the home page has an Agent column showing each server’s version with a green dot when it is online. A server on an older build than the one currently served shows an amber update tag; a server on the current build shows ✓ latest in the Actions column.

A server that has not yet reported whether it supports remote actions shows needs update in the Remote actions column. That is an agent from before remote actions existed; it will pick up the current build on its next hourly check if auto-update is on.

Updating by hand

If you would rather not wait for the hourly check, or you turned auto-update off, there are two ways to update now:

• •In the fleet table, click Update agent next to an out-of-date server. This needs the server to be online with remote actions enabled, because the dashboard dispatches the installer as a command.
• •On the server, re-run the installer. It reuses the existing agent ID and secret key, so the server keeps its history in the dashboard:

curl -sSL https://api.getopservo.com/install.sh | sudo env OPSERVO_API_URL=https://api.getopservo.com bash

Turning auto-update off

Add this line to /etc/infrapilot/config and restart the agent:

OPSERVO_AUTO_UPDATE=false

sudo systemctl restart infrapilot-agent

Running the binary with --dev also disables self-update, since a development build is not something the manifest can replace. With updates off, the server will keep showing the update tag in the fleet table until you update it by hand.