Most Linux systems let you modify anything. That flexibility is a large part of the appeal, and it is also why a botched update can leave a machine unbootable and why “it worked yesterday” is sometimes impossible to investigate. Immutable distributions take a different position: the operating system is a fixed image you replace wholesale, and everything you do lives on top of it.

What immutable actually means

The root filesystem is mounted read-only. You cannot write to /usr because the kernel will not let you.

Updates do not modify packages in place. Instead the system composes a complete new image, writes it alongside the current one, and switches the boot target. Either you boot the new image or you boot the old one, and there is no state in between.

That atomicity is the whole point. A traditional package manager interrupted midway through a large upgrade can leave half-installed packages and a system that will not start. An atomic update either happened or did not.

The previous image stays on disk. If the new one misbehaves, you reboot and pick the old entry.

Where your stuff lives

/home is fully writable and behaves normally. /etc is writable and your changes are tracked and merged across updates. /var is writable.

What you cannot do is sudo cp something /usr/bin/, and that is deliberate.

Installing software

This is the part that trips people up, because tutorials assume a writable system.

Flatpaks handle graphical applications. They bundle their dependencies, install to /var or your home directory, and update independently of the base system.

flatpak install flathub org.gimp.GIMP
flatpak update

Containers handle command-line tools and development work. Distrobox or Toolbox create a container that feels like a normal distribution, with your home directory mounted and full package manager access, while the host stays untouched.

distrobox create --name dev --image fedora:latest
distrobox enter dev
sudo dnf install gcc make ripgrep   # inside the container, normal Fedora

Commands from the container can be exported so they appear as normal commands on the host. In practice you end up with a Fedora container for one thing and an Arch container for another, both on the same machine, which is a genuinely nice arrangement.

Package layering adds a package to the base image itself. It works, it requires a reboot, and it slows future updates because your image is no longer the stock one.

rpm-ostree install akmod-nvidia
systemctl reboot

Reserve it for things that must be part of the system: drivers, kernel modules, shell replacements, and virtualisation components. If it can be a Flatpak or live in a container, do that instead.

The main implementations

Fedora Silverblue and Kinoite are the originals in this space, using rpm-ostree to compose images from RPMs. Silverblue ships GNOME, Kinoite ships KDE.

Universal Blue builds on Fedora’s work but ships images as OCI containers, which means you can build your own variant with a Containerfile. Bazzite is its gaming image, with drivers, Steam, and handheld support preconfigured. Bluefin and Aurora target general desktop use.

That OCI approach has reach beyond the desktop: Unraid 8 is moving off Slackware onto uCore, Universal Blue’s server image, after two decades.

Vanilla OS uses a Debian base and adds Apx, which manages containerised subsystems from several distributions at once. Version 3 added reproducible images and official ARM64 builds.

openSUSE Aeon and MicroOS achieve the same goals with Btrfs snapshots and transactional updates rather than image composition.

NixOS deserves a mention because it reaches similar guarantees by an entirely different route. The whole system is described declaratively in configuration, every build is reproducible, and every previous generation is bootable. It is stricter and has a much steeper learning curve.

What you gain

Updates you can undo. The most common real-world benefit. A driver regression or a broken desktop is a reboot away from resolved.

Machines that stay identical. Everyone on the same image is running exactly the same base, so “works on my machine” has fewer places to hide.

No configuration drift. Traditional systems accumulate years of half-remembered changes. An immutable base cannot, because those changes have nowhere to go.

A smaller attack surface for persistence. Malware that would normally modify a system binary finds it read-only.

What it costs

Tutorials do not apply directly. Any guide that says apt install or dnf install needs translating. This is the friction people actually hit.

Layered packages slow you down. Each one makes your image non-standard and lengthens updates.

Some software fits badly. Anything expecting to install a kernel module, integrate deeply with the system, or write to /opt needs thought.

Reboots are part of the workflow. Layering a package or switching images requires one, which on a laptop is fine and on a server is a scheduling matter.

Who should use one

Good fit: a desktop you want to stay working, a gaming machine where the OS is a means to an end, a fleet of identical workstations, anyone who has broken a system with an update and would prefer not to repeat it.

Poor fit: anyone learning how Linux works, since the useful part of that is being able to break and repair things. Also anyone whose workflow depends on software that assumes a writable root.

Worth trying either way: the reversibility is genuinely reassuring once you have used it. Knowing an update cannot leave the machine unbootable changes how willing you are to take them promptly, which is itself a security benefit.

Frequently Asked Questions

What makes a distribution immutable?

The root filesystem is mounted read-only during normal operation, so system files cannot be modified in place. Updates replace the whole system image atomically rather than changing packages one at a time, and the previous image stays on disk so you can boot back into it.

How do I install software if the system is read-only?

Three ways, in order of preference. Flatpaks for graphical applications, containers through Distrobox or Toolbox for command-line tools and development environments, and package layering onto the base image as a last resort for things that genuinely must be part of the system.

What happens if an update breaks something?

You reboot and choose the previous image from the boot menu. Because the update was atomic, the old system is intact rather than half replaced. This is the main practical advantage over a traditional distribution, where a failed update can leave you with a system that does not boot at all.

Is an immutable distro more secure?

Somewhat. Malware cannot persist by modifying system binaries, and the reduced writable surface limits some attacks. It is not a substitute for updates, good passwords, or a firewall, and your home directory is still writable and still where most of your data lives.

Can I use an immutable distro as a normal desktop?

Yes, and most users would not notice the difference day to day. The friction appears when following a tutorial that says to run a package manager command, since the equivalent step is different. Anything installing to your home directory works unchanged.

Which immutable distribution should I try?

Fedora Silverblue or Kinoite for a general desktop, Bazzite for gaming and handhelds, Vanilla OS if you want a Debian base with multi-distribution containers, and openSUSE Aeon or MicroOS in the SUSE ecosystem. NixOS achieves similar guarantees through an entirely different mechanism.