Stop treating your bootc images like they are just fat containers

Technical Briefing | 9/27/2026

You probably started playing with bootc because you were tired of managing drift across a fleet of servers. It is tempting to shove your entire stack into a container image and push it to production like you would a microservice. But I have seen this blow up in staging more than once when the underlying host-level dependencies or kernel parameters weren’t actually what the image expected at runtime.

The trap of the monolithic root filesystem

The biggest mistake is ignoring the host configuration lifecycle. Just because your base OS is immutable doesn’t mean your host state is static. You still have network settings, storage partitioning, and secrets that need to be injected before the first boot. Cloud-init is still doing the heavy lifting here, and if you treat your image as a black box without accounting for the cloud-init integration, you are going to end up with nodes that simply refuse to join the cluster.

bootc status --booted

• Use custom cloud-init snippets to verify local storage after the image pull
• Keep your kernel arguments strictly separated from your image build layers
• Test your deployment logic with a virtualized environment before touching bare metal

When your image deployment fails, don’t just inspect the container layer. Check the bootc status to confirm which manifest the node thinks it is running. Most of the time, the drift isn’t in your software, but in a mismatch between the base image version and the specific cloud-provider bootloader configuration that keeps getting reset by your automation. Keep a close eye on the image digest in your bootc manifests, because relying on latest is a shortcut to midnight debugging sessions you really do not want.