An immutable OS that upgrades itself

The trouble with hosts you can log into

Most appliances start life clean and slowly rot. Someone SSHes in to fix a production issue, installs a debugging tool, edits a config file, and forgets to write it down. Multiply that across a fleet and every box becomes a snowflake: subtly different, impossible to reproduce, terrifying to upgrade.

In-place OS updates make it worse. A package upgrade touches hundreds of files across the running system. If it fails halfway — a dependency conflict, a full disk, a power blip — you are left in a state that is neither the old version nor the new one, and no one can say exactly what is on the box anymore. “Works on my machine” is really just “my machine drifted somewhere useful, once.”

Immutable is the fix

Modern immutable, container-oriented OS designs take a different stance: the root filesystem is a single, read-only, versioned image. You never patch it in place. To change anything, you build a whole new image and switch the machine to it. The running system is exactly the artifact you built and signed — no more, no less.

That gives you three properties for free:

• Reproducible — the image is a build output. The same inputs produce the same root, byte for byte.
• Auditable — you know precisely what is running, because it is a versioned artifact rather than an accreted history of apt runs.
• Atomic — you either boot the new image or you don’t. There is no half-applied state.

How SiHA does it

SiHA ships as one squashfs read-only root image, booting under enforced UEFI SecureBoot: a signed UKI (unified kernel image) launched by signed sd-boot. The boot chain is verified before the kernel ever runs.

On the appliance there is no SSH, no systemd, and no cloud-init. A tiny supervisor runs as PID 1: it does platform init — mounts, signal handling, seeding — then spawns and supervises the VPP dataplane and the control-plane daemons. Dropping the usual middleware is not just tidiness; it is a smaller attack surface. There is no shell to compromise, no service manager to misconfigure, and the root filesystem is read-only, so there is nothing to persist a tampered binary into.

Reduced attack surface, signed boot chain, read-only root. To be precise about scope: this is a signed boot chain plus a read-only root, not disk encryption and not full verified-boot of the root contents. Those are out of scope here — we don’t claim them.

A/B slots and the one-shot try

The image lives in one of two slots, A and B. At any time one slot is active and running; the other is idle.

An upgrade is deliberately boring:

1. Write the new image to the inactive slot. The running system is never touched.
2. Flip the bootloader entry to the new slot as a one-shot “try”, with a fallback counter set.
3. Reboot.

That is the whole mechanism. If step 3 goes badly, you have lost nothing: the old, known-good slot is still sitting there intact.

Health-gated, with automatic rollback

The one-shot try is where SiHA earns its keep. After the machine boots the new slot, it runs its health checks. Only a healthy boot — one that comes up and confirms itself — gets committed as the new default.

If the checks fail, or the system never confirms at all (it hangs, panics, or loops), the bootloader’s fallback counter simply expires. On the next boot the loader returns to the previous known-good slot automatically. No operator has to notice, wake up, or intervene.

This inverts the usual risk profile of an OS update. Instead of “cross your fingers and hope the patch applied cleanly,” the worst case is: the new version misbehaves, the box reboots once, and you are back on the exact version you were running before — untouched, unpatched, unsurprising.

Upgrades become a non-event. Best case, you’re on the new build. Worst case, you’re on the old one, one reboot later, with nothing to clean up.

Why it matters for a dataplane box

A firewall/router/load-balancer sits in the path of everything. It is the last place you want a snowflake host or a half-applied update. Pushing 10 GbE line rate — 14.88 Mpps for 64-byte frames — through VPP is hard enough without also wondering whether the OS underneath is the one you tested. An immutable root plus health-gated A/B upgrades means the platform under the dataplane is as declarative and predictable as the config running on top of it.

Want the full picture of how the supervisor, dataplane, and control plane fit together? See the architecture overview.