Does Toolbx work on standard Fedora Workstation, or only on Silverblue?

Toolbx works on both. It is most essential on Silverblue and Kinoite where the root filesystem is immutable, but it is equally useful on standard Fedora Workstation to keep the base system clean.

Are Toolbx containers the same as Docker or Podman containers?

Toolbx containers are OCI containers managed by Podman, but they are configured with extra mounts and shared namespaces (home directory, D-Bus, network, PID namespace) so they feel like a local shell rather than an isolated service container.

Will files I create inside a Toolbx container persist after I exit?

Yes. The container itself persists (it is not ephemeral by default), and your home directory is a bind mount, so files there survive even if you delete the container. Files written to container-only paths like /usr are lost when the container is removed.

Can I use a non-Fedora image, such as an Ubuntu image, with Toolbx?

Toolbx officially supports Fedora-based images. You can point it at other OCI images with `toolbox create --image `, but support is best-effort — the Ubuntu image, for example, may lack some expected integration points.

How do I update packages inside a Toolbx container?

Enter the container and run `sudo dnf upgrade` as you would on any Fedora system. Toolbx containers are not automatically updated when the host upgrades; you manage them independently.

Use Toolbx on Fedora (and Silverblue)

Toolbx (formerly toolbox) solves a real problem on immutable systems like Fedora Silverblue or Kinoite: your root filesystem is read-only, so you cannot install development tools, compilers, or random packages directly on the host. Even on standard Fedora Workstation, Toolbx gives you a clean, disposable environment that keeps the base system tidy. It wraps podman to spin up OCI containers that share your home directory, D-Bus socket, and most of the host namespaces — so it feels like a normal shell, not a VM.

Prerequisites and Installation

On Fedora Silverblue and Kinoite, Toolbx is pre-installed. On standard Fedora Workstation it is usually present as well. Check first:

toolbox --version

If it is missing, install it. Toolbx is available on any system with podman, including Debian/Ubuntu and Arch, but the workflow below targets Fedora.

# Fedora Workstation / Atomic desktops (already installed, but just in case)
sudo dnf install toolbox podman

# Debian / Ubuntu
sudo apt install podman-toolbox

# Arch Linux (AUR)
yay -S toolbox

Podman must be functional without sudo — rootless containers are the default and expected mode. Verify:

podman info --format '{{.Host.Security.Rootless}}'

The output should be true.

Creating a Container

Default container

Running toolbox enter with no arguments creates and enters a container that matches your host Fedora version. This is the fastest path for most users.

toolbox enter

The first run pulls the registry.fedoraproject.org/fedora-toolbox image for your release — expect a few hundred megabytes on first use. Subsequent runs are instant.

Named containers and pinned releases

You will often want multiple containers for different projects or a different Fedora release. Use --container and --release:

# A container named "dev" running Fedora 40
toolbox create --container dev --release f40

# A container pinned to Fedora 39 for legacy compatibility
toolbox create --container legacy39 --release f39

Enter a named container explicitly:

toolbox enter dev

Listing and removing containers

toolbox list          # shows containers and cached images
toolbox rm dev        # remove a stopped container
toolbox rmi fedora-toolbox:40   # remove a pulled image

Installing Packages Inside a Container

Once inside, the container behaves like a normal Fedora installation. You have full dnf access and sudo rights (your user is in the wheel group by default inside the container).

# Inside the toolbx container
sudo dnf install gcc make clang python3-devel nodejs neovim

There is no need to hold back — install whatever the project needs. The host OS is completely unaffected. To confirm you are inside the container, look at the shell prompt: it typically shows the container name, or you can check:

cat /run/.toolboxenv   # exists only inside a toolbx container

Accessing your home directory

Your $HOME is bind-mounted into the container at the same path. Files you create inside are immediately visible on the host. There is no syncing step — it is the same directory.

ls ~          # same files as on the host
pwd           # /home/yourname — identical path

Running host binaries from inside the container

Toolbx mounts /usr/bin/flatpak and a few other host paths into the container so you can still launch Flatpak apps. For arbitrary host binaries, use the host-spawn helper or simply exit the container and run them on the host.

GPU Access

GPU access inside Toolbx works but requires the right drivers and libraries to exist inside the container. The host kernel handles the hardware; the container needs matching userspace.

NVIDIA

Toolbx does not automatically pass NVIDIA devices through. Install the CUDA toolkit and the NVIDIA container libraries inside the toolbx container:

# Inside the container — add RPM Fusion and install drivers matching the host
sudo dnf install https://download1.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm
sudo dnf install akmod-nvidia xorg-x11-drv-nvidia-cuda

The kernel module itself lives on the host; only userspace needs to match. After installation, verify:

nvidia-smi

AMD and Intel (Mesa / Vulkan)

Mesa-based drivers (AMD RDNA, Intel Arc and integrated) work out of the box because Toolbx mounts /dev/dri into the container by default. Install Mesa inside the container if the base image does not have it:

# Inside the container
sudo dnf install mesa-vulkan-drivers vulkan-tools

Test Vulkan enumeration:

vulkaninfo --summary

For OpenGL workloads, glxinfo should report the hardware renderer, not a software fallback:

sudo dnf install glx-utils
glxinfo | grep "OpenGL renderer"

If you see llvmpipe, the container is not reaching the GPU — check that /dev/dri exists inside with ls /dev/dri and that your user is in the video and render groups on the host.

Running GUI Applications

On Wayland (the default on Fedora), Toolbx passes the WAYLAND_DISPLAY socket through automatically. Most GTK and Qt apps just work:

# Inside the container — launch a GUI app
gedit myfile.txt
code .   # VS Code, if installed inside the container

On XWayland sessions the DISPLAY variable is also forwarded. If a GUI app fails to launch, check that $WAYLAND_DISPLAY is set inside the container:

echo $WAYLAND_DISPLAY   # should print something like wayland-0

Integrating with systemd and the Host Desktop

Toolbx containers share the host's systemd user session — so systemctl --user commands inside the container affect the same user units as on the host. Be deliberate about enabling user services from inside a container.

You can also run a command directly in a container without an interactive shell, which is useful for scripting:

toolbox run --container dev python3 ~/projects/myscript.py

Verification

# List all toolbx containers and their status
toolbox list

# Confirm you are inside a container
cat /run/.toolboxenv && echo "Inside toolbx"

# Confirm home directory is shared
touch ~/toolbx-test && ls ~/toolbx-test   # visible on host too

Troubleshooting

Container fails to start after a Fedora upgrade: The toolbx image version may no longer match. Run toolbox create --release fXX with the new version number and migrate your workflow. Old containers still run but may feel stale.
dnf is slow inside the container: The container uses the Fedora mirror list. Add a local fastestmirror hint: echo 'fastestmirror=True' | sudo tee -a /etc/dnf/dnf.conf inside the container.
GPU not found inside container: Run ls -la /dev/dri inside the container. If the directory is empty or missing, your host's podman may be too old. Update to Podman 4.x: sudo dnf upgrade podman.
Wayland socket missing: If $XDG_RUNTIME_DIR is not set in the container, Wayland apps fail. This is a bug in older Toolbx versions. Update: sudo dnf upgrade toolbox.
Cannot use sudo inside container: Your user must be in the wheel group on the host. Check with groups on the host, and add if missing: sudo usermod -aG wheel $USER, then log out and back in.