Stop fighting over post-boot configuration in your bootc images

Technical Briefing | 7/18/2026

You spend hours perfecting your container image for bootc, ensuring the base OS is lean and mean. Then you deploy it to a cloud provider and find yourself back to the stone age, relying on cloud-init scripts to hammer the system into shape post-boot. It’s a mess. Your image says one thing, your configuration file says another, and you’re left with a system that has drifted from its original state before it even finishes joining the cluster.

The trap of late-stage configuration

Most of us use cloud-init to inject SSH keys or update package mirrors, but that is a mistake when using immutable OS workflows. If your image requires runtime modification to be usable, you’ve essentially invalidated the benefit of testing the image as a single, immutable artifact. Stop treating your bootc host like a VM template you can patch on the fly. If it needs to be there, put it in the container build.

podman build -t my-immutable-os -f Containerfile . && bootc build --type qcow2 --target-no-signature-verification my-immutable-os

• Embed your primary system configuration files directly into /etc during the container build phase
• Use systemd-sysusers to bake your service accounts into the image rather than creating them on first boot
• Hardcode your custom repository configurations in the container image to bypass network-dependent cloud-init updates

Making the transition to truly immutable

Shift your perspective: cloud-init should only be responsible for ephemeral identity tasks, like instance-specific disk mounting or metadata ingestion. Everything else, from kernel parameters to hardening scripts, belongs in the container layer. If you catch yourself writing a cloud-init script to install a package, stop. Open your Containerfile, add the rpm-ostree install command, and rebuild. Your future self debugging a fleet of identical servers will thank you.