Everyone loves a good golden image until they have to patch a fleet of them. You start with a base, bake in your security agents, add a few config files, and push it to your registry. Then a CVE drops, and you are back to square one, running the same CI pipeline just to bump a kernel version. It is tedious work that hides the real problem: you are treating your OS like a pet, even if you are building it with code.

Why bootc is the inevitable shift

The transition to container-native OS builds is what happens when you stop fighting the immutable infrastructure model. With bootc, your operating system isn’t an artifact produced by a separate pipeline, it is just a container image that happens to have a kernel. You get the same layer-based caching benefits for your rootfs that you already use for your apps. If you break the bootloader config, you just roll back the image update, not the hardware.

bootc switch --transport registry quay.io/example/my-os-image:latest

• Layering security patches becomes as fast as a container pull
• The OS filesystem becomes read-only by default
• Deployment syncs across edge sites without manual PXE tinkering
• Kernel parameters live in your container build context

Where the pain still lives

Transitioning to an immutable OS isn’t all upside. You lose the ability to go rogue and install random debugging tools via dnf on a whim. That feels like a loss of power, but it is actually a design feature. If you find yourself needing to hack a live system, look at what was missing from your base image and put it into the next build. If you can stop opening shell sessions for troubleshooting, you have finally won the war against configuration drift.

Next time a kernel vulnerability hits, look at your CI run logs for your app vs your OS. If the OS build takes longer or feels more manual, that is your target for the next sprint. Don’t be the person manually running updates on fifty nodes when a registry tag is all it takes to propagate a hardened kernel across the entire rack.