Fedora Silverblue, an introduction for developers

The Fedora Silverblue project takes Fedora workstation, libostree and podman, puts them in a blender, and creates a new Immutable Fedora Workstation. Fedora Silverblue is an OS that stops you from changing the core system files arbitrarily, and readily allows you to change the environment system files. The article What is Silverblue describes the big picture, and this article drills down into details for the developer.

Fedora Silverblue ties together a few different projects to make a system that is a git-like object, capable of layering packages, and has a container focused work flow. Silverblue is not the only distribution going down this road. It is the desktop equivalent of CoreOS, the server OS used by Red Hat Openshift.

Silverblue’s idea of ‘immutable’ has nothing to do with immutable layers in a container. Silverblue keeps system files immutable by making them read-only.

Why immutable?

Has an upgrade left your system in an unusable state? Have you wondered why one server in a pool of identical machines is being weird? These problems can happen when one system library – one tiny little file out of hundreds – is corrupted, badly configured or the wrong version. Or maybe your upgrade works fine but it’s not what you’d hoped for, and you want to roll back to the previous state.

An immutable OS is intended to stop problems like these biting you. This is not an easy thing to achieve – simple changes, like flipping the file system between read-write and read-only, may only change a fault-finding headache to a maintenance headache.

Freezing the system is good news for sysadmins, but what about developers? Setting up a development environment means heavily customizing the system, and filling it with living code that changes over time. The answer is partly a case of combining components, and partly the ability to swap between OS versions.

How it works

So how do you get the benefits of immutability without losing the ability to do your work? If you’re thinking ‘containers’, good guess – part of the solution uses podman. But much of the work happens underneath the container layer, at the OS level.

Fedora Silverblue ties together a few different projects to turn an immutable OS into a usable workstation. Silverblue uses libostree to provide the base system, lets you edit config files in /etc/, and provides three different ways to install packages.

  • rpm-ostree installs RPM packages, similar to DNF in the traditional Fedora workstation. Use this for things that shouldn’t go in containers, like KVM/libvirt.
  • flatpak installs packages from a central flathub repo. This is the one-stop shop for graphical desktop apps like LibreOffice.
  • The traditional dnf install still works, but only inside a toolbox (a Fedora container). A developer’s workbench goes in a toolbox.

If you want to know more about these components, check out Pieces of Silverblue.

Rolling back and pinning upgrades

All operating systems need upgrades. Features are added, security holes are plugged and bugs are squashed. But sometimes an upgrade is not a developer’s friend.

A developer depends on many things to get the job done. A good development environment is stuffed with libraries, editors, toolchains and apps that are controlled by the OS, not the developer. An upgrade may cause trouble. Have any of these situations happened to you?

  • A new encryption library is too strict, and an upgrade stopped an API working.
  • Code works well, but has deprecated syntax. An upgrade brought error-throwing misery.
  • The development environment is lovingly hand-crafted. An upgrade broke dependencies and added conflicts.

In a traditional environment, unpicking a troublesome upgrade is hard. In Silverblue, it’s easy. Silverblue keeps two copies of the OS – your current upgrade and your previous version. Point the OS at the previous version, reboot, and you’ve got your old system files back.

You aren’t limited to two copies of your file system – you can keep more by pinning your favorite versions. Dusty Mabe, one of the engineers who has been working on the system since the Project Atomic days, describes how to pin extra copies of the OS in his article Pinning Deployments in OSTree Based Systems.

Your home directory is not affected by rolling back. Rpm-ostree does not touch /etc/ and /var/.

System updates and package installs

Silverblue’s rpm-ostree treats all the files as one object, stored in a repository. The working file system is a checked-out copy of this object. After a system update, you get two objects in that repository – one current object and one updated object. The updated object is checked out and becomes the new file system.

You install your workhorse applications in toolboxes, which provide container isolation. And you install your desktop applications using Flatpak.

This new OS requires a shift in approach. For instance, you don’t have to keep only one copy of your system files – you can store a few and select which one you use. That means you can swap back and forth between an old Fedora release and the rawhide (development) version in a matter of minutes.

Build your own Silverblue VM

You can safely install Fedora Silverblue in a VM on your workstation. If you’ve got a hypervisor and half an hour to spare (10 minutes for ISO download, and 20 minutes for the build), you can see for yourself.

  1. Download Fedora Silverblue ISO from
  2. https://silverblue.fedoraproject.org/download (not Fedora workstation from https://getfedora.org/).
  3. Boot a VM with the Fedora Silverblue ISO. You can squeeze Fedora into compute resources of 1 CPU, 1024MiB of memory and 12GiB of storage, but bigger is better.
  4. Answer Anaconda’s questions.
  5. Wait for the Gnome desktop to appear.
  6. Answer Initial Setup’s questions.

Then you’re ready to set up your developer’s tools. If you’re looking for an IDE, check these out. Use flatpak on the desktop to install them.

Finally, use the CLI to create your first toolbox. Load it with modules using npm, gem, pip, git or your other favorite tools.


If you get stuck, ask questions at the forum.

If you’re looking for ideas about how to use Silverblue, read articles in the magazine.

Is Silverblue for you?

Silverblue is full of shiny new tech. That in itself is enough to attract the cool kids, like moths to a flame. But this OS is not for everyone. It’s a young system, so some bugs will still be lurking in there. And pioneering tech requires a change of habit – that’s extra cognitive load that the new user may not want to take on.

The OS brings immutable benefits, like keeping your system files safe. It also brings some drawbacks, like the need to reboot after adding system packages. Silverblue also enables new ways of working. If you want to explore new directions in the OS, find out if Silverblue brings benefits to your work.

