We have spent years treating server images like artisanal baked goods. You kick off a packer build, wait ten minutes for updates to pull, inject some custom configs, and push a hundred-megabyte artifact to the cloud. By the time that image actually boots in production, half your packages are already out of date. It is a slow, brittle cycle that hides drift instead of preventing it.

Why re-baking is the wrong approach for modern stacks

The transition to container-native OS models like bootc changes the game by treating the entire root filesystem as a container image. Instead of manual provisioning, you define your system state in a Containerfile. The bootable image is just an OCI artifact. When you need to patch, you do not rebuild the world; you update the base image layer and let the host pull the delta.

bootc switch quay.io/my-org/my-os-image:latest

• Eliminate the lag between your build pipeline and your runtime patches
• Stop running custom post-install scripts that fail silently during cloud-init
• Atomic rollbacks become a simple image revert rather than a redeployment
• Keep your host configuration identical to your container base layers

If you are still using cloud-init to hammer a generic image into submission on every boot, you are just asking for flakiness. Every shell script in a user-data block is a point of failure you can avoid by moving those dependencies into the image itself. Shift your logic from runtime modification to build-time immutability, and you will spend significantly less time debugging why your dev environment looks different than production.

Next time you feel the urge to add another task to cloud-init, pause. If it can be baked into an OCI layer, put it there instead. Your future self will thank you when the fleet actually deploys predictably.