Red Hat Image Builder and OpenFactory: Different Boundaries

Updated August 12, 2026. RHEL Image Builder has native output and OpenSCAP capabilities that should not be minimized. OpenFactory covers a different hosted build-and-test path. Pick from the required artifact and operating model, not from a generic feature score.

Start by separating the two Image Builder scopes

Red Hat's supported product and the upstream osbuild project are related, but they are not identical promises. Current RHEL 10 documentation describes blueprint-driven RHEL images through the command line or RHEL web console. It lists output formats for AWS, Google Cloud, Azure, OpenStack/QEMU, Oracle Cloud, VMware, Vagrant, WSL, and an Anaconda installer ISO, with architecture-specific support.

The current upstream image-description matrix also lists AlmaLinux and Rocky Linux alongside RHEL, CentOS Stream, and Fedora. It explicitly warns that available targets depend on whether the build uses the CLI, osbuild-composer, a hosted service, and a compatible local host. Run image-builder list on the actual builder to establish the supported combinations for a decision record.

Image Builder's native strengths

• Explicit blueprints and composes. Package and system customizations are versionable inputs associated with build metadata and logs.
• Platform-specific formats. Cloud, VM, installer, and other output types carry setup appropriate to their target instead of treating every platform as a generic ISO.
• Supported RHEL integration. A registered RHEL host can use the CLI and cockpit-image-builder web console alongside Red Hat repositories and support processes.
• OpenSCAP integration. Red Hat documents generation and pre-first-boot application of current security-profile remediation. Preserve the profile ID, data-stream version, exceptions, and results.

Red Hat's current OpenSCAP guide is particularly important when comparing hardening claims. Selecting and applying a maintained profile is a concrete capability. It still does not certify the deployed system or replace organization-specific risk review.

Where OpenFactory fits

OpenFactory is a candidate when the desired target is a supported Ubuntu, Debian, or Fedora bootable artifact, a user wants to start from a prompt or guided configurator, and the acceptance loop benefits from attached build logs, an artifact checksum, and selected machine-level checks. The generated recipe must be reviewed before building; validation cannot prove that natural-language intent was interpreted correctly.

OpenFactory's current public boundary is not a general cloud-image publisher, RHEL support channel, full fleet rollout service, OpenSCAP replacement, or compliance authority. Customer-controlled deployment, rollback, regulated workflows, and integrations belong in a scoped pilot with written ownership and acceptance criteria.

Side-by-side decision table

Keep Image Builder when its native path is the requirement

Keep the Red Hat path for supported RHEL images, current OpenSCAP profiles, native cloud or virtualization formats, existing subscription operations, and platform-specific image semantics. Keep upstream Image Builder when its current distro/type matrix and local-build model match the need. Adding a second builder only makes sense when a target or review workflow sits outside those boundaries.

Pilot an Ubuntu equivalent without hiding uncertainty

The following prompt is deliberately explicit about secrets, unsupported controls, validation, and post-deployment responsibility. It is a starting point to review, not a promise that every requested control maps cleanly from RHEL to Ubuntu.

Build an Ubuntu 24.04 server image for an edge-gateway pilot.

Include Docker, Prometheus node exporter, and the Tailscale client from Tailscale's official signed Ubuntu Noble repository. Enable tailscaled, but do not run tailscale up and do not place an auth key in the image.

Create a small Python standard-library compatibility service at /opt/internal-monitoring-agent/agent.py with /healthz and /metrics on port 9191. Add and enable internal-monitoring-agent.service. Do not clone a private repository during the build; document the post-deployment handoff instead.

Request the supported CIS Level 1 controls, enable unattended-upgrades, and configure SSH for key-only authentication. Do not insert a fake public key. Add a runbook that blocks deployment until the real operations key is provisioned.

Add explicit validation checks for the Docker service, tailscale binary and enabled unit, node exporter on port 9100, monitoring-agent /healthz on port 9191, SSH password authentication disabled, and a successful reboot. Produce a downloadable bootable artifact plus build and validation evidence. If any requested package, control, or test is unsupported, report that before building instead of silently omitting it.

1. Review every resolved package, repository, service, file, and hardening action before building.
2. Require the builder to surface unsupported intent instead of silently dropping it.
3. After completion, verify the artifact checksum and compare the package and service inventory with the recipe.
4. Boot and reboot the artifact, execute the named checks, and preserve their logs.
5. Provision real keys and credentials only through the target environment's secret process, then repeat the deployment tests.

A mixed estate can legitimately use RHEL Image Builder for its native RHEL outputs and OpenFactory for a supported Ubuntu, Debian, or Fedora hosted build loop. The defensible integration point is an immutable artifact identifier plus explicit evidence, not a claim that the two systems produce equivalent images.