We have spent years treating servers like pets, SSHing in to tweak configs and install a quick package here or there. Then we moved to immutable OSes like Fedora CoreOS or images built with bootc, thinking we had solved the drift problem forever. But the reality is that the gap between your image build and your live production environment is where the real headaches hide, especially when your ignition config is misaligned with the actual state of the disk.

Why cloud-init doesn’t care about your build pipeline

Cloud-init is great until it is not. It fires once at first boot, does its work, and leaves you with a running system. If you change your base image, that existing ignition config sitting on your cloud provider is not going to magically update the files you manually placed three months ago. You end up with a hybrid monster, half-containerized, half-legacy, and entirely unmanageable when the security team asks for an audit of your systemd drop-ins.

bootc status --details

• Stop mounting host directories unless you are prepared to manage their state via bootc containers
• Treat your ignition files as code that requires its own CI pipeline separate from your base image builds
• Verify your bootc deployment status on every reboot to ensure the layer sync actually worked
• Stop injecting sensitive credentials via cloud-init userdata when secret stores exist for a reason

If you are still pulling packages inside a cloud-init script, you are just building a traditional server with extra steps. Shift that logic into the bootc image build itself. By moving your custom configurations into the container layers, you guarantee that what you tested in dev is exactly what you are booting in prod. Next time you notice a weird binary sitting in /usr/bin that no one remembers putting there, check your container file first instead of blaming a rogue automation script.