Stop your bootc images from carrying around stale cloud-init baggage

Technical Briefing | 7/31/2026

Building containerized OS images is supposed to simplify your life. You package your dependencies, bake in the config, and deploy. But more often than not, I see engineers baking generic cloud-init configs into the base image itself. That’s a mistake. You end up with static user accounts and hardcoded datasource expectations that break the moment you move that image from AWS to bare metal.

Why pre-baking cloud-init feels like a trap

When you embed cloud-init logic inside your bootc image, you are effectively tethering your immutable OS to the environment it was built for. Cloud-init is a runtime configuration tool, not a build-time configuration tool. If you hardcode your network interface definitions or SSH keys, you aren’t just configuring the system; you’re poisoning the portability. Once that image hits a new provider, the metadata service won’t match, and you’ll spend hours debugging why your network hangs during boot.

bootc image build --build-arg 'CLEAN_CLOUD_INIT=true' -t quay.io/example/my-os:latest .

• Delete the /var/lib/cloud/instance folder inside your Dockerfile before the final commit
• Strip all vendor-specific data sources from the cloud-init config files
• Move sensitive identity management to an external tool like HashiCorp Vault or FreeIPA
• Ensure the cloud-init service is enabled but not pre-seeded with instance-specific artifacts

The right way to handle this is to treat your image as a blank slate. If you need dynamic identity, rely on the metadata service the platform provides at runtime. Keep your build artifacts completely provider-agnostic. Next time you see a hung boot process, check if you accidentally baked your development environment’s cloud-init secrets into the production image. It’s an easy fix that saves you from a total rollback.