Fedora Project community


  1. Giovanni Fabbro

    Silverblue is a nice option for a VM if you’re not already on Fedora, but I found Toolbox to be the dead-simple option for testing. The biggest issue I’ve found with Silverblue is that some common desktop components need to be layered RPM’s but when you start getting into numerous RPM layers, updates tend to break the install. And then not every application is available from the Fedora Registry so you’re dealing with Flathub packages that have big redundant desktop runtimes as hard-coded dependencies, sometimes even outdated ones.

    The nice thing about Toolbox is that you can still use it on Fedora Workstation. It’s great for command-line stuff and running web servers locally and the like, but I’d like to see better integration of application installs with the host OS. Just for instance, simple things like integrating icon links for GUI applications installed in the container. The next step after that is being able to repackage that container so that it could be redeployed easily to other desktop machines. Whenever possible, I try to use containers instead of virtual machines. Toolbox makes that decision easy. Dealing with the headaches of having to custom code Docker config files is a pain whereas with any install of Fedora Workstation, I can have a container that acts somewhat like a VM without the overhead in 3 short commands, and I don’t have to give up any of the full flexibility of having an OS that has a standard package management system. When I’m done, I can blow away the container and continue using the traditional WS desktop.

  2. anteante

    I love it!
    It’s the perfect OS for a regular user 🙂

  3. Sergey


    Not exactly in the subject, but where is the documentation on the use of the Fedora containers in the clouds docker ?

    For example, I created a container in Silver Blue with the help of tolbox there wrote a program and now I need to convert this container to a docker format and send to the cloud. Is it possible to do that and how ? I know about oci but I’d like to hear about the docker.

    • If you want an intro to containers that can be found at the Silverblue docs site. There are ample documentation sites about docker including the download page for dockerfile docs
      Plus, there is this link to Fedora Docker Images

      • Sergey

        Thank you for the answer. I have studied all this documentation long ago I thought that there is already something that can endow a way of the developer on silverblue.

        For an example:
        1. Run SilverBlue
        2. Run Toolbox and write apps in. (example django apps)
        3. Exit toolbox and run : oci2docker, and transformation.
        4. push docker conteiner in registry docker.

  4. Leslie Satenstein

    As a single OS on a single computer, silvberblue is an interesting experiment.
    It is, as you wrote, immutable, and causes a multi-disk, multi-partition multi-system interfacing to become non-standard.

    My own operating system setup is like a solar system. In the centre I have my sun, a pool of development software and archives. Surrounding this core are earth (Fedora32), leap15,beta( Mars), Ubuntu(Neptune), and Arch (Mercury). My planet systems all interface to the centre core, (sun).
    Suddenly, the immutable advantage became an inconvenience, (odd man out), due to creating links to those system, and to lack of a grub interface.

    I think the concept is immutable is necessary, but not the way Silverblue implemented it. It will not work for me, but, if I could relocate some stuff, it would be a sure winner.

    Here is my view of how SB will work for me.

    The /silverblue and everthing below it is immutable and is locked, as if it is an operating system on a chip. My linux system would be as follows:


    back to the top The following are mutable by root.
    as before, and ONLY MUTABLE by ROOT.

    Flatpacks will be essential and the only way to maintain the Linux System(Silverblue) and the other user(mutables). In this my alternative configuration, it would be a win-win. Users with practices where a common core of applications, libraries, backups and accessability serve multiple systems.

    The /silverblue entries and all subdirectories below /silverblue are immutable, providing the protection, stability and performance desired.

    Yes, I still visit to experiment with Silverblue to test it out, but i have not yet established a chainloader entry to allow me to use Fedora32’s grub menu to launch SB. I have to modify the system bios to boot to Silverblue.
    A sample chainloader file follow up article would be appreciated.

    • Do you run Solaris?

    • I agree. Running a container with /etc/sysconfig/readonly-root enabled makes a lot more sense to me too. I would seem that if you backed the container with a log-based file system that supports snapshots,rollbacks, and clones, then you would have all the benefits of silverblue without any of the drawbacks (e.g. having to reboot every time you want to install/change something).

      • Alek Paunov

        Which file system would you recommend for that purpose?

    • What in the world does that mean? I’m very good with that kind of stuff, but this left me hanging awkwardly. Please explain!

    • Sergey

      Sorry, but it seems to me that your question is somewhat similar to the one that I tried to find out earlier.


  5. George

    Been using Silverblue for a year now, and can honestly say it’s the best Linux distro I’ve ever used, and I’ve been using Linux for over 20 years.

    A big thank you to the good people at Fedora and the open source contributors at large that made this happen!

  6. Stanislav G.

    Fedora Silverblue is an interesting attempt to create, indeed, a very stable system. I like the idea, yet I would not recommend it to anyone. Layered packages are a painful experience. The benefits are not obvious for the end user. I believe the Clear Linux stateless design is the inevitable future for all distributions of GNU/Linux. Were I a Fedora developer, I’d go this way.

    • johnm

      I dissagre.

      This is THE best OS for a normal user.

  7. I checked Silverblue and it is amazing, thanks! Because I have to use Windows for my work, Silverblue’s immutable concept would be ideal to be available on WSL2 (Windows Subsystem for Linux v2), so I could switch back-and-forth using the same $HOME, regardless the underlying OS.

    Is this something that Team Silverblue considers in the foreseeable future? If you need any non-windowscoding help, testing, hit me up!

Comments are Closed

The opinions expressed on this website are those of each author, not of the author's employer or of Red Hat. Fedora Magazine aspires to publish all content under a Creative Commons license but may not be able to do so in all cases. You are responsible for ensuring that you have the necessary permission to reuse any work on this site. The Fedora logo is a trademark of Red Hat, Inc. Terms and Conditions