LUNAROPS · OPERATIONAL UPLINK 100% UPTIME 1,247d POSTS 893 JEFF.MOON@LUNAROPS.DEV UTC --:--:--

Immutable Linux Distros: NixOS, Silverblue, and bootc

16 min read Systems Administration
linuxnixossilverbluebootcostreeimmutabledevops
Contents

The traditional Linux package model has not changed in any deep way since the 1990s: you run apt, dnf, or pacman, the package manager writes new files into a shared root filesystem, runs post-install scripts, and your running system is now subtly different from every other one of its kind, including the one you tested against. This works most of the time and fails in ways that are infuriating precisely because they are intermittent — a half-applied transaction, a config-file conflict, a library upgrade that breaks something on next boot. Immutable distros throw out the entire premise. They treat the operating system as a versioned, atomically swapped artifact instead of an accumulating pile of files, give you a previous version sitting next to the current one for instant rollback, and quarantine your personal changes into well-defined seams. The three serious implementations in 2026 — NixOS, the OSTree-based Fedora Silverblue/Kinoite/Bluefin family, and the newer bootc model that swaps OSTree’s bespoke transport for OCI container registries — answer “what does immutable mean” in three different ways, with three different costs. This post walks them honestly: what changes at the filesystem, what you give up in ergonomics, and who should actually run one.

What “Immutable” Actually Means

The word immutable is doing too much work in the marketing. Strictly speaking, nothing in a running Linux system is read-only forever; the kernel, your home directory, and your runtime state all change constantly. What immutable distros actually mean by the word is narrower and more useful: the OS itself is treated as a unit, swapped atomically, never mutated in place, and always available in its previous version for rollback.

The shared mechanism behind every immutable distro is some form of two-root layout: at any given moment, your live system runs from one root tree (call it current), while a previous tree (rollback) sits next to it untouched. Updates do not modify current; they construct a brand-new next tree somewhere else on disk, and a reboot makes next the live root. If anything is broken on next boot, you reboot once more, the previous current becomes active again, and you are back to a known-good state. The OS files themselves typically live on a read-only mount, so even root cannot scribble on /usr accidentally, and any system-level configuration change must go through whatever explicit mechanism the distro provides.

This is conceptually identical to how container images are deployed in Kubernetes — pull a new image, swap a pointer, roll forward or back — applied to the host OS itself. The mental model is the same one that already powers your container build pipelines and your CI/CD: the artifact is fixed, identified by content, and rolled out as a whole. The only novel claim immutable distros make is that the operating system should be deployed that way too.

Three concrete properties fall out:

  • Atomicity. An update either completes fully (new tree exists, bootloader entry written) or has no effect. There is no half-installed state.
  • Rollback as a first-class operation. Every system has its previous self on disk, one bootloader entry away.
  • Reproducibility, at least in principle. Two machines running the same image are bit-for-bit identical on the OS side. The drift that haunts traditional fleets does not happen.

The trade-off — and there is always a trade-off — is that you cannot just sudo cp something into /usr/bin anymore. Every place you used to mutate the system is now gated behind a deliberate mechanism, and those mechanisms vary wildly between distros.

NixOS: The Whole System Is a Function

NixOS approaches immutability from the language end. Your entire system — every package, every kernel parameter, every systemd unit, every user, every cron job — is defined declaratively in Nix-language files, conventionally rooted at /etc/nixos/configuration.nix. The Nix evaluator turns that configuration into a system derivation, a content-addressed build product stored in the Nix store at /nix/store/<hash>-<name>. Building activates the derivation: kernel, init system, and userspace are all set up to point at the specific store paths that this system generation needs.

There is no /usr/bin in any meaningful sense. The binaries you run live deep inside the Nix store, exposed to your shell via per-user profile symlinks. Two completely independent versions of Python, or three different OpenSSL builds, can coexist on the same machine, each referenced only by the things that asked for them. Upgrades produce a new system generation, also stored in /nix/store, with a new bootloader entry; the old generation is still there for rollback until you garbage-collect it.

A working configuration.nix looks roughly like this:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

