Larvitz Blog

Immutable Linux Desktops: Universal Blue, OSTree, and the Future of Desktop Linux

Traditional Linux desktop installations accumulate state over time. Package upgrades modify system files in place, configuration changes drift from defaults, and after a few years, systems become unique snowflakes that are difficult to reproduce or repair. Atomic desktops take a fundamentally different approach: the operating system is treated as a single, versioned image that can be deployed, rolled back, or replaced entirely.

This model has proven itself in server infrastructure through CoreOS and similar projects. Now it’s coming to the desktop through Fedora’s atomic variants and, more ambitiously, through Universal Blue’s community-built images like Aurora and Bazzite.

The Foundation: OSTree

At the heart of atomic Linux systems lies OSTree (also known as libostree), a content-addressed filesystem designed to store and deploy complete bootable operating system trees. Think of it as “git for operating systems”. Though the comparison is imperfect, it captures the essential concept.

OSTree stores filesystem trees as immutable, deduplicated objects identified by their content hash. When you deploy a new system version, OSTree:

  1. Downloads only the changed objects (delta updates)
  2. Hardlinks unchanged files from the existing deployment
  3. Creates a new boot entry pointing to the new tree
  4. Keeps the previous deployment intact for rollback

The result is atomic updates - the system either fully transitions to the new state or remains unchanged. No more half-completed upgrades leaving your system in an inconsistent state. No more “let me try rebooting again” after a failed update.

$ sudo rpm-ostree status
State: idle
Deployments:
  fedora:fedora/43/x86_64/silverblue
                  Version: 43.20260126.0 (2026-01-26T00:26:25Z)
                   Commit: e36246b0837cfe0d1c09e3ee60205ed5be57d57260adc10a625f9353bbef3c40
             GPGSignature: Valid signature by C6E7F081CF80E13146676E88829B606631645531
                     Diff: 522 upgraded, 11 removed, 26 added

● fedora:fedora/43/x86_64/silverblue
                  Version: 43.1.6 (2025-10-23T03:11:18Z)
                   Commit: 4d40d281be93a88f3d559b5756df602f454f932f3c809a6a4250b91049ce40e8
             GPGSignature: Valid signature by C6E7F081CF80E13146676E88829B606631645531

The bullet point indicates your current deployment. The previous deployment remains available - a single rpm-ostree rollback and reboot returns you to the exact state you left.

rpm-ostree: Hybrid Package Management

While pure OSTree deployments are completely immutable, desktop users need flexibility. Enter rpm-ostree, which provides a hybrid model: you get the reliability of image-based deployments while retaining the ability to layer additional RPM packages.

The base system remains a verified, signed image from your distribution. On top of this, rpm-ostree allows you to:

  • Layer packages: Install additional RPMs that persist across updates
  • Override packages: Replace base system packages with different versions
  • Remove packages: Exclude unwanted components from the base image
# Layer a package on top of the base image
rpm-ostree install htop neovim

# Override a base package with a newer version
rpm-ostree override replace ./updated-package.rpm

# Remove a base package you don't need
rpm-ostree override remove firefox

Each modification creates a new deployment, leaving the previous state intact. Updates from upstream are rebased on top of your layered packages, maintaining a coherent system state.

The key insight: your customizations are explicit and tracked. Unlike traditional package managers where the system state is the accumulated result of thousands of operations over time, rpm-ostree maintains a clear separation between the base image and your modifications.

bootc: Container-Native Systems

The current standard in this space is bootc, which takes the logical next step: if containers are the standard way to build and distribute software, why not use them for entire operating systems?

bootc systems are built as standard OCI container images. The same tools used for application containers - Podman, Docker, Buildah - can build bootable system images. The same registries that host application images can host operating system images. The entire container ecosystem becomes available for OS development.

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

# Install additional packages
RUN dnf install -y htop neovim && dnf clean all

# Add custom configuration
COPY custom-config.conf /etc/myapp/

# Standard container build produces a bootable system

Building this Containerfile produces a complete, bootable operating system image. You can test it in a VM, push it to a registry, and deploy it to physical hardware. The same image works everywhere.

bootc uses OSTree under the hood for the actual deployment mechanics, but the authoring experience shifts entirely to container workflows. For organizations already invested in container tooling, this dramatically simplifies system management.

Current state: bootc is production-ready for servers and is making rapid progress on desktop support. Universal Blue’s images are already built using container workflows, positioning them well for the full bootc transition.

