You spend hours crafting the perfect bootc image, only to realize that hardcoding a static IP or a specific bond configuration traps that image in a single subnet. When you try to move that same node to a different rack, the whole thing falls over on boot. I have seen this turn a simple hardware refresh into a weekend-long troubleshooting disaster.

Why your image should stay oblivious to the network

The temptation to stick a network config file into the image is strong because it feels like complete automation. But the right approach is to treat the base OS as a pure artifact and push the network stack into cloud-init or a separate Ignition config. By decoupling these layers, you can deploy the exact same immutable binary across different availability zones or even bare metal without rebuilds.

bootc image switch --transport registry quay.io/my-org/my-app:latest

• Use kernel parameters to point the node to a network config source that exists outside the image
• Avoid using NMState in the build phase if you want to reuse the image across different sites
• Rely on cloud-init metadata providers to inject your interface bonds at runtime

If you are struggling with images that refuse to talk to the gateway, check your initrd contents. Sometimes, specific NIC drivers get left behind because the builder assumed a standard environment. When the network isn’t coming up, dump the journal before the network manager tries its hand, and you might find the driver was never loaded to begin with.

Next time you feel like adding a site-specific config file to your Dockerfile, stop. If you keep the networking logic external, you won’t need to rebuild your stack just because a VLAN ID changed.