{ config, pkgs, ... }: {
  imports = [ ./hardware-configuration.nix ];

  boot.loader.systemd-boot.enable = true;
  networking.hostName = "lunarbox";
  time.timeZone = "America/Los_Angeles";

  services.openssh.enable = true;
  services.tailscale.enable = true;

  users.users.jeff = {
    isNormalUser = true;
    extraGroups = [ "wheel" "docker" ];
    openssh.authorizedKeys.keys = [
      "ssh-ed25519 AAAA... jeff@laptop"
    ];
  };

  environment.systemPackages = with pkgs; [
    git vim tmux htop ripgrep fd
  ];

  system.stateVersion = "25.05";
}

1
2
3
4
5
6
7

sudo nixos-rebuild switch                # build, activate, set as default
sudo nixos-rebuild test                  # build and activate but don't persist
sudo nixos-rebuild boot                  # build and queue for next boot only

nix-env --rollback                       # roll user profile back one generation
sudo nixos-rebuild --rollback switch     # roll the system back
nix-store --gc                           # collect old generations

The win is total. Two machines pointed at the same configuration are identical in a way no apt-based system ever achieves. Rollback is one command. Branching off an experimental config means making a new file and rebuilding — if it breaks, you reboot to the previous generation, untouched. Reproducibility is so deep that the same Nix expression evaluated on two machines produces byte-identical store paths. NixOS is what configuration management looks like when you let the language define the system end to end, rather than driving an external system with Ansible playbooks that try to converge a mutable root.

The cost is real. Nix-the-language has a learning curve that is steep and idiosyncratic — it is a lazy, purely functional language whose error messages are notorious. The package set (nixpkgs) is enormous (well over 100,000 packages), but anything not in nixpkgs requires you to write a Nix derivation for it, which is itself a small project. Many proprietary binaries (game launchers, vendor drivers, electron apps shipped as random tarballs) assume /lib/ld-linux.so.2 exists where it does not on NixOS, and require explicit patchelf or nix-shell wrappers to work. NixOS is the most powerful answer to immutability on offer and the one with the harshest entry exam.

Fedora Silverblue and the OSTree Family

Silverblue (and its KDE sibling Kinoite, plus the developer-flavored Bluefin) takes the other tack: keep a familiar Fedora userspace, but distribute and update the root filesystem as a single signed image tree managed by OSTree. Think of OSTree as Git for filesystems — it stores root trees as content-addressed objects, lets you check out one as a deployment, and atomically switch between checkouts. Each “commit” is a complete OS image; rpm-ostree is the tool that builds those commits from RPM packages and manages local deployments.

A Silverblue system has two deployments visible at any time:

   /ostree/deploy/fedora/deploy/<commit-hash-A>/   <- current
   /ostree/deploy/fedora/deploy/<commit-hash-B>/   <- previous (rollback)

   /usr  is a bind-mount from the current deployment, MOUNTED READ-ONLY
   /etc  is writable (per-deployment, with three-way merge across updates)
   /var  is writable and shared across deployments

Daily life looks like Fedora until you reach for dnf. There is no dnf install; the supported pattern is:

1
2
3
4
5
6
7
8

rpm-ostree status                  # show current and pending deployments
rpm-ostree upgrade                 # pull next image; queue for reboot
rpm-ostree rollback                # swap order of current and previous
rpm-ostree install nvtop           # layer a package onto next deployment
rpm-ostree override replace pkg    # override a base-image package
flatpak install flatseal           # GUI apps via Flatpak, not RPM
toolbox enter                      # mutable Fedora container for dev work
distrobox enter --image ubuntu     # same idea, distro-agnostic

The model splits the system into three tidy zones: the immutable base (read-only, atomically updated, OSTree-managed), layered packages (RPMs added on top, rebuilt into the next deployment), and user-space sandboxes (Flatpak for GUI apps, Toolbx or Distrobox for CLI dev environments). The split is the entire ergonomic story: you do not pollute the base with random tools; you put them in containers where they belong, and your base stays small, signed, and identical across machines.

Layering is the seam where Silverblue’s purity meets reality. Every layered RPM adds time to your update — rpm-ostree rebuilds the layered tree on each upgrade — and stacking dozens of layers undermines the speed and atomicity that made the base attractive. The discipline the model wants is: use Flatpak for desktop apps, Toolbx for development tools, and layer only the small handful of things (drivers, codecs, shells) that genuinely need to live in the base. When you obey that discipline Silverblue is delightful; when you fight it by layering everything you used to dnf install, the experience degrades.

