Stop treating your immutable OS images like traditional pets
Technical Briefing | 7/15/2026
You probably spent years perfecting your Ansible playbooks, massaging configuration files into place, and hoping the drift stayed under control. Then you moved to an immutable OS approach using bootc, and suddenly your old habits are fighting the architecture. Most people try to shoehorn shell scripts into the boot process or keep injecting sidecar packages on top of the base image, but that defeats the entire point of atomic updates.
The trap of runtime injection
I have seen too many teams build a base image and then continue to treat it like a mutable server by using cloud-init to install heavy runtime dependencies. If you are doing this, you are effectively running a hybrid system that is twice as hard to debug. You lose the atomicity of your OS updates because your runtime environment is constantly drifting from the source image. Stop baking in workarounds and push that logic into the container build layer instead.
bootc status --json | jq .status.staged.image
- Audit the bootc image for stale libraries before you even attempt a deployment
- Keep your cloud-init files strictly for identity and networking, not for software provisioning
- Version your image manifests as strictly as you version your application code
If you find yourself needing to hack a kernel module or a system-level driver into the boot process, stop. Move that logic into a containerized build workflow that produces a secondary image layer you can pull. It feels slower at first to build an image instead of running a quick dnf install, but you will stop having those 3 AM panics where a server reboots into a broken state because a dynamic dependency changed out from under you. If you really want to sleep better, embrace the rebuild.
