What image mode means for users of RHEL for edge

Image mode for Red Hat Enterprise Linux (RHEL) and RHEL for edge provide very similar benefits and operational workflows, and also address similar use cases. Image mode is becoming the preferred deployment method in RHEL 10, so in this article we'll go over what this means for users of RHEL for edge.

If you’re following news about the upcoming RHEL 10 release (currently in beta) or about Red Hat Enterprise Linux AI (RHEL AI), you’ve heard about image mode for RHEL. And, if you’re a user of RHEL for edge, which is also a part of Red Hat Device Edge, you'll have noticed that both start from the concept of deploying and updating a Linux operating system—pre-configured and with applications already deployed—as a single system image.

In fact, the processes and workflows for provisioning Linux systems using RHEL for edge and image mode for RHEL look strikingly similar. As a RHEL for edge user, you might be wondering whether you should plan to switch to image mode sooner or later, and how much to invest in your current projects that are based on RHEL for edge.

Let’s compare these two technology stacks and see how each will be supported in RHEL 10 and other Red Hat products in the future.

What are image mode for RHEL and RHEL for edge?

Image mode for RHEL is currently in tech preview and will be the new and recommended method for deploying RHEL in all footprints: bare metal, cloud, virtualized and edge.

Image mode lets you build bootable operating system images as Open Container Initiative (OCI) container images, letting you use familiar tooling from the Linux containers world, such as Podman, Red Hat Quay and Red Hat OpenShift Pipelines. It also enables cloud-native DevOps and CI/CD processes to extend from applications all the way down to operating systems on bare metal.

RHEL for edge, which debuted in RHEL 8, is the recommended method for deploying the world’s leading enterprise Linux platform on edge devices and edge gateways. It uses the image builder tool to produce immutable operating system images based on the RPM-OSTree technology, and allows you to efficiently distribute over-the-air updates to edge systems using OSTree repositories.

While RHEL for edge has been optimized for edge deployments, its technology stack is also well-suited for data center and cloud deployments. In fact, those kinds of deployments could also benefit from a “shift left” approach, where you perform most of your server configurations at image build time instead of as part of Day 2 operations.

So, while RHEL for edge can work for data center and cloud scenarios, image mode for RHEL also works for edge scenarios. These do not represent radically different approaches, but are simply different tool sets used to implement very similar approaches for deploying and managing operating system and application stacks using DevOps principles.

Comparing image mode for RHEL with RHEL for edge

You can describe the operational workflow for deploying a Linux system using image mode for RHEL in the following steps:

1. Create a containerfile which takes a base bootc RHEL container image and adds your applications and configurations.
2. Use standard container tools, such as Podman, to build a derived bootc container image, which you publish on a standard OCI container image registry.
3. Use the standard RHEL installer (Anaconda) to deploy that derived bootc container image to a physical or virtual system.
4. Alternatively, use the bootc image builder tool to convert your derived bootc container image into a bootable disk image that can be directly used to provision physical systems, from USB media or virtual machines, using the native system image formats of your cloud provider or hypervisor.

Updating a system using image mode for RHEL is basically repeating steps 1 and 2, then using the bootc update tools, already embedded on your RHEL systems, much like you would use YUM or DNF to update a traditional package mode RHEL system.

You can describe the operational workflow for deploying a Linux system using RHEL for edge in pretty much the same steps:

1. Create a blueprint which takes a base RHEL release and adds your applications and configurations.
2. Use the image builder tool to build an OSTree system image, as an OSTree commit, which you publish on a standard web server.
3. Use the standard RHEL installer (Anaconda) to deploy that OSTree commit image to a physical or virtual system.
4. Alternatively, use the image builder tool to convert your OSTree commit into a bootable disk image that can be directly used to provision physical systems, from USB media or virtual machines, using the native system image formats of your cloud provider or hypervisor.

Updating a system using RHEL for edge is basically repeating steps 1 and 2, then using the RPM-OSTree update tools, already embedded on your RHEL systems, much like you would use YUM or DNF to update a traditional package-based RHEL system.

The following table maps the concepts and tasks of RHEL for edge to those in image mode for RHEL:

Both RHEL for edge, with its RPM-OSTree technology, and image mode for RHEL provision Linux systems from immutable system images and apply transactional updates to these systems. So far, image mode for RHEL just looks like a different way of achieving the same outcomes as using RHEL for edge.

As you can see, RHEL for edge and image mode are just two technology stacks and tool sets designed to “shift left” Linux operating system customization and application deployment from Day 2 operations to image build time.

They both support the same kinds of applications designed for RHEL, and use the same Linux kernel, device drivers, system libraries and programming runtimes. You can perform Day 2 configurations, if you need, and ongoing system management (such as system patching) using standard tools which support RHEL, such as Red Hat Ansible Automation Platform.

Why switch from RHEL for edge to image mode for RHEL

While OSTree-based images offer notable advantages such as hands-off upgrade safety, automated rollbacks and significant network bandwidth savings, they require familiarity with OSTree-specific tooling. Image mode leverages Red Hat’s expertise in image-based, transactionally updated operating systems—like RHEL CoreOS and RHEL for edge—by extending these concepts to container images, one of today’s most common software building blocks. This approach transitions from OSTree’s specialized tools to a broader ecosystem of industry-standard tooling.

