Signed auto-update + rollback
sha256 + ed25519 verification before swap; auto-rollback if the new binary doesn't heartbeat within 5 minutes.
Last updated May 27, 2026
What it is
A three-step update pipeline that keeps deployed agents on the latest code without operator intervention, AND survives a bad release without manual recovery:
- Heartbeat-advertised release. On every 30 s heartbeat,
the cloud responds with
update: {version, url, sha256, sig}when a newer build is staged. - Verify-before-swap. Agent downloads, verifies the sha256, then verifies the ed25519 signature against an embedded public key. Mismatch → refused; no on-disk swap.
- Rollback verifier. Pre-swap, the current binary is copied
to
<exe>.prev+ a marker is written. After restart, if no heartbeat lands within 5 min, the verifier restores.prevand exits.
What it produces
- On the dashboard: a “update → X.Y.Z” pill next to any agent whose self-reported version differs from the staged release.
- On the host: the binary swap + a brief log line:
auto-update: swapped to 0.4.0, exiting for supervisor restart - On the cloud: the agent’s
versionfield flips on first heartbeat after the swap.
What to use it for
- Pushing security fixes to deployed agents same-day, without operator action
- Rolling out new task kinds (new fingerprint capability, new exploit type)
- Avoiding the “we have 200 agents on 19 different versions” problem every SaaS-with-an-agent eventually has
Why it matters
Once you have customers running an installed binary, you cannot expect them to manually update it. Every fix you ship, every CVE you patch, has to roll out automatically, and has to roll BACK automatically if it breaks, because you can’t SSH into a customer host to recover.
Why it’s valuable
- sha256 + ed25519, both verified. sha256 catches accidental corruption; ed25519 catches a compromised control plane (the signing key is offline, never on the cloud).
- 5-min rollback safety. A bad release that prevents the agent from heartbeating gets reverted automatically. Supervisor brings the previous version back up.
- —pinned-version override. Paranoid customers can pin a specific version; updates with a non-matching version are refused.
How to use it
Automatic: no operator action needed for the happy path. To pin:
umbra-agent --pinned-version 0.4.0
…or in JSON config:
{"pinned_version": "0.4.0"}
The dashboard surfaces version drift with an update → X.Y.Z
pill on each agent row. Hover for “next heartbeat will swap.”