Self-upgrade

A box keeps its in-guest krillbox tooling current — signed, verified, opt-in.

Boxes are thin clones of a golden image, so over time the krillbox guest binaries inside a long-lived box drift behind what the platform ships. Self-upgrade lets a box pull the newer binaries from the host, verify them, install them atomically, and reload the affected components — without recreating the box.

Versions & drift

Every box reports a guest version in its heartbeat. The control plane compares it against the version the platform currently ships and flags boxes that are behind (visible in metrics / dashboards).

krillbox-guest version        # the guest version this box runs
krillbox-guest info           # includes guest_version + the expected version

Upgrading on demand

krillbox-guest upgrade           # dry run: verify + show what would change
krillbox-guest upgrade --apply   # fetch, verify, install, reload

The box fetches a manifest of the shipped binaries, verifies its ed25519 signature against a public key baked into the box, and for each binary whose content hash differs it downloads the blob, re-checks the hash, and installs it with an atomic rename. New code takes effect when its component reloads (see below).

Automatic, opt-in

krillbox-guest upgrade --auto on       # this box converges on its own
krillbox-guest upgrade --auto off      # back to manual (default)
krillbox-guest upgrade --auto status

With auto on, the box's heartbeat periodically checks for a newer version and applies it the same way --apply does. It's off by default and set per box, so you can roll a canary first. (Bake the marker into a golden to default it on for a whole image.)

How it takes effect

• The guest agent and its listeners reload in place — the box does not reboot and your shell/processes are untouched.
• The in-guest CLI (krillbox-guest) is live on its next run.
• The init process itself (PID 1, on agentless images) can't swap live — the new binary is staged and takes effect on the next boot or resume.