Image builder and image mode, counted at the host.

RHEL image builder is the productised service for composing custom RHEL images. The buyer specifies a blueprint, the service produces an image artifact in the requested target format, and the image is delivered for deployment on bare metal, on a hypervisor, into a cloud, or onto an edge device. The service runs in two postures: the hosted posture at console.redhat.com, which is available to any RHEL subscriber at no incremental fee, and the on premise posture, which runs as the osbuild composer service on a RHEL host that itself carries a RHEL subscription. Either posture is included with the base RHEL line and there is no separate image builder SKU.1

RHEL image mode is the second half of the licensing reading. Image mode is the delivery method introduced as a supported posture in recent RHEL releases that ships the operating system as a bootc container image rather than as a conventional package install. The host boots the image atomically, updates by switching to a new image version, and rolls back by reverting to the prior image. The delivery is structurally close to the ostree pattern used on the edge variant. The licensing model is unchanged: the host carrying the bootc image pays for itself as RHEL on the appropriate tier. The cross reading with the edge variant of the same delivery sits in the RHEL for edge and embedded licensing note.

What changes with image builder and image mode is not the licensing line. What changes is the operational pattern around it. The buyer running image mode at scale produces and deploys a far larger number of distinct image versions across the trailing year than the buyer running the conventional package install pattern; the buyer running image builder produces and ships images to deployment targets the procurement team has not historically seen. Both patterns reshape the question the procurement register must answer. The cross reading with the broader RHEL practice sits in the RHEL practice.

Three counting traps recur on RHEL image builder and image mode readings. Each is structural; each remediates inside a renewal cycle.

The first trap is the deployment target the procurement register has not seen. The image builder service composed an image; the operations team deployed the image to a hypervisor cluster, a cloud account, or an edge device fleet; the procurement register, which had not been updated to anticipate the new target, continues to read against the prior estate. The reading is exposure for the period of operation on the new target. The remediation is the inventory pass against the deployment record and the attach at the next renewal. The pattern is most expensive when the deployment target is a cloud marketplace where the bring your own subscription posture has been assumed but the subscription line does not exist. The sibling reading on the cloud marketplace pattern sits in the RHEL on AWS marketplace economics note.2

The second trap is the image proliferation pattern. A buyer running image mode produces ten, twenty, fifty distinct image versions across the year as the security and feature cadence requires. Each image version carries a registration identifier; each deployed host commits to a specific image. The procurement register tracks the host count but does not always track the image version distribution. The reading is structurally undemanding for licensing but operationally important for the audit, because the host inventory of record is now also the image inventory of record. The remediation is the discipline of tying the host count to the image registration log at the renewal cycle. The pattern overlaps with the broader treatment in counting RHEL systems accurately.

The third trap is the boundary with the universal base image and the container image cataloguing pattern. A buyer producing custom RHEL images for use as container base layers reads the licensing line differently than a buyer producing images for full host boot. The universal base image, abbreviated UBI, is a redistributable subset of RHEL intended for container use and carries its own redistribution terms. The boundary between an image builder produced bootable image and a UBI derived container layer matters for the audit reading because the licensing line is different in each case. The cross reading on UBI redistribution sits in the sibling treatment of the RHEL universal base image licensing rules note.

The bootc delivery is the technical mechanism behind image mode and the source of the audit reading shift. A bootc image is a container image that boots as the host operating system rather than running inside a container engine. The image is registered, the host commits to a specific image version, and updates ship as new image versions with atomic apply. The discipline is structurally close to the ostree based delivery used on the edge variant and produces the same useful side effect on the audit reading: the image version on the host is a discrete artifact, and the procurement register can walk the image registration log directly.

The bootc delivery does not introduce new licensing entitlements. It introduces new discipline around the same entitlements. The host running a bootc image is a RHEL host carrying a RHEL subscription line. The image version is the artifact the audit can read against. The procurement register that has historically read against the host inventory now reads against the host inventory and the image version log in parallel. The discipline is most operationally significant when the image version cadence is high; a buyer composing and rolling out a new image every two weeks across a thousand host fleet should anticipate the audit reading earlier rather than later. The sibling reading on the cloud variant of the same delivery sits in the RHEL on Azure marketplace economics note.3

The cross cluster bridge sits in the broader treatment of container image counting on OpenShift in the Red Hat Quay registry licensing note. The OpenShift side reads container images for application workloads; the image mode side reads container images for host operating systems. The two patterns share delivery mechanics and procurement discipline; they do not share the licensing line.

The audit reading on image builder and image mode walks three artifacts. The image registration log, the host inventory of record, and the procurement register of RHEL subscription lines. The reading is internally consistent when every active host carries a registered image version and a paid subscription line at the appropriate tier.

Three inconsistencies recur. The first is the deployment target the procurement register has not seen. The image was composed and deployed to a hypervisor cluster, a cloud account, or an edge device fleet that the procurement register was not anticipating. The reading is exposure for the period of operation. The remediation is the inventory pass and the attach at the next renewal cycle. The procurement register should be a deployment target inventory before it is a subscription line inventory. The discipline overlaps with the broader treatment of under entitlement audit exposure.4

The second is the composed image that was distributed beyond the immediate operational team. A buyer's image builder service composed an image for an internal team; the team in turn distributed the image to a sister business unit that the original procurement line was not sized to cover. The reading is exposure on the sister unit; the remediation is the line expansion at renewal. The pattern overlaps with the broader treatment of shadow Red Hat usage in mergers and acquisitions; internal distribution behaves structurally similarly to inherited estate exposure for the audit reading.

The third is the image version that the procurement register treats as a separate line. A buyer who has misread the image version cadence will sometimes carry distinct procurement lines for distinct image versions. The lines are phantom; the host count is the unit, the image version is metadata. The remediation is the retirement of the phantom lines at renewal. The broader treatment of audit defense framework sits in audit defense.

The renewal posture on RHEL image builder and image mode has three habits. The habits are unglamorous; the same three habits, applied honestly, retire the recurring drift on most image driven estates within a single renewal cycle.

The first habit is the deployment target inventory. A short artifact, owned by the operations team and reviewed by procurement, that names every deployment target served by the image builder service and every host fleet running image mode. The artifact is reviewed quarterly and is the input to the renewal cycle. The discipline sits inside the broader treatment in the 90 day subscription assessment.

The second habit is the image cadence sync. The procurement register is read against the image version registration log at the same cadence as the image build cycle. The discipline is operationally undemanding when the registration log is queryable, which it is by default on a properly configured estate; it is significant exposure prevention over a multi year horizon. The sibling treatment of the cadence pattern on the cloud side sits in the RHEL on GCP marketplace economics note.

The third habit is the boundary review. At the renewal cycle, the image builder line is read alongside the UBI distribution pattern if both are in use and alongside the Satellite or Insights line where the image lifecycle is being managed inside the broader platform. The reading is whether the boundaries between the lines are clean and whether the procurement register carries any phantom lines. The broader treatment of renewal cycle discipline sits in renewal negotiation. For the parent service hub, see subscription assessment. For an engagement against the desk, see the contact form.

Preparing a response? The practice keeps a one-page Red Hat audit response checklist — what to acknowledge, what to preserve, and what not to volunteer in the first fourteen days after the letter arrives.