RHEL Image Builder 10.2 and 9.8: A Golden Image Checklist

Red Hat’s latest Image Builder update is easy to read as a feature announcement: RHEL 10.2 and 9.8 add new build paths, the unified image-builder command gets more responsibility, and the RHEL 10 web console grows a guided workflow. For platform teams, the more useful interpretation is operational: golden images need the same release discipline as application artifacts.

The official Red Hat post says Image Builder creates custom RHEL images with preinstalled software and configuration for virtual machines, cloud targets, and bare metal. Red Hat also points to hosted building in the Hybrid Cloud Console and on-premises building through the command line or web console. That makes Image Builder a control point for repeatable infrastructure, not just a convenience tool.

This Learning Hub checklist focuses on RHEL 10.2 and 9.8 environments that need repeatable images for virtualization, PXE, boot ISO, cloud, or image mode for RHEL. It uses Red Hat’s announcement, Red Hat’s Image Builder overview, and OSBuild’s Image Builder documentation as the source of truth.

What changed in RHEL 10.2 and 9.8

The headline is consolidation. Red Hat says the image-builder command is available as an RPM in the AppStream repository and as a container image in the Red Hat container registry. In the same update, Red Hat says the similar containerized bootc-image-builder tool is deprecated.

For image mode for RHEL, the update matters because the unified command can now build bootable artifacts from a bootc container reference. Red Hat’s RHEL example builds a virtualization image:

# Target context: RHEL 10.2 or 9.8 Image Builder host after authenticating to registry.redhat.io.
# Source: Red Hat's RHEL 10.2/9.8 Image Builder announcement.
image-builder build qcow2 
  --bootc-ref=registry.redhat.io/rhel10/rhel-bootc:latest

Red Hat’s post also says Image Builder can build PXE images for package mode and image mode for RHEL, and network installer boot ISO images for package mode RHEL. On the RHEL 10 web console side, Red Hat describes a guided image mode workflow, direct VM launch for built .qcow2 guest images when the host can run nested virtualization, and OpenSCAP profile selection during blueprint creation.

A production checklist for RHEL golden images

1. Classify the artifact before selecting the interface

Start with the deployment target, not the tool. A .qcow2 VM image, a PXE boot archive, a network installer ISO, a cloud image, and a bootable image mode artifact all have different promotion and rollback requirements. Put each image request into a short matrix:

• Target platform: virtualization, cloud, bare metal, edge, PXE, or boot ISO.
• RHEL mode: package mode or image mode for RHEL.
• Build interface: hosted Red Hat Lightspeed image builder, local RHEL web console, or local image-builder CLI.
• Promotion gate: smoke test, compliance scan, vulnerability check, and owner sign-off.

Red Hat’s Image Builder overview frames golden images as a way to deploy consistent, repeatable operating-system images that conform to a standard operating environment. Treat that standard as an input to the build pipeline, not as a wiki page someone manually follows.

2. Decide package mode versus image mode early

Package mode still fits images that are composed from RPM packages and traditional system configuration. Image mode for RHEL fits teams that already package the operating-system filesystem as a bootable container. Red Hat’s RHEL 10.2 and 9.8 post says the updated image-builder command can create bootable image mode artifacts from a container image reference.

OSBuild’s Image Builder usage documentation also calls out --bootc-ref as the key argument for bootc inputs. It notes that, in upstream usage, the bootc containers used by --bootc-* arguments must be available in the container storage of the user running Image Builder before the build starts. In a RHEL production pipeline, make that an explicit preflight check: verify registry authentication, pull permissions, digest pinning, and access from the actual build host.

3. Put blueprints under change control

Red Hat’s example customizes a bootable image with a TOML blueprint. The announcement uses a simple user customization:

# Target context: RHEL 10.2 or 9.8 Image Builder blueprint example from Red Hat.
# Do not commit real passwords; use your approved secret or hashed-password process.
[[customizations.user]]
name = "alice"
password = "******"
groups = ["wheel"]

The important production step is not the demo user. It is preserving the blueprint as reviewed infrastructure code. Store blueprints beside the pipeline that builds the image, require pull-request review for package, service, user, kernel, filesystem, or compliance changes, and record which blueprint commit produced each artifact.

