Releases and roll-outs
Agents only install binaries signed by a key that never touches a server. The hub chooses which signed version each machine gets; it cannot supply code.
How a machine updates
The hub keeps a desired version per machine. On every connection it compares the running version with the target; if they differ and a signed manifest for the target exists, it asks the agent to update. The agent fetches its manifest, verifies the signature against the public key compiled into it, downloads the binary, verifies the checksum, swaps the binary atomically and exits so the service manager restarts it. The next connection marks the roll-out done. A manifest signed by any other key is refused and the roll-out shows failed. Rollbacks work the same way by targeting an older signed version.
Rolling out
In Updates, every machine has a version picker and a push button (arm, then confirm). The roll-out bar targets ticked rows, all visible machines, one company, or a tag such as canary. Offline machines get the target and apply it at their next connection.
curl -H "$K" -X PUT "https://hub.[yourdomain]/agents/<id>/target?approved=yes" -d '{"version":"0.7.6"}'
curl -H "$K" -X POST "https://hub.[yourdomain]/updates/rollout?approved=yes" -d '{"version":"0.7.6","tag":"canary"}'Publishing a release
If you run your own hub: build and sign on the machine that holds the signing key, then publish to the hub with the admin API key. Each release carries release notes shown in the console.
scripts/release.sh # builds every target, signs, writes notes
scripts/publish.sh https://hub.[yourdomain] # uploads binaries, checksums, manifest, notesThe signing key is the crown-jewel file: offline, backed up, never on a server. Losing it strands the fleet on the current version.
Try it on one machine first.
The install line takes a minute. Uninstall the agent and you are out.