Compared to NixOS, Silverblue is less radical and far more familiar. If you already know Fedora, you are eighty percent there; the new vocabulary is rpm-ostree, flatpak, and toolbox. The trade is that you do not get NixOS’s whole-system declarative reproducibility — your layered packages and /etc edits are still mutable state that drifts per-machine — but you do not pay NixOS’s learning tax either. Most users coming from a normal distro should start here.

bootc: OCI All the Way Down

The newest entry rethinks the delivery mechanism. bootc keeps OSTree’s atomic-deploy model on the host but distributes the OS image as an OCI container image pulled from a standard container registry, rather than as OSTree objects fetched over OSTree’s own transport. The image is built with Containerfile/Dockerfile syntax, pushed to ghcr.io or any other registry you like, and the host pulls and applies it the same way Kubernetes nodes pull pod images — except this image is the root filesystem of the host, not a container running on it.

The implications are large:

  • The OS build pipeline becomes a container build pipeline. Anything you can do with docker build, you can do to your host OS. You can layer Dockerfiles on top of a vendor base image, build in GitHub Actions, sign with cosign, scan with Trivy, and ship to fleets through the same registries you already use.
  • The transport is industry-standard. No bespoke OSTree HTTP; OCI registries, mirroring, pull-through caches, and air-gap workflows all just work.
  • Composition is sane. A “derived image” is just FROM quay.io/fedora/fedora-bootc:42 plus whatever RPMs, configs, and tweaks you want, baked once and applied everywhere.

A skeleton derived image:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

FROM quay.io/fedora/fedora-bootc:42

RUN dnf -y install tailscale tmux ripgrep fd-find && \
    dnf clean all

COPY etc/ /etc/

# enable a unit shipped in this image
RUN systemctl enable tailscaled.service

LABEL org.opencontainers.image.source="https://github.com/jeff/lunar-bootc"

Build and deploy on the host:

1
2
3
4
5
6
7

podman build -t ghcr.io/jeff/lunar-bootc:latest .
podman push  ghcr.io/jeff/lunar-bootc:latest

sudo bootc switch ghcr.io/jeff/lunar-bootc:latest    # change tracked image
sudo bootc upgrade                                    # pull latest, stage for reboot
sudo bootc rollback                                   # back to previous image
sudo bootc status                                     # current image and pending

The bootc model is what Red Hat is pushing as the long-term direction; Fedora’s atomic desktops are progressively transitioning from rpm-ostree to bootc under the hood, and RHEL’s image-mode editions ship with bootc as the supported flow. For managing fleets of machines, this is an enormous simplification: your host OS lifecycle becomes a CI/CD problem with familiar tools, and rollback is bootc rollback. The model is closer to “Kubernetes for hosts” than to any traditional sysadmin workflow.

The cost is the same one OSTree had: layering local packages still rebuilds the next deployment, your /etc and /var are still mutable seams that can drift, and you give up the per-package surgical precision of dnf install x on a running system. The win — composable images, signing, registry-native distribution — is what makes bootc the right answer for organizations and the most likely default for enterprise immutable Linux in the next few years.

How They Compare

Property NixOS Silverblue (rpm-ostree) bootc
Declared in Nix language Image tree + layered RPMs OCI Containerfile
Atomicity boundary System generation OSTree commit/deployment OCI image / bootc deployment
Rollback Previous generation in bootloader Previous deployment in bootloader Previous image staged on disk
Reproducibility Strong (content-addressed Nix store) Image-level, not package-level Image-level via OCI digest
Familiarity to mainstream users Low (new language and model) High (Fedora userspace) Medium (containers, but new host model)
Local package layering Native via overlay/profile Yes via rpm-ostree install Yes via derived image rebuild
Per-app sandboxing nix-shell, home-manager Flatpak, Toolbx, Distrobox Flatpak, Toolbx, Distrobox
Transport binary cache (HTTP) OSTree (HTTP) OCI registries
Best fit Power users, lab machines, reproducible dev Desktop users wanting reliability Fleets, enterprise hosts, image pipelines
Learning cost High Low-medium Medium

