Who doesn’t have that one server in their infrastructure that everyone is afraid to restart? The one where something was tweaked in the configuration, nobody knows exactly what, but if we touch it, the system won’t come back up. We politely call this “configuration drift,” but it is simply a ticking time bomb. And RHEL 10 Image Mode steps in here to defuse that bomb. Instead of treating the symptoms, it changes the foundation.
Immutable OS (and how Image Mode fits in)
Before we move on, we need to clarify one concept. Immutable OS is an architectural concept where the file system is locked in “read-only” mode by default after installation.
In the traditional Mutable model, the system lives and evolves: today you install Apache, tomorrow you patch the glibc library, the day after you change permissions in /usr/bin. After a year, such a system is a “snowflake”—a unique artifact that cannot be reproduced.
In the Immutable model:
- The system is not “changed.” It is replaced.
- Updating does not mean overwriting files. It involves swapping in a completely new system image in its entirety and flipping a switch upon restart.
And this is where RHEL 10 Image Mode comes in. It’s not the name of a new operating system; it’s the name of Red Hat’s implementation of the Immutable OS mechanism. It is a specific technology that allows you to take this academic idea of immutability and deploy it in production using tools you already have in your company.
It’s not an experiment, it’s a standard you already know
Before you start turning up your noses thinking Red Hat is reinventing the wheel, look around. The concept of an Immutable OS is not a novelty. It is the standard in every modern device that is simply supposed to work and not break.
We encounter this every day, we just rarely transferred it to Enterprise servers:
- Android / iOS: Your phone has a “Read-Only” system partition. Apps cannot overwrite system files. This makes updates safe and cryptographically signed.
- Steam Deck: Valve’s portable console. The system partition is immutable. The user can go wild in their home directory, but they won’t break the OS by installing a game.
- Fedora Silverblue / Red Hat CoreOS (RHCOS): These were the proving grounds in the Linux world. Silverblue on the desktop, RHCOS under Kubernetes (OpenShift).
RHEL 10 simply takes what has been proven in these systems and says: “Okay, it’s time for serious servers to work this way too.”
What’s all the fuss about? (Image vs. Package)
In short: Your operating system is now a single, consistent artifact.
Forget about ISOs and Kickstart files you wrote a decade ago. In RHEL 10 Image Mode, you don’t “install” the system piece by piece (a few RPMs from here, a few configs from there). You deploy the system as a whole.
- You define the image (what should be in it: kernel, apache, your scripts).
- You build it once (build time).
- The exact same, bit-identical image lands on dev, test, and production.
The system stops being modeling clay that we shape on a living organism. It becomes a solid cast.
Does this remind you of something? If you thought of containers, you hit the bullseye. Yes, it’s exactly the same philosophy, just moved “one floor down,” to the level of the operating system itself. Image Mode borrows heavily from the idea of containerization: build once, run everywhere, and the whole thing is atomic and immutable. It is essentially the containerization of the entire OS.
How does it work under the hood? (bootc technology)
This is hard engineering based on the bootc project. Simply put: the system is packaged in the OCI format (yes, the same standard used in lightweight virtualization), but it includes the Linux kernel and bootloader inside. When such a system starts, mechanisms previously known from OSTree map this image to the physical disk. You don’t need to know OSTree commands. For you, it is simply a system that boots from an image, not from a local package repository.
Where will the system block you? (New Safety Rules)
This is the moment where you have to shift your mindset, or you will perish. You SSH into the server, type dnf install htop out of habit and… ERROR. Wall. The file system has new rules of the game.
/usris Read-Only. Cemented. Want to add a tool? You must add it to the image definition and rebuild it. There is no “quick install on the side.” This guarantees that no one makes a mess in system libraries without a trace./etcis the negotiation zone. Here you can change the configuration, but the system performs a so-called “3-way merge” during an update. It tries to intelligently reconcile what you changed manually with what came in the new image./varis your backyard. Here you keep data, logs, databases. The system does not overwrite this during updates.
Important note: if you put something important (e.g., an application) outside of/varon a live system, it will simply disappear at the next update. You have been warned.
Why is this a “game changer”?
Imagine a classic failure: You release a system update to 500 machines. It turns out the new kernel conflicts with your key application.
- In the old world (Package Mode): You stay up for three nights, write repair scripts, and pray that the YUM transaction rollback works (and we know that can be hit or miss).
- In the Image Mode world:
- The system sees that it didn’t boot correctly (thanks to the greenboot mechanism).
- It performs an automatic rollback to the previous image version.
- It restarts.
- You come to work in the morning, drink your coffee, and see in the logs: “Update failed, rolled back.” Everything is running on the old, proven version.
That is the difference. We treat servers as replaceable resources, not as unique works of art that need to be coddled.
Is it time to change habits?
I’ve been playing on a Steam Deck for a long time, regularly updating the Android in my pocket, but I never connected the dots that this is exactly how it works underneath. That this stability stems from the fact that the system is an image, not a collection of loose files. We use this every day at home, yet at work, we still treat our servers like fragile eggs.
This is likely the future. The model of “fiddling with packages” is slowly becoming a thing of the past. If a game console can update itself more safely than an Enterprise system, it’s a sign that it is time for a change.
Resources: https://developers.redhat.com/products/rhel-image-mode/getting-started