Don’t let cloud-init fight your immutable image for control

Technical Briefing | 10/15/2026

Building an immutable OS image with bootc is great until you realize your cloud-init configs are still trying to mutate the system on every boot. You end up with a weird hybrid state where your container-based image says one thing and your cloud-config files are desperately trying to override network or user settings behind your back. I have seen this lead to some nasty race conditions where the systemd service starts before the cloud-init module finished nuking your carefully crafted state files.

The battle for ownership of /etc

On a standard mutable system, cloud-init is a guest that moves in and starts rearranging the furniture. On a bootc-managed host, your image is the homeowner. If cloud-init tries to touch /etc/hostname or generate SSH keys that you already baked into your image, you are setting yourself up for inconsistent deployments. You should really be leaning into image-based configuration for everything that does not change between boots, and only using cloud-init for the absolute bare minimum identity injection.

bootc status --json | jq .status.staged.image.reference

• Disable cloud-init modules that conflict with your image defaults like users-groups or write-files
• Move static network configurations into your base image layer rather than relying on network-config-data
• Use cloud-init strictly for instance-specific metadata like local drive mounting or secrets

If you find yourself using cloud-init to install packages or update configs, stop. Bake those into the container image itself. It makes your rollouts predictable and prevents the cloud provider from accidentally injecting something that breaks your base image. If the build succeeds, the deployment should be identical every single time it lands on a new node.

Next time you provision a node, pull up the cloud-init logs and filter specifically for the modules that took the longest to run. If you see things in there that belong in your container layer, treat that as technical debt and move them into your next image build. You will save yourself a massive headache the next time a cloud provider changes how they format their metadata response.