History and core concepts
In 2014, Red Hat launched Project Atomic — an umbrella around immutable, container-oriented Fedora (and related) systems. Under it you had Fedora Atomic Host, CentOS Atomic Host, and RHEL Atomic Host on the server side, and later Atomic Workstation on the desktop. The two host lines targeted servers; Atomic Workstation was the desktop variant, shipped with GNOME.
They shared the same technical ideas: an immutable OS (stable, image-like base with /usr read-only in normal use) and atomic updates. Updates are delivered as a new bootable tree, not as in-place edits of files. The store and deployment model is OSTree; on Fedora the integration that composes the OS from RPMs and switches versions is rpm-ostree (so you do not use dnf on the host to mutate the base the way you do on classic Fedora Workstation).
You can think of OSTree as “Git for the OS root”. The new OS is staged as a full deployment and you switch into it at reboot.
As of today, Atomic Host products are retired. Fedora Atomic Host was renamed to Fedora CoreOS and Atomic Workstation to Fedora Silverblue.
Fedora Silverblue
Fedora Silverblue is the successor to Fedora Atomic Workstation: Fedora GNOME desktop delivered as an immutable base. It is one of the Fedora Atomic Desktops; sibling editions swap GNOME for KDE (Kinoite), Sway, Budgie, or COSMIC.
On a normal Fedora Workstation, you drift over time: dnf changes /usr continuously. On Silverblue you keep the base small and predictable; GUI apps usually come from Flatpak. Flatpak installs desktop and CLI applications as sandboxed bundles, with their own runtimes, separate from the host’s rpm-ostree image. On Silverblue that is the usual way to add GUI software without layering RPMs on the base: apps update on their own lifecycle, and the immutable OS underneath stays stable. When you need a classic Fedora userland with dnf, compilers, and random packages, you can use Toolbx. It is mutable container, isolated from your root OS.
rpm-ostree
The Fedora project composes Silverblue’s base image from the same package ecosystem as Workstation, but assembled as a filesystem tree and published as OSTree commits. On your laptop, rpm-ostree tracks those commits as bootable deployments: you are always running one checked-out tree, with one or more others kept around for rollback.
Day to day you use commands such as rpm-ostree status (see current and pending versions), rpm-ostree upgrade (pull the latest base for your stream), and reboot when you want to switch to the new deployment. If something breaks, you pick the previous entry in the bootloader or use rollback features in the docs—your data in /home stays put; you are switching which read-only /usr tree you boot.
You can add a small number of RPMs “on top” of the base with rpm-ostree install (layering). That works, but rebuilding the layered image takes time and fights the “thin host” idea, so heavier needs usually go to Toolbx or Flatpak instead.
Fedora CoreOS
Fedora CoreOS is the successor to Fedora Atomic Host: a small image for servers and Kubernetes nodes, it has no GUI and the running OS is an rpm-ostree deployment. It is shipped with Ignition - tool for automated provisioning. It runs with initramfs, and reads JSON with configuration of disk partitions and filesystem types. Ignition it creates users, configure SSH keys and systemd units. Butane is a tool to write such a config, and verify it before apply. Other notable tool is Zincati - update agent. It is a daemon that handles automatic updates. It polls remote server to check if new OS version is available. Then uses rpm-ostree to download new immutable image. If maintenance window is configured, it reboots the machine to apply the update