The differences across columns are real, but it is worth keeping the shared model in view: all three deliver atomic updates, all three give you rollback, all three quarantine the base from your changes. The right question is not which is best but which trade-off matches your situation.

Where Immutability Helps, and Where It Fights You

Immutability earns its keep in three clear cases. Reliability on machines you cannot babysit — kiosks, signage, fleet endpoints, ephemeral lab hosts — where atomic update plus instant rollback is the difference between a working device and a remote support ticket. Reproducible developer environments, particularly with NixOS or with bootc-derived dev images, where “works on my machine” stops being a phrase because every machine boots the same image. Security postures that benefit from a read-only base — a compromised user account cannot rewrite /usr/bin/sshd, and base-image signing means an attacker who modifies the image cannot make a host boot it.

Immutability fights you in three corresponding cases. Proprietary software with bad packaging assumptions that wants to drop binaries into /usr/local, link against a specific glibc, or install a kernel module out of tree — anything that assumes a mutable root will need wrappers, containers, or grudging acceptance. Fast-moving, frequently-tweaked desktops where part of the joy is leaning into dnf install whenever you find a new tool; the immutable model wants you to put those tools in a Toolbx container or a Flatpak, and if that is friction you do not want to absorb, the model is not for you. The deepest customization edge cases — patching the kernel for a niche peripheral, swapping init systems, etc. — are possible on NixOS but cumbersome on OSTree/bootc, where you would need to rebuild the base image and rejoin the upgrade train.

The closest thing to a unifying lesson from the gamer-focused Bazzite/CachyOS/SteamOS handhelds is that consumer-facing immutable Linux is now real — appliance-grade reliability with desktop ergonomics. The same OSTree machinery that makes Silverblue resilient is what makes Steam Deck OS resilient, and the convergence is informative: when you do not need to mutate the system to use it, you should not.

Who Should Actually Run One

Honest guidance, since the marketing usually says “everyone.”

Run NixOS if you want declarative reproducibility above everything else, you have time to learn the Nix language, you maintain multiple machines whose configs must match, or you build reproducible dev environments and the work-day saved on consistency is worth the days lost on learning curve.

Run Silverblue/Kinoite/Bluefin if you want a reliable Fedora desktop, you can live with Flatpak and Toolbx as the way to run desktop apps and dev tools, and you want the atomic/rollback story without the language tax of NixOS. This is the lowest-friction on-ramp for a normal user.

Run a bootc-based system if you are managing fleets — homelab nodes, edge hosts, enterprise servers — and you already think in OCI images. The pipeline you already have for containers becomes your OS pipeline. For organizations, this is the most strategically interesting option in 2026; for solo desktop users, it is still rougher than Silverblue.

Stay on a traditional distro if you are happy with how things work, your reliability problems are not in the OS layer, or the workflows you depend on assume mutable roots. Immutable Linux is a real upgrade for the cases it fits; it is not free, and forcing it on a setup that does not benefit just adds friction without payback. The full universe of options, including the traditional ones, is the right frame: see choosing a Linux distribution for the broader landscape.

Verdict

Immutable Linux is not a new feature glued onto a normal distro — it is a different philosophy about what the operating system is. NixOS treats the system as the output of a pure function over a configuration; Silverblue and the OSTree family treat it as a signed filesystem tree atomically swapped at boot; bootc keeps that model but distributes the image through OCI registries, turning host OS lifecycle into the same problem your container pipelines already solve. All three deliver atomic updates, first-class rollback, and a hard separation between the immutable base and the seams where you are allowed to change things, and all three pay for it by removing the freedom to mutate the root that traditional distros let you take for granted. The right one for you is the one whose trade-offs you actually want: NixOS if you will pay learning cost for the strongest reproducibility guarantee on Linux, Silverblue if you want a familiar Fedora desktop that survives bad updates, bootc if you are managing more than one machine and image-mode operations would simplify your fleet. Stay on a traditional distro if your problems are not in the OS layer, because immutability is not a tax-free upgrade. But the bigger story is that immutable distros have stopped being a curiosity and become a credible default for new deployments, and the question over the next few years is not whether the model wins but which of these three architectures becomes the standard way to ship a Linux host.

Sources

Comments