Your Linux host does not need every compiler, repository, SDK, and command-line tool you use. Distrobox gives each workload its own distribution while keeping the result connected to your desktop.
Run Fedora on Debian. Use Arch packages from an immutable operating system. Build software in Ubuntu without filling your host with development packages. Launch a graphical application from a container through your normal application menu.
For most Linux desktop users, Distrobox deserves a permanent place in the toolbox.
What Distrobox does
Distrobox creates OCI containers through Podman, Docker, or Lilipod. It adds deep host integration on top of the container engine.
Inside a box, you retain access to your normal home directory, display server, audio, network, removable storage, SSH agent, D-Bus, and other host services. Commands and graphical applications feel local even when their packages live inside another distribution.
Distrobox uses the host kernel. It starts much faster than a virtual machine and needs less memory. Each box still gets its own package database and user-space software.
This design fits several common jobs:
- Keep a stable host while using current development tools.
- Add packages to Fedora Atomic, SteamOS, openSUSE Aeon, and other immutable systems.
- Test a project across Fedora, Ubuntu, Arch, or openSUSE.
- Separate conflicting SDKs and language toolchains.
- Try distribution packages without adding their repositories to your host.
- Run a Linux desktop application missing from your host’s repositories.
Install Distrobox with a rootless container engine
Use your distribution’s package manager when it offers current Distrobox and Podman packages. The official installation guide lists supported methods for many distributions.
I prefer rootless Podman. It avoids a privileged daemon and maps container root to your unprivileged host account.
After installation, verify both commands:
podman --version
distrobox --version
See the container images supported by your installed release:
distrobox create --compatibility
Create your first development box
This example creates a Fedora environment named dev-fedora:
distrobox create --name dev-fedora --image fedora:latest
Enter it:
distrobox enter dev-fedora
The first entry takes longer because Distrobox prepares the image for host integration. Your shell prompt changes once setup finishes.
Install development packages with the container’s package manager:
sudo dnf install git gcc make
Your host stays unchanged. Fedora owns those packages and tracks their updates inside dev-fedora.
Leave the box with:
exit
Run one command without opening an interactive shell:
distrobox enter dev-fedora -- git --version
List, stop, and remove boxes with these commands:
distrobox list
distrobox stop dev-fedora
distrobox rm dev-fedora
Removing a box does not remove files saved in your shared home directory.
Your home directory follows you
Distrobox shares your host home directory by default. A project under ~/projects appears at the same path inside the box. You edit the same files from either environment, with the same user ownership.
This makes development pleasant. Clone a repository once, then build it in several boxes without copying source code between them.
Shared home access also has consequences. A program inside the box sees your documents, SSH configuration, browser profiles, and other user files unless host permissions block access.
Give a box a separate home when you want cleaner application settings or less accidental overlap:
mkdir -p ~/.local/share/distrobox-homes/test-fedora
distrobox create \
--name test-fedora \
--image fedora:latest \
--home ~/.local/share/distrobox-homes/test-fedora
This improves separation, but it does not turn Distrobox into a security sandbox.
Export applications to your desktop
Install a graphical application inside a box, then export its desktop entry. This example uses the AbiWord word processor:
distrobox enter dev-fedora
sudo dnf install abiword
distrobox-export --app abiword
exit
AbiWord then appears in your host application menu. Opening it starts the program inside dev-fedora, with access to your display and files.
Export a command-line program into ~/.local/bin from inside the box:
distrobox-export \
--bin /usr/bin/example-tool \
--export-path ~/.local/bin
Replace /usr/bin/example-tool with an installed executable. Confirm ~/.local/bin appears in your host PATH before relying on the exported command.
Remove an exported item from inside its box:
distrobox-export --app abiword --delete
distrobox-export \
--bin /usr/bin/example-tool \
--export-path ~/.local/bin \
--delete
Keep every box updated
A container still needs package updates. Upgrade one box by name:
distrobox upgrade dev-fedora
Upgrade all boxes:
distrobox upgrade --all
Run this on a schedule you understand. Read the package output and test important development environments after large upgrades.
Rebuild boxes from a file
An environment loses much of its value when nobody remembers how it was assembled. Distrobox Assemble reads an INI file and creates named boxes with declared images and packages.
Create distrobox.ini:
[dev-fedora]
image=fedora:latest
additional_packages="git gcc make vim tmux"
Build the environment:
distrobox assemble create --file distrobox.ini
Keep the file with your dotfiles or project documentation. Review changes like code. A fresh workstation then needs one short command to restore the environment.
Distrobox is integrated, not isolated
The official compatibility notes describe Distrobox as an integration tool rather than a sandbox. The distinction matters.
Do not run untrusted software in Distrobox and expect your files to remain protected. The default shared home gives programs broad access to your user data. Rootful containers increase the risk because container root has greater influence over the host.
Use rootless Podman or Lilipod for normal desktop work. Avoid --root unless the workload requires it and you understand the access involved.
Choose a virtual machine instead when you need:
- a separate kernel
- a strong boundary around untrusted software
- kernel module testing
- a different operating system
- isolated networking or device access
- a production server with its own lifecycle
Distrobox works best for software you trust and tasks you would otherwise run under your normal Linux account.
A practical daily workflow
Start with one box tied to a clear purpose. Name it after the job, such as python-data, rust-dev, or docs-ubuntu.
Then follow a few habits:
- Install project tools inside the box, not on the host.
- Keep source files in your normal home directory.
- Record the image and packages in
distrobox.ini. - Export only the applications and commands you use often.
- Upgrade boxes alongside your host maintenance.
- Remove old experiments after saving any needed files.
- Use a VM when the work needs real isolation.
Your host remains boring and dependable. Each project gets the distribution and package versions it needs. Rebuilding a workstation becomes easier because fewer one-off changes live in the base system.
Distrobox belongs on almost every Linux workstation. It solves package conflicts, supports immutable desktops, and keeps experiments easy to remove. You gain freedom to use another distribution without reinstalling the machine you already trust.