You are on Debian stable and need a tool that only exists in the AUR. Or you are on Arch and need to build against an old Ubuntu for compatibility. Or you are on an immutable system where the root filesystem is read-only and apt install is not a thing.

Distrobox solves all three by running another distribution in a container that feels like a normal shell.

What it actually does

Distrobox creates a container with your home directory mounted, your user replicated inside with the same UID, and enough of the host integrated that it stops feeling like a container. Your files are simply there. Graphical applications display on your desktop. Devices, including the GPU, are available.

This is deliberately the opposite of what containers usually do. A production container isolates a process from the host. Distrobox tears that isolation down on purpose, because the goal is a different userspace, not a security boundary.

sudo apt install distrobox podman      # Debian and Ubuntu
sudo dnf install distrobox             # Fedora
sudo pacman -S distrobox               # Arch

Using it

# Create
distrobox create --name arch --image archlinux:latest
distrobox create --name ubuntu2204 --image ubuntu:22.04

# Enter
distrobox enter arch

# Inside, it is that distribution
sudo pacman -S ripgrep bat fd

The first entry takes a moment while it sets up the user and installs a few integration packages. After that it is instant.

distrobox list
distrobox stop arch
distrobox rm arch

Exporting applications

This is what makes it practical rather than a curiosity.

# Inside the container
distrobox-export --app gimp             # graphical app to the host menu
distrobox-export --bin /usr/bin/rg --export-path ~/.local/bin

The exported application appears in your host application menu, and the exported binary is on your PATH. Running rg on the host executes it inside the container without you thinking about it.

The result is a system where the host stays clean and minimal while the tools you use come from wherever suits them.

Where it genuinely helps

Old toolchains. A project that needs GCC from a specific era builds in a container of that era’s distribution, and your host stays current.

AUR access from anywhere. An Arch container gives you the AUR on Debian, Fedora, or anything else. Our AUR explainer covers the trust model, which applies inside a container exactly as it does outside.

Immutable hosts. On Silverblue, Bazzite, or Vanilla OS, this is the intended way to get command-line tooling without layering packages onto the base image.

Testing across distributions. Verify a script works on Debian, Fedora, and Alpine without three virtual machines.

Keeping the host clean. Development dependencies live in a container that you can delete and recreate, rather than accumulating on the host over years.

Toolbox

Fedora’s equivalent, and simpler by design:

toolbox create
toolbox enter
toolbox list

It is well integrated on Fedora and Silverblue and mostly limited to Fedora images. Distrobox supports far more base images, works with Podman or Docker, and runs anywhere. Both can coexist.

The honest limitations

It is not isolation. Your home directory is mounted read-write. A malicious package inside the container can read ~/.ssh and your browser profile. If you need actual sandboxing, use a plain container without home mounted, or a VM.

Systemd services do not work normally. These containers are for interactive use, not for running daemons. Run services on the host or in a proper container.

The kernel is shared. Anything needing a different kernel or a kernel module belongs in a VM.

Storage adds up. Each container carries a full base image. podman system df will tell you how much, and it is usually more than you expected.

A reasonable setup

# One general-purpose container for tools
distrobox create --name tools --image archlinux:latest

# One per project that has awkward dependencies
distrobox create --name legacy-build --image ubuntu:20.04

# Enter directly without a separate step
distrobox enter tools -- fish

The pattern that works long term is a minimal, stable host with containers doing the messy parts. It is the same reasoning behind immutable distributions, applied without having to adopt one.

Frequently Asked Questions

How is Distrobox different from a normal container?

It is a normal container, configured for interactive use. Your home directory is mounted, your user exists inside with the same ID, and the shell feels like a login on that distribution. A plain container isolates you from the host, which is exactly what you do not want here.

Distrobox or Toolbox?

Toolbox is Fedora’s tool and works well within the Fedora ecosystem. Distrobox supports many more base images, works with both Podman and Docker, and runs on any distribution. Distrobox is the more flexible choice, Toolbox the more integrated one on Fedora.

Is this a security boundary?

No, and it should not be treated as one. Your home directory is mounted read-write, so anything in the container can read your SSH keys and browser profile. Use it for convenience and compatibility, not to sandbox untrusted code.

Why use this instead of a virtual machine?

Containers share the host kernel, so they start in under a second and use almost no memory, and your files are already there rather than behind a shared folder. A VM is the right answer when you need a different kernel or genuine isolation.

What does exporting an application do?

distrobox-export creates a launcher on the host that runs the program inside the container. The result appears in your application menu or on your PATH and behaves like a normally installed program, which is what makes the setup practical day to day.

Do I need an immutable distribution for this?

No. It works on Ubuntu, Debian, Arch, and anything else. It is essential on immutable systems where the root filesystem is read-only, which is why it gets associated with them, but it is just as useful on a traditional install.