Fedora Atomic Desktops

Fedora provides official atomic desktop variants, each tailored to a specific desktop environment:

Variant Desktop Environment Target Users
Fedora Silverblue GNOME General desktop users
Fedora Kinoite KDE Plasma KDE enthusiasts
Fedora Sway Atomic Sway Tiling WM users
Fedora Budgie Atomic Budgie Budgie fans

These provide the foundation: a stable, tested base with Fedora’s regular release cadence. They’re excellent choices for users who want the atomic model with minimal deviation from upstream Fedora.

However, Fedora’s official images are intentionally conservative. They include only what’s necessary for a functional desktop, leaving additional customization to the user through package layering.

Universal Blue: Opinionated Images Done Right

Universal Blue takes the Fedora atomic base and builds upon it with thoughtful defaults, additional hardware support, and curated software selections. Rather than starting from scratch, they leverage Fedora’s extensive testing and add value through careful curation.

The project produces several image variants:

Aurora

Aurora is Universal Blue’s flagship desktop image, based on Fedora Kinoite (KDE Plasma). It targets users who want a polished, productive desktop without manual configuration:

  • Enhanced hardware support: Additional firmware, codecs, and drivers included (UBlue images come with Nvidia drivers pre-installed and signed)
  • Developer tooling: Distrobox pre-configured for containerized development environments
  • Quality-of-life improvements: Thoughtful defaults and missing pieces filled in
  • Automatic updates: System images update in the background and apply on reboot

Aurora represents what a modern Linux desktop can be when someone with taste makes the integration decisions. The KDE Plasma experience feels cohesive and complete.

Bazzite

Bazzite targets gaming and HTPC use cases, building on the same solid foundation with gaming-specific optimizations:

  • Steam and Lutris: Pre-installed and configured
  • Graphics drivers: Latest Mesa, Vulkan support, and vendor-specific drivers
  • Controller support: Out-of-box recognition for a wide range of game controllers
  • Performance tuning: Kernel parameters and system settings optimized for gaming
  • Steam Deck compatibility: Specific images for Steam Deck and similar handhelds
  • HTPC mode: Console-like experience for living room setups

Bazzite solves the perennial “gaming on Linux” setup problem. Instead of spending an afternoon configuring drivers, Proton, and various compatibility layers, you boot into a system where everything already works.

Other Variants

Universal Blue also produces:

  • Bluefin: GNOME-based developer workstation image
  • uCore: Server-focused images based on Fedora CoreOS
  • Framework-specific images: Optimized for Framework laptop hardware

The Advantages of Atomic Desktops

Reliability and Stability

The most significant advantage is predictability. Every user running Aurora 43.20260126 has exactly the same base system. Support becomes tractable - you’re not debugging the unique accumulated state of someone’s five-year-old installation.

Updates are atomic: they either complete successfully or don’t happen at all. The half-updated, inconsistent states that sometimes plague traditional distributions simply cannot occur.

Painless Rollback

Every update preserves the previous system state. If an update causes problems:

# Rollback to the previous deployment
rpm-ostree rollback
systemctl reboot

After reboot, you’re running the exact system you had before the update. This isn’t “uninstall the broken package and hope” - it’s a complete restoration of the previous state.

This dramatically lowers the risk of updates. You can confidently run the latest packages knowing that recovery is trivial.

Rebasing: Switch Distributions Instantly

Perhaps the most surprising capability: you can switch between compatible images without reinstalling. Running Aurora but want to try Bazzite for gaming?

# Rebase to Bazzite
rpm-ostree rebase ostree-unverified-registry:ghcr.io/ublue-os/bazzite:latest # (Select the specific tag for your hardware/GPU)
systemctl reboot

After reboot, you’re running Bazzite. Your home directory, user data, and Flatpak applications remain untouched - only the base system changed. Don’t like it? Rebase back to Aurora.

This works across any compatible OSTree-based images. You can move between Fedora’s official images and Universal Blue’s variants freely. The operating system becomes as swappable as a container image - because, fundamentally, that’s what it is.

Separation of Concerns

Atomic desktops enforce a clean separation:

  • System image: Managed by OSTree, updated atomically, reproducible
  • Applications: Installed via Flatpak, containerized, independent of system
  • User data: Lives in your home directory, persists across rebases
  • Development tools: Run in Distrobox containers, isolated from system

