Image Mode (bootc)

RHEL Image Mode, GA since RHEL 9.6 and built into RHEL 10, is a new way to deliver the operating system: pack the entire OS (kernel, packages, configuration) into a single OCI container image, then build, distribute, and update it with the container toolchain. The core component is bootc (bootable containers). Nothing underneath changes — packages, kernel, and systemd are the same as traditional RHEL. What changes is the delivery model.

Why Image Mode Exists

The pain points of traditional RHEL operations:

Applications go into containers, but the OS itself is still configured layer by layer with RPM plus Ansible — two artifacts, two pipelines
System state “drifts”, hard to reproduce, with rollback depending on backups
Debugging differences between development, testing, and production is expensive

Image Mode’s answer:

One artifact: applications and the OS live in the same container image, distributed from the same registry
Immutable base, declarative updates: the system is defined by the image; updating means pulling a new image, and rollback is built in
Familiar tools: build with a Containerfile plus Podman/Buildah — no new DSL to learn

Core Concepts

Concept	What It Is
rhel-bootc	Red Hat’s official bootable base image (registry.redhat.io/rhel10/rhel-bootc)
bootc	Tooling to install, boot, and update image-based systems (`bootc upgrade`, `bootc status` on the host)
Containerfile	Same as ordinary container builds, but the output is a bootable image
bootc-image-builder	Converts bootc images into ISO, qcow2, AMI and other media (deprecated; superseded by osbuild’s image-builder)

Quick Start: Building a Custom OS Image

1. Write the Containerfile

# The RHEL bootc base image lives on registry.redhat.io and needs a login (subscription):
#   podman login registry.redhat.io
# Without a RHEL subscription use a community base image, e.g. quay.io/centos-bootc/centos-bootc:stream10
FROM registry.redhat.io/rhel10/rhel-bootc:latest

# Identical to ordinary image builds: install packages, copy config
RUN dnf -y install nginx && dnf clean all
COPY nginx.conf /etc/nginx/nginx.conf
COPY app.conf /etc/sysctl.d/

# Declare boot-time services with systemd units
RUN systemctl enable nginx.service

2. Build and Push

$ podman build -t quay.io/yourorg/rhel-custom:1.0 .
$ podman push quay.io/yourorg/rhel-custom:1.0

3. Install onto Machines

Two routes:

Install to disk: bootc install to-disk must run inside the target image container with --privileged (or from a prepared install ISO) — it is not run directly on a bare-metal host, where the bootc command usually does not exist. On a system already running bootc, use bootc switch to move to your image.
Cloud/VM images: generate qcow2, AMI or ISO with osbuild’s image-builder (the old bootc-image-builder is deprecated upstream)

$ sudo podman run --rm --privileged --pid=host \
    -v /var/lib/containers/storage:/var/lib/containers/storage \
    -v /dev:/dev -v /run/udev:/run/udev \
    quay.io/yourorg/rhel-custom:1.0 bootc install to-disk /dev/sda

# bootc-image-builder is deprecated upstream; the new flow uses osbuild's image-builder CLI.
# Subcommands and image tags change between versions -- follow the osbuild / image-builder docs.
$ podman run \
    --rm -it --privileged \
    --volume ./output:/output \
    quay.io/centos-bootc/bootc-image-builder:latest \
    quay.io/yourorg/rhel-custom:1.0 --type qcow2

4. Day-2 Updates and Rollback

On a running bootc system:

$ sudo bootc upgrade
$ sudo systemctl reboot

# Roll back to the previous image when something breaks
$ sudo bootc rollback

Updates run automatically on a systemd timer — think of it as “a yum update driven by git”.

Compared with the Traditional Approach

Dimension	Traditional RHEL (RPM + Kickstart)	Image Mode (bootc)
System definition	Package list + config management tool	One container image tag
Updates	dnf upgrade	bootc upgrade (pull image)
Rollback	Depends on snapshots/backups	Built-in previous-boot rollback
Build output	ISO + Ansible playbook	OCI image
Package changes	dnf install anytime	Change the image and republish (host still supports dnf for emergencies)

When to Use It (and When Not)

Good fit:

Large, standardized server fleets (edge, cloud, CI runners)
Compliance scenarios that want “system version = image tag” auditability
Teams already running GitOps/container pipelines who want the OS in the same pipeline

Not yet a fit:

Single, constantly changing experimental boxes (package-level flexibility wins)
Setups relying on third-party kernel modules or frequent hardware changes (verify first)
Small environments with no container toolchain — Image Builder and Kickstart deliver more direct value there