Actually, I should clarify – I spent the better part of last Thursday debugging a Kickstart file that hadn’t been touched since 2022. You know the type. It had three different post-install scripts, a sed command that I’m pretty sure was written by a ghost, and it failed silently 40 minutes into the build process.

But then I remembered that it’s 2026 and we don’t actually have to do this anymore. If you are still building OS images for your edge devices or servers using legacy image builders, you are probably choosing violence. The paradigm shifted while we were all arguing about tabs versus spaces. We’re building operating systems with Containerfiles now.

The “Aha” Moment with bootc

The concept of bootc (bootable containers) isn’t brand new—we saw the initial hype back in 2024—but the tooling has finally caught up to the promise. And frankly, it’s embarrassing how much easier this is than my old workflow.

The idea is stupidly simple: You write a Containerfile (Dockerfile). You build it with Podman. But instead of running it as a container on an OS, that container is the OS. You boot straight into it.

It’s Just a Containerfile

I was skeptical at first. But look at this. This is literally all I needed to create a bootable Fedora 43 server image with my specific admin tools baked in:

FROM quay.io/fedora/fedora-bootc:43

# Install my standard admin tools
RUN dnf -y install \
    htop \
    ripgrep \
    neovim \
    NetworkManager-tui \
    && dnf clean all

# Create a user with sudo access (don't do this in prod without SSH keys)
RUN useradd -G wheel -m adminuser && \
    echo "adminuser:secretpassword" | chpasswd

# Enable necessary services
RUN systemctl enable sshd.service

# Copy my custom motd because I have an ego
COPY motd /etc/motd

That’s it. No %post sections. No partition tables defined in obscure syntax. I ran podman build -t my-server-os . and I had an image.

The “Gotcha” That Bit Me

Of course, nothing is perfect. I ran into a wall immediately when I tried to deploy this to a bare-metal NUC I use for testing.

The problem: Persistent State.

I treated the OS image exactly like a standard application container, assuming I could just bind mount whatever I needed later. But when you boot a system, /etc is mutable (via overlay), but you have to be very intentional about /var.

Performance Check: VM vs. Container Build

Environment: Apple M3 Pro, running Podman 5.4.0 in a VM.

• Packer + Ansible build: 14 minutes, 22 seconds. (Mostly waiting for dnf installs and VM boot overhead).
• Podman build (cold): 3 minutes, 45 seconds.
• Podman build (cached): 12 seconds.

Because it utilizes container layer caching, if I just change the COPY motd line in my Containerfile, I don’t have to reinstall 500 RPMs. It just swaps the layer and exports the image. This is the killer feature. It turns OS development from a “go get coffee” task into an interactive process.

Why You Should Care (Even if You Don’t Use Podman Desktop)

I know a lot of hardcore CLI users roll their eyes at desktop GUIs. But the Podman Desktop extension for this is actually useful for one specific reason: visualization of the output formats.

The Verdict

We are moving toward a world where the line between “application” and “operating system” is basically gone. If you can write a Dockerfile, you can now build a custom Linux distribution tailored exactly to your needs, updated via a container registry.

Is it perfect? No. But compared to maintaining Kickstart files or debugging Ansible failures over SSH? I’ll take the Containerfile any day.