This separation means you can experiment freely with your development environment without risking system stability. Your tooling runs in containers; your OS remains pristine.

Reproducibility

Need to set up a new machine identically to your current one? The process is trivial:

  1. Install the same base image
  2. Apply the same layered packages (if any)
  3. Sync your home directory

There’s no “reinstall all the packages I’ve accumulated over five years” step because your system state is declaratively defined by the image plus your explicit modifications.

Working with Atomic Desktops

Daily Workflow

Day-to-day usage feels identical to traditional Linux. You use your applications, edit documents, browse the web. The atomic nature is invisible until you need it.

Updates happen automatically in the background. When a new image is ready, you’ll see a notification. The update applies on your next reboot - no waiting for package downloads during your workday.

Installing Software

For graphical applications, Flatpak is the primary method:

flatpak install flathub org.mozilla.firefox
flatpak install flathub com.spotify.Client

Flatpak applications are containerized and independent of the base system. They update separately and work across all Linux distributions.

For command-line tools and development environments, Distrobox provides seamless container integration:

# Create a development container
distrobox create --name dev --image fedora:43

# Enter the container - it feels like native
distrobox enter dev

# Inside the container, install whatever you need
sudo dnf install gcc cmake python3-devel

Distrobox containers integrate with your desktop - applications appear in your menu, files are accessible, and the experience is nearly transparent.

Crucially, you can export binaries or GUI apps from the container to the host. This means you can launch tools like VS Code or PyCharm directly from your system dock or application menu, just as if they were installed natively.

When to Layer Packages

Some software legitimately needs system integration that Flatpak can’t provide:

  • Virtualization: libvirt, QEMU, virt-manager
  • VPNs: OpenVPN, WireGuard with system integration
  • System services: Custom daemons that run at boot
  • Kernel modules: Out-of-tree drivers (though check if the image already includes them)

For these cases, rpm-ostree layering is appropriate:

rpm-ostree install libvirt virt-manager
systemctl reboot

The general guidance: use Flatpak when possible, Distrobox for development, and rpm-ostree layering only when neither alternative works.

Considerations and Trade-offs

Atomic desktops aren’t without trade-offs:

Adjustment Period

Users accustomed to dnf install whatever need to adapt their mental model. The system isn’t broken - it’s intentionally designed to guide you toward better patterns. This adjustment takes a few days for most users.

Reboot Requirements

System changes require a reboot to take effect. While this ensures atomicity, it can feel inconvenient compared to traditional package managers. In practice, most users update infrequently enough that this isn’t burdensome.

Layered Package Limits

While you can layer packages with rpm-ostree, heavy layering defeats the purpose. If you’re layering fifty packages, you’re fighting the model. Consider whether those packages truly need system integration or whether Flatpak/Distrobox would work.

Some Niche Software

Certain applications expect traditional FHS layouts or assume they can modify system files. Most mainstream software works fine, but occasional edge cases exist.

Getting Started

Choosing an Image

For general desktop use with KDE Plasma: Aurora

For gaming or HTPC: Bazzite

For GNOME and developer workflows: Bluefin

For conservative, upstream-focused experience: Fedora Silverblue/Kinoite

Installation

Universal Blue images install like any other Linux distribution. Download the ISO, create a bootable USB, and run the installer. The Anaconda installer handles partitioning, user creation, and initial setup.

Post-installation, enable automatic updates if not already enabled:

sudo systemctl enable --now rpm-ostreed-automatic.timer

First Steps

  1. Explore Flatpak: Visit Flathub and install your essential applications
  2. Set up Distrobox: Create a development container for your programming environment
  3. Configure your desktop: KDE Plasma or GNOME settings work exactly as expected
  4. Verify automatic updates: Check rpm-ostree status to see your current deployment

The Future

The atomic desktop model aligns with where computing is heading. Containers have proven their value for applications; applying the same principles to the operating system itself is the logical evolution.

bootc represents the next major step, unifying system management with container tooling. Universal Blue is already building toward this future while maintaining stability today.

For users tired of nursing aging installations, wondering what broke after the last update, or simply wanting a system that stays out of their way, atomic desktops offer a compelling alternative. They’re not experimental technology - they’re the result of years of refinement in the server space, now polished for desktop use.

The best part: if you don’t like it, you can always rebase back.

References

Thanks to the Universal Blue community for building these excellent images and to the Fedora team for providing the solid foundation they’re built upon.