Distrobox, Toolbx, and the 'What Would You Give and What Would You Keep' Question

“What would you give and what would you keep?” — Mase, From Scratch (Double Up, 1999)

Mase asked it about rewinding your whole life and starting over. I ask it every time someone on my team picks a development container stack. Because the moment you decide to let a container be your workstation — not just hold a service, but hold your editor, your shell, your language toolchains, your AUR packages on top of a Fedora host — you’re making a series of small, ugly trade-offs. What would you give up from your bare-metal workflow, and what would you keep?

Two tools have spent the last few years competing to answer that question on Linux: Toolbx (Red Hat’s, by way of the containers/toolbox project) and Distrobox (by Luca Di Maio, upstream at 89luca89/distrobox). They sit on top of either Podman or Docker. And depending on which combination you pick, the answer to Mase’s question is meaningfully different.

What this is even for

Skip ahead if you already know. The pitch in one sentence: a dev container is a long-lived, full-distro container that shares your home directory and your display with the host, so you can run a complete Ubuntu / Arch / Alpine / OpenSUSE userland on a Fedora machine (or vice versa) without dual-booting, without a VM, and without polluting your host. You enter it, you work, you exit, your host stays clean.

The two big reasons this matters:

1. Immutable host distros. Fedora Silverblue, Kinoite, Bluefin, Bazzite, openSUSE MicroOS — these don’t want you running dnf install gcc against the root filesystem. A dev container is the official escape valve.
2. Polyglot or cross-distro work. Need RHEL 9 packaging on a Fedora 42 host? Need an Arch userland because something is only on the AUR? Want the build environment for a project locked to Ubuntu 24.04? A dev container lets you do this without the cognitive overhead of a full VM.

Toolbx, Distrobox, and the project DNA

This is where it gets political, in the polite open-source way.

Toolbx (containers/toolbox) is the Red Hat-led project. It’s written in Go, lives under the containers org alongside Podman and Buildah, and is the default tool preinstalled on Fedora Silverblue / Kinoite. It’s purpose-built for the atomic Fedora world: pull a specially-prepared fedora-toolbox image, get a CLI environment that matches your host’s userland, install whatever you need with dnf, and stop pretending the host’s rpm-ostree cares about your TypeScript compiler.

Distrobox (89luca89/distrobox) is the community project that showed up shortly after, written entirely in POSIX shell (no compiled binary), and built around a much broader thesis: any container image should be usable as a dev environment. Want Arch? distrobox create -i archlinux. Want Ubuntu 24.04? Same command, different image. Want to export the container’s code binary or its Discord .desktop entry into your host’s launcher menu? One command.

The two projects sit in a strange relationship. Distrobox is, by any honest measure, a near-superset of Toolbx today. The Toolbx maintainers have explicitly discussed merging or aligning with Distrobox upstream and there’s an open issue on the repo about it. But the projects have different audiences and different opinions about scope, so they continue to coexist.

Feature matrix, no marketing

Here’s where they actually diverge in 2026.

The honest summary: Toolbx is what’s already on your Fedora atomic desktop and it works. Distrobox is what you reach for the moment that’s not enough.

Docker or Podman underneath

Either tool runs on a container engine, and that choice matters more than the tool itself.

Podman is the obvious match. Daemonless, rootless by default, uses user_namespaces to map your host UID to root inside the container, integrates cleanly with systemd user units, and ships in the same containers/ org as Buildah and Skopeo. On Fedora it’s the out-of-box default and the path of least resistance. Toolbx literally won’t run on anything else.

Docker still works as a backend for Distrobox, and there are reasonable cases for it — most commonly that your team’s CI already runs Docker and you want one mental model. But the integration is rougher: the Docker daemon runs as root, your user needs to be in the docker group (which is effectively passwordless root on the box — this is not paranoia, it’s documented), and SELinux interplay on Fedora needs --security-opt label=disable more often than it should.

If you’re starting fresh on Linux today, use Podman. If you have an existing Docker workflow you can’t abandon, Distrobox with Docker is fine and the gap is smaller than it was three years ago.

The pros and cons, plainly

Toolbx — Pros

• Preinstalled on every Fedora atomic spin. No setup tax.
• Tighter integration with Fedora’s image stack.
• Smaller scope = fewer ways to shoot your foot.
• Backed by Red Hat engineering hours.

Toolbx — Cons

• Podman only, so if your CI is Docker-shaped, mental-model split.
• No distrobox-export-equivalent for GUI apps to host launcher.
• “Use any image” works in theory, breaks in practice on non-Fedora bases.
• Less actively expanding feature-wise.

Distrobox — Pros

• Genuinely distro-agnostic. Pick any image, it works.
• App export to host launcher is the killer feature.
• POSIX shell means it’ll run anywhere sh runs — no toolchain.
• Active community, fast feature pace.
• First-class on the Steam Deck and on Bluefin/Bazzite/uBlue variants.

Distrobox — Cons

• Not preinstalled on Silverblue / Kinoite (yet).
• More surface area = more sharp edges if you do unusual things.
• POSIX shell at scale is fragile (no static typing, no easy debug).
• Docs are good but assume you already know what you want.

Alternatives if neither fits

• Plain podman run / docker run with -v. The original pattern. Works, ugly, no app export, no init hooks. Fine for one-off experiments.
• Devcontainers (the VS Code spec). Best when your team lives in VS Code and the dev environment is per-project rather than per-machine. Different audience.
• Nix / Home Manager. Different religion entirely. No containers, just declarative package sets. Worth your time if you can pay the learning tax.
• Apptainer (née Singularity). HPC-flavored. Probably not what you want unless you’re running on a cluster.

What I actually run, and why

My host is Fedora 44 KDE (the workstation edition, not Kinoite — I have not yet committed to atomic).

• Distrobox as the front-end, Podman as the engine.
• One fedora-toolbox:44 container for general CLI work that needs to match my host’s RPM stack.
• One archlinux:latest container for anything AUR-flavored.
• One ubuntu:24.04 container for a project that’s locked to that base and isn’t worth porting.

I run Toolbx on my secondary laptop (Kinoite) because it’s already there and the workload is light enough that “good enough” wins.

What did I give up? A clean host with gcc and a hundred -devel packages installed directly. The ability to dnf install on instinct. A simpler mental model of “the machine.”

What did I keep? Reproducibility. A host that boots clean every morning. Three completely different distros’ userlands at my fingertips. The freedom to nuke ~/.local/share/containers and rebuild everything from a script in twenty minutes if I really mess it up.

Back to Mase

The question was never “Toolbx or Distrobox” or “Docker or Podman” — not really. The question is always what part of the old workflow are you actually willing to walk away from, and what are you sneaking with you into the new one.

Pick whichever combination lets you answer honestly. For most people on a Fedora desktop in 2026, the honest answer is Distrobox on Podman. For the immutable-desktop crowd on Kinoite or Silverblue who just want a CLI matching their host, Toolbx is enough.

The rest is taste. And like Mase, you’ll know what’s worth keeping the moment something tries to take it.