Distrobox is a fascinating project that lets us run apps made for other distributions right on the one we’re using — a Debian app on Fedora, an RPM inside Ubuntu — without a VM, dual-booting, or a second desktop. Under the hood it uses Podman containers, but not the way Docker uses them: instead of isolating the app, Distrobox shares your home directory, display and audio with the container, so apps from the “wrong” distro open as ordinary windows on your desktop.
It sounded too good to be true, so I had to try it out to wrap my head around it. Before I forget the basics, here’s how to get started.
Installing Distrobox
The updates repo has the main package, we can install it via DNF. We also need podman, although it should come installed as default in Fedora (so that’s optional).
sudo dnf install distrobox podmanNow we’re ready to use the “distrobox” command. Note that we cannot run it as root.
Creating Containers
To create a new container we can use the -n switch (–name), followed by an arbitrary name. Without specifying an image, Distrobox will pick its own default — and be warned, that’s not necessarily your current distro and version. On my Fedora 44 system, a bare create pulled in a Fedora 43 image (one version behind). Handy to know if you want a slightly older environment, but surprising if you don’t.
distrobox create -n testingFor predictable results, specify the distro you’d like to use explicitly with the -i switch (–image). This is ideal if you want to run a single app and keep it and its twelve thousand dependencies isolated from your host OS.
distrobox create -n test -i ubuntu:24.04This will use the Ubuntu LTS 24.04 image as template (debian:12 works the same way). You can even provide your own image, as well as default packages you’d like to add. Quite the powerful little thing!
Starting a Container
Once installed, we can enter the container by using enter and its name:
distrobox enter testThe first time you run it it’ll take a little longer, but subsequent launches are as fast as opening a Terminal window. It’s seriously cool! Once inside, exit will get us back to the host’s command line. You can tell that you’re in a container because of a cute little box icon in front of your user name.
Note that exit doesn’t actually stop the container — it keeps running quietly in the background so the next enter is instant. To see what’s running, and to stop a container properly, use these:
distrobox list
distrobox stop testIn a container, we can install packages as needed, using the native package manager for its distribution. It behaves like a full VM, without being a full VM.
By default the user’s home directory is shared, which is great for exchanging files. We can use our host to download something, then use the container to install and run it.
Deleting a Container
If you’ve screwed it all up and “didn’t want to install DaVinci Resolve on Linux anyway”, you can delete your container again and forget this sorry affair ever happened:
distrobox rm testIf the container is running, it will be stopped. If it doesn’t work, add –force to the end.
Creating a native Shortcut
Say I wanted to setup a shortcut in my Fedora applications to launch an app inside a container. From inside the box (this is important — the command runs in the container, not on the host), export the app like so:
distrobox-export --app yourappThis drops a well-formed .desktop file into ~/.local/share/applications on the host, and your desktop does the rest: the app appears in your application menu (labelled with the container name, e.g. “MyApp (on test)”), launches with one click — starting the container on demand — and shows up in the task bar like any native app. It won’t look or behave any different from the real thing. I’ve since used this for the official Claude Desktop app, and the result genuinely blew me away — full story in How to install the Claude Desktop app on Fedora Linux (three ways).
Caveats
I use 3D and productivity apps, as well as games on my Linux desktop, so GPU support matters to me. Good news I didn’t know when I first drafted this article: the GPU is shared with the container — the device files under /dev/dri are passed through, so Intel and AMD graphics acceleration generally just work.
NVIDIA is the special case: the container needs the host’s proprietary driver userland to match, and Distrobox has a purpose-built flag for exactly that. Create your container with it and the host’s NVIDIA driver is mounted inside:
distrobox create -n cuda-test -i ubuntu:24.04 --nvidiaIn other words: if a GPU-hungry app failed for you in Distrobox (as DaVinci Resolve once did for me), the missing –nvidia flag may well have been the reason. A rematch is on my list.
Real-world examples
This isn’t just a party trick, I’ve used Distrobox for real software that isn’t offered for Fedora, and it works great on my workstation:
- The official Claude Desktop app (Debian/Ubuntu only) in a Debian 12 box — with full desktop integration
- Faceform Wrap in an Ubuntu 24.04 box — three extra packages and it ran