Stop fighting your immutable OS updates and start versioning your bootc state

Technical Briefing | 10/24/2026

Transitioning to an immutable OS like Fedora CoreOS or a bootc-based image is great until you hit the first update cycle. Most of us are used to slapping an update command into a script and calling it a day, but that approach falls apart when the entire OS is a single atomic unit. I have seen more than a few junior engineers try to treat these systems like a standard Debian box, only to end up with a broken deployment and no way to roll back because they ignored the bootc lifecycle.

Treating your OS as a container registry artifact

The shift here isn’t just about the filesystem being read-only. It is about shifting your mental model from patching packages to pulling a new image. If you are still SSHing into hosts to fix drifting configurations, you are doing it wrong. Instead, you need to be building your host images with bootc, pushing them to your registry, and letting the fleet pull the new image hash during your maintenance window. When the update lands, the switch is atomic, and the rollback is a one-line reboot.

bootc switch quay.io/your-org/custom-base:latest

• Avoid using rpm-ostree overrides unless you absolutely must
• Keep the base image lean by moving your service configs to container sidecars
• Use the image digest rather than tags for deterministic deployments in prod

The real trap is thinking you can sneak in a configuration change via cloud-init after the image has booted. While cloud-init is fine for initial provisioning, it shouldn’t be your day-to-day configuration management tool. If your host needs a new sysctl setting or a custom service, bake it into the container image itself. If you keep treating your immutable nodes like snowflakes, you will eventually find yourself with a pile of nodes running different configurations, and then you are back to the same mess we were supposed to escape years ago.