By incorporating the strengths of OSTree systems while lowering the barrier to entry, image mode makes it easier for users to take advantage of these benefits. In essence, RHEL for edge concepts remain core to image mode by enabling more flexibility and broader adoption of these robust, transactionally updated systems.

With image mode for RHEL, we hope to bring more IT professionals and Linux deployments—both on edge and on datacenter and clouds—to image-based workflows and transactional updates by enabling the use of the now widely-adopted Linux container tooling, based on OCI standards. Instead of learning new tools (image builder and RPM-OSTree) to build operating system images, you build them using Podman and similar tools. Instead of learning how to provision and maintain an OSTree repository on a web server, you provision and maintain Red Hat Quay or any other standard OCI container registry.

Image mode for RHEL and OSTree

Notice that the image mode technology stack requires much more than just OCI containers. We prefer referring to “bootable containers” as bootc container images, or just bootc containers, because OCI container images cannot be booted anywhere. No current hypervisor, cloud provider or computer firmware knows how to boot from a container image.

A bootc container image is just a regular container image which contains additional files that would normally be considered unnecessary, but just adding a kernel and other files to an application container doesn't make it bootable.

Bootc container images can be run as a regular container image, as long as their applications don't need any of the systemd, dbus and kernel-related features that could be configured into their images. This enables quick testing of applications embedded in bootc images before being deployed to a system.

Another issue with using OCI container images for bootable operating systems is that they are not designed to preserve security attributes such as SELinux labels. You don’t want to run operating systems without the protection you get from SELinux.

Image mode for RHEL creates bootc containers by including bootc in base container images. Bootc performs tasks such as configuring a boot loader and setting SELinux contexts from special metadata that is also included. It does so using the RPM-OSTree technology from RHEL for edge.

So, while the key technologies of RHEL for edge are still there and make image mode for RHEL work, they are now a mostly invisible implementation detail. Developers building bootc container images and system administrators managing image mode for RHEL do not need to interact directly with RPM-OSTree and OSTree. In essence, image mode replaces the user-visible tooling of RHEL for edge.

The future of RHEL for edge

RPM-OSTree is a mature technology. It has existed since RHEL 7 (as part of RHEL Atomic Host) and it is the cornerstone of RHEL CoreOS, which has already been in production for years at many large OpenShift deployments.

Similar to OpenShift administrators—who don’t have to interact with RPM-OSTree to perform their day-to-day tasks, but who still benefit from its capabilities—RHEL administrators who use image mode won’t have to deal with RPM-OSTree to get its benefits.

Future releases of Red Hat products will switch over to using image mode, each on their own schedule. The reasons for this are many, and include providing a consistent user experience and reducing cognitive load on IT professionals. Red Hat Enterprise Linux AI (RHEL AI) is the first Red Hat product built on image mode, and the next major iteration of RHEL CoreOS in Red Hat OpenShift will make the switch.

On the other hand, RHEL for edge is much larger than just image builder and RPM-OSTree. It also includes additional features such as greenboot for automatic rollback of operating system updates, and FIDO Device Onboard (FDO) infrastructure for secure onboarding edge devices. These features remain mostly unchanged in image mode for RHEL.

Just as RHEL for edge is not a distinct product, image mode for RHEL is also not a product, but a new feature of RHEL. Other features that originated in the context of RHEL for edge remain available to image mode for RHEL. One of the reasons image mode for RHEL is still considered to be in tech preview despite already being used in RHEL AI, is the extensive quality assurance (QA) required to verify that all technologies from RHEL for edge and all other feature sets from RHEL remain working and reliable when deployed and managed using image mode for RHEL.

To smooth the transition from the current RHEL for edge to image mode for RHEL, Red Hat QA is also verifying that the key behaviors of RPM-OSTree deployments are preserved by image mode for RHEL. Transitioning from RHEL for edge to image mode for RHEL should be a matter of creating container files which implement the same customizations as your existing image builder blueprints.

RHEL for edge in RHEL 10

With RHEL 10 you will be able to use the current RHEL for edge tooling, that is, image builder and RPM-OSTree, to generate both OSTree-based images and package-based images for RHEL 9. So if you are using RHEL for edge today, you can switch to RHEL 10 and preserve your workflows to support your existing RHEL for edge images based on RHEL 9.

Image builder in RHEL 10 image builder will also be able to build package mode images for RHEL 10 and RHEL 9. But there will be no way to build RHEL for edge images for RHEL 10. In fact, image builder and RPM-OSTree in RHEL 10 will not support building RHEL 10 edge images. If you want to build images for edge devices with RHEL 10 kernels and packages, then you must use image mode for RHEL, that is bootc and bootc image builder.

If you want to get started with image mode for RHEL you don’t need to switch to RHEL 10. Image mode for RHEL has been in tech preview since RHEL 9.4 and will become fully supported in a future minor release of RHEL 9. You will be able to use image mode tools on RHEL 9.4+ and RHEL 10 for production deployments in a short time.

Wrap up

Edge deployments based on image mode for RHEL will follow workflows that are very similar to those for the current RHEL for edge deployments. By switching from RPM-OSTree tooling to OCI container tooling, Red Hat is simplifying the learning curve and facilitating its integration into DevOps workflows. This should help reduce the impedance mismatch between the cloud-native development world and the edge operations world, and enable a larger set of organizations to benefit from transactional operating system deployments and updates.

Thanks to Antonio Murdaca, Colin Walters, Mark Russell, Matt Micene and Micah Abbott for their reviews on this article.