# Immutable Linux: What Silverblue, Flatcar and Talos Are, and Why the System Is Off Limits - **Published on:** 2026-09-10 - **Category:** News - **Original page:** https://linuxgratis.com/en/articles/immutable-linux-silverblue-flatcar-talos Eight systems where the root directory is read-only and updates arrive as whole images with rollback. What they solve, what they take away, and when each one is worth it. --- For thirty years, running Linux has meant editing files under `/etc` and updating packages one at a time. Immutable systems break that habit: the base system ships as a read-only image, gets replaced whole, and if the new one misbehaves you boot the previous one. We have just added eight of them to the catalogue, and they are worth telling apart, because the same label covers two fairly different worlds. ## What "immutable" means in practice The disk is not read-only. Your data in `/home` changes, and so does your configuration. What does not change is the base system: `/usr` is mounted read-only and you cannot casually install a package that modifies it. Three consequences follow: 1. **Every machine is identical.** If a thousand servers boot the same image, there are not a thousand configuration variants piled up by urgent patches. 2. **Updates are atomic.** There is no halfway state between two versions: either it applied whole or it did not apply. 3. **You can undo them.** If the new image breaks something, you reboot into the previous one, still sitting on disk. What you lose is the habit of fixing things live. For plenty of people that habit is exactly the problem they want to leave behind. ## The desktop ones [Fedora Silverblue](/en/fedora-silverblue) is the GNOME variant and [Fedora Kinoite](/en/fedora-kinoite) the same idea with KDE Plasma. They share cycle and dates with [Fedora](/en/fedora) because they are the same release assembled differently. Applications come as Flatpaks, development happens in Toolbx containers and, if you really need an RPM inside the base system, there is an escape hatch that layers packages on top of the image. It works, but the more you use it, the less advantage is left. [Vanilla OS](/en/vanilla-os) reaches the same place from another direction: untouched GNOME, two partitions that alternate on update, and the option to install packages from several distributions inside containers. Since version 2 it swapped Ubuntu for its own Debian base. Then there is [Bazzite](/en/bazzite), which is Fedora Atomic dressed as a console: Steam session mode, current drivers and image-based updates. On a [Steam Deck](/en/steamos) or a ROG Ally it makes complete sense, because a console is exactly the device where a half-applied update must never leave you unable to boot. ## The server and container ones The premise changes here: no desktop, fleets instead. [Fedora CoreOS](/en/fedora-coreos) is Fedora reduced to running containers. It has no conventional package manager; it is configured on first boot with Ignition and updates itself along a stream. It is the direct successor to the original Container Linux. [Flatcar](/en/flatcar) picked up that baton when Red Hat discontinued Container Linux, and today it lives under the Cloud Native Computing Foundation. It keeps two stable channels at once, a regular one and an LTS, which anyone running a large cluster on a slow upgrade cycle will appreciate. [Talos Linux](/en/talos) is the most radical of the bunch: no shell, no SSH, no package manager. The machine is administered through a gRPC API, full stop. You cannot log in to see what is happening, which is the whole point: if nobody can touch a node by hand, no node ends up different from the rest. It runs Kubernetes and little else. [Bottlerocket](/en/bottlerocket) is the AWS entry, largely written in Rust. Read-only root verified with dm-verity, no shell except in a separate admin container, and updates that roll themselves back when boot fails. [Azure Linux](/en/azure-linux) —formerly CBL-Mariner— is the distribution Microsoft builds for itself and runs on AKS nodes. RPM packages, minimal surface and end-to-end control of the supply chain. ## When it pays off It pays off when you have many identical machines, or one you cannot afford to break. A Kubernetes cluster, a home server doing NAS and downloads, a handheld console. The real benefit is not security, although that comes along too: it is that the system returns to a known state on every boot. It does not pay off if your work involves tinkering with the base system, compiling kernel modules or installing software that expects to write wherever it pleases. A plain [Debian](/en/debian) or [Arch](/en/arch) will give you far less trouble there. A practical note about dates: these systems publish often and fast. Bottlerocket is on 1.64, Talos on 1.14 and Flatcar ships a release every few weeks across its two channels. The catalogue entries refresh themselves from official sources, so the version you see is today's, not the one from the day we wrote this.