Choosing Between Layering and Toolbox in Fedora Silverblue for Development Workflows

Problem: Keeping a mutable dev stack on an immutable OS

Fedora Silverblue mounts the root filesystem as read‑only and delivers updates as OSTree commits. This guarantees a reliable base, but it also means that traditional DNF install commands cannot write to /usr or /etc. When you need compilers, debuggers, or language‑specific libraries that change frequently, installing them directly on the host would break the immutability model.

Thesis: Use toolbox for most development needs, reserve layering for system‑wide utilities

Silverblue provides two complementary ways to add software: rpm-ostree install layers a package onto the immutable base, creating a new OSTree commit; toolbox starts a mutable container that shares the host’s home directory and can be discarded or recreated at will. For day‑to‑day coding, testing, and building, a toolbox gives you a full‑featured Linux environment without altering the base image. Layering is best suited for utilities that must be available in the host namespace, such as firmware flashers or kernel‑module builders that need direct access to /dev or /lib/modules.

Understanding Silverblue’s immutability

Each boot entry corresponds to an OSTree commit. Running rpm-ostree status shows the current deployment and any pending upgrades. The root filesystem is mounted with ro,bind flags, so any attempt to write to /usr results in a permission error. This design enables atomic upgrades and instant rollbacks, but it also shifts the responsibility for mutable software to the user.

When to layer versus when to toolbox

• Layer with rpm-ostree install when you need a binary that must be visible in the host’s PATH, appear in the GUI menus, or interact with hardware drivers that expect files in /usr/lib or /etc. Examples: proprietary GPU drivers, VPN clients that install system services, or custom kernel modules.
• Use toolbox for compilers, interpreters, debugging tools, and language‑specific packages that you only need inside a development shell. The container inherits your $HOME, so source code, SSH keys, and configuration files are instantly available.

Worked example: Setting up a Python toolbox

1. Create a container named devbox (you can choose any name):

   toolbox create devbox

2. Enter the container:

   toolbox enter devbox

   Inside the shell you have a regular Fedora environment with dnf available.
3. Install the Python stack you need. For instance, to get Python 3.12 and pip:

   dnf install -y python3 python3-pip

4. Verify the installation from inside the container:

   python3 --version
   pip --version

5. Exit the container when you are done; the changes persist until you delete or recreate the box:

   exit

To use the container without entering an interactive shell, run a command directly:

toolbox run devbox python3 -m pip list

Trade‑off and limitation

The main trade‑off is isolation versus convenience. A toolbox gives you a fully mutable environment, but GUI applications launched inside the container do not automatically appear on the host desktop unless you configure X11 or Wayland forwarding (e.g., with --env DISPLAY or a Flatpak wrapper). If you need a graphical IDE that integrates with the host’s menus, layering the IDE’s RPM or installing it as a Flatpak may be smoother. Additionally, the container does not have access to host system services such as libvirtd unless you explicitly bind‑mount the relevant sockets.

Actionable closing

Start by auditing the software you install daily. If a tool only needs command‑line access and you can live without a desktop shortcut, spin up a toolbox. Keep a short list of packages that truly require layering (e.g., hardware drivers) and apply them with rpm-ostree install, then verify the new deployment with rpm-ostree status. After any layering operation, test a rollback with rpm-ostree rollback to ensure you can return to a known good state. This split approach preserves the reliability of Silverblue’s immutable base while giving you the flexibility of a traditional Linux workstation.