You built your golden image with bootc, pushed it to your registry, and felt great about having an immutable base. Then you wired up cloud-init to handle the last-mile configuration on first boot. The problem is that cloud-init runs once and leaves. If your bootc image gets updated but your cloud-init logic assumes a specific state that has shifted, you’re looking at a drift that no one bothered to track. I have seen this lead to nodes that think they are perfectly configured but actually lack the specific runtime patches needed for the latest container runtime versions.

The trap of the one-shot configuration

Cloud-init is great for setting hostname and injecting public keys, but it is not a configuration management tool. When you start baking heavy package installs or complex sysctl tweaks into a cloud-init user-data script on top of an immutable OS, you’re fighting the architecture. The moment your bootc image updates, you have no guarantee that your cloud-init script will play nice with the new binary versions. Keep your state separate from your OS base, or better yet, move that logic into the container build process itself.

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

• Audit your cloud-init logs at /var/log/cloud-init.log for ignored modules after image updates
• Prefer layered containers over complex run-once shell scripts
• Verify your image digests in your deployment manifest to avoid silent version mismatches
• Use local systemd units for tasks that must repeat rather than cloud-init if the state changes frequently

Next time you push a deployment, verify what version is actually running rather than assuming the orchestrator got it right. A quick check of your image reference will save you an hour of debugging why your local user data did not apply the second time around. If it is not part of the base container image, treat it as transient and stop relying on it to fix your OS.