You downloaded the ISO and now you have three choices
You navigated to the Fedora download page, clicked the Atomic Desktops link, and stopped. The page lists Silverblue, Kinoite, and Sway Atomic. They all mention "immutable," "rpm-ostree," and "container-first." The installer asks you to pick a variant. You installed Silverblue six months ago, loved the stability, but you really prefer KDE Plasma. Or you are a new user coming from Windows and GNOME feels alien. Picking the wrong ISO isn't fatal, but switching later requires a rebase that downloads gigabytes of data. You need to know which desktop environment matches your workflow before you commit.
Pick the ISO that matches your desktop. The core is identical.
What's actually happening under the hood
All three variants share the same immutable base. The difference is only the desktop environment and a few default tools. Under the hood, the root filesystem is read-only. Your system state lives in a base image managed by rpm-ostree. When you install software, it goes into a mutable overlay layer. Updates replace the entire base image atomically. If an update breaks, you boot the previous image. This architecture prevents configuration drift and makes rollbacks instant.
Think of the base image as a sealed library book. You cannot write in the margins. Your changes live in a separate notebook that sits on top of the book. When a new edition of the book arrives, you swap the book and keep your notebook. The notebook applies to the new edition automatically. This keeps the system clean and predictable.
The trade-off is that you cannot modify files in /usr. You manage packages differently than on standard Fedora Workstation. You do not run dnf install on the host. You use rpm-ostree for system packages, flatpak for desktop applications, and toolbox for development environments.
rpm-ostree upgrade replaces the entire OS tree. dnf upgrade does not exist on the host. Run rpm-ostree upgrade to update the system.
Trust the immutable model. You cannot break the base image.
How to verify your current variant
Run this command to see which variant you are currently running. The output shows the deployed OS trees and the current boot state.
rpm-ostree status
# WHY: Shows the deployed OS trees and the current boot state.
# Look for the "Deployments" section to find your base image name.
# The line starting with "●" indicates the currently booted system.
# The base image name contains the variant, such as silverblue or kinoite.
The output lists deployments. The top entry with the ● marker is the active system. Check the BaseCommit line or the repository name. You will see fedora/silverblue, fedora/kinoite, or fedora/sway. This confirms your variant.
If you see multiple deployments, you have rollback options. The second deployment is usually the previous version. You can boot it from the GRUB menu if the current one fails.
journalctl -xe reads better than journalctl alone. The x flag adds explanatory text and the e flag jumps to the end. Use journalctl -xeu rpm-ostree to check for update errors.
Run rpm-ostree status first. Know your base before you change it.
Switching variants with a rebase
You can switch variants without reinstalling. The process is called a rebase. It downloads a new base image and creates a new deployment. Your home directory, configuration files in /etc, and layered packages persist. The rebase is safe because the old deployment remains until you explicitly delete it.
Run this command to rebase to a different variant. Replace kinoite with your target variant.
rpm-ostree rebase fedora:40/kinoite/x86_64
# WHY: Switches the base image to the specified variant.
# This downloads the new base and creates a new deployment.
# Reboot to activate the new variant.
# The old deployment stays available for rollback.
The command downloads the new tree. It may take several minutes depending on your connection. After the download completes, reboot. The system boots the new variant. If something goes wrong, select the previous deployment in GRUB.
Rebasing preserves your layers. If you installed a package with rpm-ostree install, it stays installed. Your Flatpaks and Toolbox containers also persist. The only change is the desktop environment and default system packages.
Rebase is safe because the old deployment stays until you delete it. Keep the rollback option open.
Common pitfalls and error messages
Users often try to edit files in /usr/lib or /usr/bin. The filesystem is read-only. You will see Read-only file system errors. Edit configuration in /etc. If you need to modify a system file, use rpm-ostree admin replace or create a drop-in override.
Another pitfall is expecting dnf to work like Workstation. Running sudo dnf install vim on the host will produce an error.
Error: Transaction test error: package vim-minimal-2:9.0.x conflicts with vim-common-2:9.0.y from fedora
The conflict is intentional. The base image manages these packages. Do not force the transaction. Use toolbox for development tools.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/.
If you see [FAILED] Failed to start rpm-ostree.service during boot, your overlay might be corrupted. Boot the previous deployment and run rpm-ostree cleanup -m to remove broken metadata.
Edit /etc, never /usr. The overlay protects you from drift.
Development tools and containers
Atomic variants rely on containers for mutable environments. toolbox provides a command-line container with a full dnf environment. The container shares the host's /home and network stack. You can install development tools, compilers, and libraries inside the container without affecting the host.
Run this command to create a toolbox container.
toolbox create --container fedora-toolbox-40
# WHY: Creates a mutable container with a full dnf environment.
# The container shares the host's /home and network stack.
# Use this for development tools, not system packages.
# The container name helps identify it in podman lists.
Enter the container with toolbox enter. Inside, you can run dnf install freely. The packages stay inside the container. Your host remains clean.
firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge. This applies to the host firewall, not the container.
Use Toolbox for dev tools. Keep the host clean.
Choosing the right variant
Use Silverblue when you want the standard GNOME experience with extensions and a polished workflow. Use Kinoite when you prefer KDE Plasma, need deep desktop customization, or are migrating from Windows. Use Sway Atomic when you want a tiling window manager, keyboard-centric navigation, and a minimal footprint. Stay on Workstation if you need to install kernel modules, run proprietary drivers that require /usr writes, or maintain legacy scripts that modify the host filesystem.
Silverblue follows the upstream GNOME workflow. It includes the Activities overview, dynamic workspaces, and GNOME extensions. It is the reference implementation for Atomic Desktops.
Kinoite ships with KDE Plasma. You get the traditional panel, system tray, and deep configuration options. It supports both Wayland and X11 sessions. It is ideal for users who want familiarity and customization.
Sway Atomic ships with Sway, a tiling window manager compatible with i3. It targets keyboard-driven workflows and Wayland compositing. It has a smaller footprint and fewer background services. It requires comfort with configuration files and keyboard shortcuts.
Workstation uses dnf and a mutable filesystem. It allows direct installation of kernel modules and low-level driver patches. It is the choice for hardware that needs proprietary firmware or custom kernels.
Match the desktop to your muscle memory. The atomic core handles the rest.