Blueprint review questions

• Does the blueprint add only the packages and services required for the target role?
• Are local users, SSH keys, and sudo groups approved for the deployment environment?
• Are secrets omitted from version control and supplied through an approved mechanism?
• Does the image include enough observability and break-glass access for first boot?

4. Build with a pinned source and a repeatable command

Red Hat’s announcement shows adding the blueprint to the build command:

# Target context: RHEL 10.2 or 9.8 Image Builder host building a qcow2 image mode artifact.
image-builder build qcow2 
  --bootc-ref=registry.redhat.io/rhel10/rhel-bootc:latest 
  --blueprint=blueprint.toml

For a tutorial or lab, :latest is convenient. For production, record the exact source image digest, the image-builder version, the RHEL minor release of the builder, the blueprint commit, and the output checksum. If the team cannot reproduce the same artifact from the same inputs, the image should not move to a shared catalog.

5. Shift compliance left, but still test the running image

The RHEL 10 web console update is notable because Red Hat says teams can select an OpenSCAP profile while creating an image blueprint. Red Hat describes this as build-time security hardening that configures packages, filesystem settings, kernel settings, and enabled services required by the selected policy.

Build-time hardening reduces manual drift, but it is not the final evidence. Boot the image in the same class of target it will run on, then verify account access, package inventory, service state, network configuration, logging, vulnerability scan results, and the relevant compliance profile. A hardened image that fails first boot is still a failed release.

6. Test each deployment path separately

Do not assume a clean .qcow2 build proves every target. PXE images, network installer boot ISOs, image mode artifacts, and cloud images each have different dependencies. Red Hat’s post specifically calls out PXE, network installer, VM launch, and image mode workflows, so use separate smoke tests for each path you plan to publish.

• Virtualization: boot the .qcow2, confirm cloud-init or first-boot configuration, and validate network access.
• PXE or diskless: test DHCP, TFTP or HTTP boot delivery, kernel and initramfs compatibility, and root filesystem access.
• Network installer: verify repository reachability and unattended install options before relying on the boot ISO.
• Image mode: confirm the bootc source, update path, rollback behavior, and registry access from the deployment environment.

Migration note: move away from standalone bootc-image-builder

The OSBuild deprecation notice says the project is converging package mode and image mode into a single Image Builder experience and deprecating the standalone bootc-image-builder container and CLI in favor of the unified image-builder CLI. It also says RHEL 9 and 10 retain backward compatibility for the full life of RHEL 10, while RHEL 9.8 and 10.2 begin the shift in how new major versions are shipped.

That gives teams time, but not a reason to wait. Inventory every pipeline that calls bootc-image-builder, map its inputs to image-builder, and run both paths against non-production artifacts until the outputs and test evidence are understood. The safe migration goal is not a renamed command; it is one image-building path with one audit trail.

Release gates for an Image Builder pipeline

A RHEL Image Builder pipeline should fail closed when any of these gates fail:

1. Source gate: source container, package repositories, and blueprint commit are identified and accessible.
2. Build gate: the command, builder version, logs, output checksum, and artifact location are captured.
3. Security gate: OpenSCAP or equivalent policy evidence is attached, including accepted exceptions.
4. Boot gate: the artifact boots in its target deployment class and passes health checks.
5. Promotion gate: ownership, rollback instructions, expiration date, and downstream consumers are documented.

The practical lesson from RHEL 10.2 and 9.8 is that Image Builder is becoming the common front door for more RHEL image types. Use that consolidation to remove one-off build scripts, make golden-image changes reviewable, and attach evidence before images reach production.

Sources and verification notes

• Red Hat Blog: What’s new with Image Builder for Red Hat Enterprise Linux 10.2 and 9.8
• Red Hat Customer Portal: Learn about Red Hat Enterprise Linux and Red Hat Lightspeed image builders
• OSBuild Image Builder usage documentation
• OSBuild bootc-image-builder deprecation notice
• Featured image source: CERN datacenter on Wikimedia Commons