Stop fighting cloud-init when you switch to bootc images

Cloud-Native Linux (Cloud-Init, Immutable OS, Bootc)

Stop fighting cloud-init when you switch to bootc images

Technical Briefing | 8/31/2026

Transitioning to immutable base images sounds great until you realize your decade-old cloud-init scripts are fighting the new bootc architecture. If you are used to drifting your system configuration via post-boot scripts, you are going to have a bad time. Bootc wants you to burn the config into the image, and if you keep trying to monkey-patch the rootfs at runtime, you are effectively breaking the one benefit of immutability.

Why cloud-init feels like a second-class citizen now

Most of us grew up with cloud-init doing the heavy lifting on first boot. It installed packages, touched files, and managed users. But with an immutable workflow, you should be defining your state in your container image. If you are relying on cloud-init to pull down an extra five packages every time a node scales, you are just waiting for a mirror to go down during an outage. Burn that state into the image instead.

bootc build using-containerfile Containerfile --tag my-custom-os:latest

  • Stop using runcmd to install packages that should exist in the base layer.
  • Shift your user management logic into the Containerfile build process.
  • Treat cloud-init only for ephemeral identity and network metadata.

Accept the shift toward pre-baked state

I have seen people try to shoehorn dynamic logic into bootc-based images, resulting in a system that is neither fully immutable nor particularly easy to debug. If you need a different configuration, build a different container image. It adds a step to the pipeline, sure, but it guarantees that what you tested in CI is exactly what is running in prod. When something breaks, you stop looking at log files from a configuration drift nightmare and start looking at the diff between your container versions.

Keep cloud-init for the things that literally change per-instance, like ssh keys or local disk mount points. Everything else belongs in the container manifest. Trust me, it is much easier to manage a versioned image than a pile of shell scripts that fail half the time because a service started before a package was ready.

Linux Admin Automation  |  © www.ngelinux.com  |  8/31/2026

0 0 votes
Article Rating
Subscribe
Notify of
guest

0 Comments
Newest
Oldest Most Voted