Testing distributions is part and parcel of everyday life for many developers, and some people even enjoy distro hopping as a hobby. The easiest approach to living life with multiple distributions is virtualization. There are various ways of running distributions in virtual environments. Options include hypervisors such as VMware, VirtualBox, KVM/Qemu, Gnome boxes, and Proxmox. Network-Attached Storage (NAS) systems such as Unraid and TrueNAS can also function as virtualization platforms for operating virtual machines (VMs) via a web interface.

Distrobox [1] is yet another option that lets you use any Linux distribution from inside your terminal. Introduced in 2021 and maintained by Luca Di Maio, Distrobox uses Fedora's toolbx utility [2] as a template. You can even use Distrobox with BoxBuddy [3] if you prefer working with a graphical user interface (GUI).

Distrobox styles itself as the Swiss Army knife of the distribution scene. Developers and package maintainers can use Distrobox containers to quickly test their applications on various distributions. Assuming you use Debian as your host system and have installed Arch Linux in Distrobox, you can test your packages not only against Arch Linux, but also against Debian, Fedora, SUSE, and many other distributions.

Having said this, Distrobox itself is not a container engine. It relies on Docker, Podman, or Lilipod to create the containers in which the distributions run later. These containers, which are tightly integrated with the host system, support sharing of the host's home directory, integrating external storage and USB devices, and running graphical applications on X11 and Wayland.

Distrobox will work on any Linux host; in fact, you can even use it in immutable distributions, such as Fedora Silverblue, to install low-level tools or drivers without undermining immutability. The immutable Vanilla OS, which Di Maio also co-develops, uses Distrobox as a model for its own unconventional apx [4] package manager. If all this functionality makes you think that Distrobox is complex, you would be wrong. You'll find it easy to install Distrobox and use it either in the terminal or with BoxBuddy.

Di Maio recommends using Podman as the container engine, because, unlike Docker, it does not require root privileges by default. You will need to install three packages: Podman (or Docker or Lilipod), Distrobox, and BoxBuddy (if you want a GUI).

Podman and Distrobox can be installed using the built-in package manager on most distributions (Listing 1). Once you have completed the install, you can check whether Podman is working by typing

podman run quay.io/podman/hello

01 ### Installing on Debian
02 $ sudo apt update && sudo apt install podman distrobox
03 ### Installing on Fedora
04 $ sudo dnf update && sudo apt install podman distrobox
05 ### Installing on Arch Linux
06 $ pacman -S podman distrobox

If you see something like the output shown in Figure 1, you are ready for the first container.

Figure 1: Podman reporting in as ready for action and showing links to useful websites and documents.

If you used Docker instead, the command

sudo systemctl is-active docker

will simply output an active string if the install was successful.

First Container

To create your first container, you just need the distrobox create command. The developers have already integrated support for Intel and AMD graphics cards, and the containers automatically install the latest available Mesa DRI drivers. If you are running an NVIDIA graphics card and want to loop it through to the container, you need to call

distrobox create --nvidia

Distrobox will then automatically create a container and install Fedora in it without you having to specify any other options (see Figure 2). The console output also tells you that this container's name is my-distrobox. When you do not specify a distribution or a container name in the create command, you simply get a distribution that reflects its toolbx roots.

Figure 2: Without specifying any further options, the create command creates a container based on the latest Fedora 41 and shows you the command for accessing it.

Fedora by Default

As soon as you have set up the container along with Fedora (Figure 3), you can enter the container by typing

distrobox enter my-distrobox

Figure 3: After creating a container, Distrobox installs the required packages and sets up a user account, sudo, and the init system.

The prompt tells you that you are in the my-distrobox container, but to find out what else is going on, you need to type

cat /etc/os-release

In this example, I set up the Fedora 41 version of toolbx. If you then type uname -r to query the kernel version, you will see that your host's kernel is being used to save resources.

To create another container, simply type exit to leave my-distrobox. For the next container, I'll exercise a little more control by specifying the distribution and assigning a name (Listing 2). You can use the -n option to assign a name and --image to specify which distribution you want to install (Figure 4). To use the latest release, you can simply type latest instead of a version number.

$ distrobox create -n ubu --image ubuntu:24.10

Figure 4: Adding a couple of parameters to the create command lets you define the container name and distribution.

Container Registries

You can find out where Distrobox sources images from in the /etc/containers/registries.conf.d/shortnames.conf file, which contains a list of the most important distributions along with their shortnames.

Further distributions and packages can be found in container registries such as Quay.io [5], GitHub Container Registry [6], and Amazon Elastic Container Registry [7]. To define distributions that you want to use, you can specify an abbreviation in shortnames.conf instead using the long URI. The distrobox list command helps you keep track of the installed distributions (Figure 5). As usual, typing distrobox -h (for help) will list the commands that you can use in Distrobox.

Figure 5: The list of containerized distributions shows you the image's ID, name, status, and origin.

After installing a few distros, I decided to experiment a little in my lab, starting with installing the Nautilus file manager in the Arch container. The integration of the home directory went surprisingly smoothly. I was able to set up remote shares that integrated with my home directory using WebDAV, NFS, or SMB. Apps running in different distribution containers can also be passed through to the host and used there (Figure 6).

Figure 6: After exporting, a version of Firefox installed in the Arch container is listed on the host system next to the local Firefox installation.

I installed Nautilus, as shown in Figure 7, using

distrobox-export --app nautilus

Figure 7: The Nautilus file manager in the Arch container not only binds the host's home directory but also transparently accesses the shares linked to it.

Nautilus then appeared in the host's menu system where I was able to launch it. This approach lets you use packages from the archives of the distributions installed in Distrobox on your host [8]. Having multiple versions of an application from different distributions is not a problem. Peripherals connected to the host, such as USB storage devices or external hard drives, are automatically passed through to Distrobox.