Distrobox
Another distribution's tooling on your machine, sharing your home directory
Distrobox runs any Linux distribution's userspace in a container deliberately fused to your host rather than walled off from it: the same home directory, the same devices, the same display. It is the usual answer on an immutable system or a locked down work laptop. It is explicitly not a sandbox, and the project says so itself.
Integration is the point, and isolation is the thing it gives up
A container here is not a box you push things into. It mounts your real home directory, reaches your display and audio, sees your devices and can run commands back on the host, and an application installed inside it can be exported so it shows up in the host's normal menu. The result feels less like a container and more like having a second distribution's package manager available.
The documentation is unusually honest that this is a trade rather than a free win, stating that sandboxing is not an aim and that you should not expect the isolation a plain container or a Flatpak gives you. Take that literally. Anything you would hesitate to run as yourself belongs somewhere else, because this has your whole home directory.
It is mid rewrite, and the version to run is the old one
The project is moving from its original shell implementation to a single Go binary. The Go line is still a release candidate, the shell line remains what the install script recommends for production, and both are frozen to bugfixes until the rewrite reaches parity, with no committed date for that.
None of this makes it a bad bet, since it ships in the default repositories of most major distributions and comes preinstalled on several immutable ones. It does mean you should install it from your distribution rather than from a script you found, and expect exported applications to need redoing when the new line lands.
Reach for it when
- you run an immutable or atomic system and need somewhere mutable for ordinary packages
- your work laptop is locked down and you want an environment you control without asking for root
- you want a deliberately stable base with a bleeding edge toolchain on top of it
Watch out for
- it is not a sandbox and does not try to be, so it is the wrong tool for anything you would not already run as yourself
- with docker as the backend the container runs as root, and root inside it can change things outside it
- turning on systemd inside a container switches off the host process integration that was the reason to use it
- the Go rewrite is still a release candidate while the shell line is what is recommended, and both are frozen to bugfixes
- Nvidia needs an explicit flag or a separately configured toolkit, and on macOS it is command line only
Compare with these
- Dev environmentsFree
Omarchy
An Arch based distribution where the whole desktop is already decided
- linux
- arch
- hyprland
MITRead - Dev environmentsFree
NixOS
The whole machine as one config file, with a boot menu full of undo
- linux
- nix
- declarative
MIT for Nixpkgs, LGPL-2.1 for the Nix package managerRead - Dev environmentsFree
Devbox
Per project shells with Nix underneath and no Nix language to learn
- nix
- reproducible
- cli
Apache-2.0Read