You’ve just provisioned a shiny new immutable OS instance — maybe it’s a bootc image, maybe something else in that vein. It boots up, does its initial cloud-init dance, and everything looks good. Days or weeks later, it reboots for an update, or perhaps the instance ID changed for some reason, and suddenly you notice cloud-init churning away for far longer than you’d expect. What gives? Didn’t we set everything up already? This isn’t just about wasted CPU cycles; it’s about predictable system behavior on hosts that are supposed to be, well, immutable.

Why immutable OS needs smarter cloud-init configuration

On a traditional, mutable Linux VM, cloud-init doing a bit of extra work on subsequent boots might be an annoyance, but it’s rarely a showstopper. It’ll run, maybe re-check a few things, and move on. The underlying filesystem is designed to accept changes, so if a module re-applies an NTP config or hostname, it’s usually benign. But with an immutable OS, you’re changing the game. The core system is locked down; any configuration change that isn’t part of the image, or specifically handled by an overlay, is often ephemeral. So, when cloud-init modules insist on re-running and trying to apply configuration that’s either already baked into the image, or will be reverted on the next reboot, you’re just burning API calls, network requests, and boot time for zero gain. I’ve seen this silently extend boot times by thirty seconds on large fleets, which really adds up.

The issue stems from how cloud-init’s various modules operate across its different execution phases (local, network, config, final). Some modules are explicitly designed to run on every boot if their state suggests a change, or simply because they’re marked as ‘always_run’. Others might re-evaluate based on instance metadata. On an immutable system, you’ve likely integrated a lot of your desired configuration directly into the image itself, rendering many of cloud-init’s post-boot tasks redundant. Understanding which modules are spinning their wheels needlessly is the first step.

cloud-init analyze show

Taming the repetition: Disabling modules surgically

The output of `cloud-init analyze show` gives you a clear breakdown of what modules ran during a particular boot and how long they took. If you see modules consistently taking time that you know are redundant (e.g., `mounts` trying to mount filesystems already defined in your immutable image, or `update_hostname` when your hostname is statically managed by `bootc`), you’ll want to disable them. The right way to do this at a per-instance level, even on an immutable system where `/etc/cloud/cloud.cfg` might be part of the base image, is through `user-data`’s `write_files` directive. You can drop a new configuration file into `/etc/cloud/cloud.cfg.d/` that merges with or overrides the default settings.

• cc_mounts: Often tries to process mount points. If these are part of your immutable image or handled elsewhere, turn it off.
• cc_update_hostname: Useful for initial setup, but can be redundant if your hostname is managed internally by the image or by a first-boot script.
• cc_ntp: If your immutable image already has `timesyncd` or similar configured, there’s no need for cloud-init to touch this.
• cc_set_passwords: Crucial for initial password setting, but after the first boot, it’s often safer and unnecessary to have this running again.
• cc_ssh: If your SSH host keys are baked into the image or handled by a separate process (like tpm-sealed keys), cloud-init’s SSH module might be redundant.

By strategically placing these configuration overrides in your `user-data`, you ensure that cloud-init behaves exactly as you need it to for an immutable workload. It’s not about gutting cloud-init entirely; it’s about making it a precise tool that executes exactly what you need, once, without burning cycles on tasks your system already handles or shouldn’t be repeating. Getting this right means faster boot times, fewer surprises, and a truly predictable cloud-native experience.