DISTROBOX-ASSEMBLE(1)

๐Ÿ“ฆ
version 1.8.2.5 ยท 6 versions
, in alpine 3.24, arch rolling, epel 10, epel 9, fedora 43, fedora 44, nixos 26.05, nixpkgs unstable, ubuntu stonking

๐Ÿ’– distrobox-assemble(1) โ€” the User Manual, but make it cute ๐Ÿ’–

okay bestie, buckle UP, because this is distrobox-assemble from the User Manual and she is that girl. ๐Ÿฆ‹


โœจ NAME โœจ

distrobox assemble distrobox-assemble


๐ŸŒธ DESCRIPTION ๐ŸŒธ

okay so distrobox-assemble is literally the batch-queen of distrobox. She creates or destroys containers in batches, based on a manifest file. no cap. ๐Ÿ“‹โœจ

The manifest file by default is ./distrobox.ini, but you can point her at a different one with the --file flag. ๐Ÿ’…


๐ŸŽ€ SYNOPSIS ๐ŸŽ€

distrobox assemble
  • --file โ€” path or URL to the distrobox manifest/ini file ๐ŸŒˆ
  • --name, -n โ€” run against a single entry in the manifest/ini file ๐Ÿ’ซ
  • --replace, -R โ€” replace already existing distroboxes with matching names ๐Ÿ”
  • --dry-run, -d โ€” only print the container manager command generated ๐Ÿ‘€
  • --verbose, -v โ€” show more verbosity ๐Ÿ—ฃ๏ธ
  • --version, -V โ€” show version โญ

๐Ÿงš EXAMPLES ๐Ÿงš

This is an example manifest file to create two containers, and honestly? she ate. ๐Ÿ’…

[ubuntu]
additional_packages="git vim tmux nodejs"
image=ubuntu:latest
init=false
nvidia=false
pull=true
root=false
replace=true
start_now=false

# You can add comments using this #
[arch] # also inline comments are supported
additional_packages="git vim tmux nodejs"
home=/tmp/home
image=archlinux:latest
init=false
start_now=true
init_hooks="touch /init-normal"
nvidia=true
pre_init_hooks="touch /pre-init"
pull=true
root=false
replace=false
volume="/tmp/test:/run/a /tmp/test:/run/b"

๐Ÿ’œ Create

We can bring them up simply using

distrobox assemble create

If the file is called distrobox.ini and is in the same directory you're launching the command, no further arguments are needed. iconic behaviour, fr fr. ๐Ÿซถ

You can specify a custom path for the file using

distrobox assemble create --file /my/custom/path.ini

Or even specify a remote file, by using an URL:

distrobox-assemble create --file https://raw.githubusercontent.com/89luca89/dotfiles/master/distrobox.ini

๐Ÿ” Replace

By default, distrobox assemble will replace a container only if replace=true is specified in the manifest file. lowkey important, bestie.

In the example of the manifest above, the ubuntu container will always be replaced when running distrobox assemble create, while the arch container will not. ๐Ÿ’€

To force a replace for all containers in a manifest use the --replace flag

distrobox assemble create --replace [--file my/custom/path.ini]

๐Ÿ—‘๏ธ Remove

We can bring down all the containers in a manifest file by simply doing

distrobox assemble rm

Or using a custom path for the ini file

distrobox assemble rm --file my/custom/path.ini

๐Ÿ‘€ Test

You can always test what distrobox would do by using the --dry-run flag. This command will only print what commands distrobox would do without actually running them. peek before you leap, queen. ๐ŸŽ€

๐Ÿ‘ฏ Clone

Disclaimer: You need to start the container once to ensure it is fully initialized and created before cloning it. The container being copied must also be stopped before the cloning process can proceed. โœ‹๐Ÿ˜ญ

๐ŸŒˆ Available options

This is a list of available options with the corresponding type:

โญ Types legend:

  • bool: true or false
  • string: a single string, for example home="/home/luca-linux/dbox"
  • string_list: multiple strings, for example additional_packages="htop vim git". Note that string_list can be declared multiple times to be compounded:
[ubuntu]
image=ubuntu:latest
additional_packages="git vim tmux nodejs"
additional_packages="htop iftop iotop"
additional_packages="zsh fish"

๐Ÿ‘‘ The big list (flag name โ†’ type โ†’ what she does)

  • additional_flags โ€” string_list โ€” Additional flags to pass to the container manager ๐Ÿšฉ
  • additional_packages โ€” string_list โ€” Additional packages to install inside the container ๐Ÿ“ฆ
  • home โ€” string โ€” Which home directory should the container use ๐Ÿ 
  • hostname โ€” string โ€” Set hostname of the container ๐Ÿท๏ธ
  • image โ€” string โ€” Which image should the container use, look here for a list ๐Ÿ–ผ๏ธ
  • clone โ€” string โ€” Name of the Distrobox container to use as the base for a new container (the container must be stopped). ๐Ÿ‘ฏ
  • include โ€” string โ€” Name of the entry in the manifest to include in the current definition. ๐Ÿซ‚
  • init_hooks โ€” string_list โ€” Commands to run inside the container, after the packages setup ๐Ÿช
  • pre_init_hooks โ€” string_list โ€” Commands to run inside the container, before the packages setup ๐Ÿช
  • volume โ€” string_list โ€” Additional volumes to mount inside the containers ๐Ÿ’พ
  • exported_apps โ€” string_list โ€” App names or desktopfile paths to export ๐Ÿ“ค
  • exported_bins โ€” string_list โ€” Binaries to export ๐Ÿ“ค
  • exported_bins_path โ€” string โ€” Optional path where to export binaries (default: $HOME/.local/bin) ๐Ÿ“
  • entry โ€” bool โ€” Generate an entry for the container in the app list (default: false) ๐Ÿ“
  • start_now โ€” bool โ€” Start the container immediately (default: false) ๐Ÿš€
  • init โ€” bool โ€” Specify if this is an initful container (default: false) ๐ŸŒฑ
  • nvidia โ€” bool โ€” Specify if you want to enable NVidia drivers integration (default: false) ๐ŸŽฎ
  • pull โ€” bool โ€” Specify if you want to pull the image every time (default: false) โฌ‡๏ธ
  • root โ€” bool โ€” Specify if the container is rootful (default: false) ๐Ÿ‘‘
  • unshare_groups โ€” bool โ€” Specify if the container should unshare users additional groups (default: false) ๐Ÿซฅ
  • unshare_ipc โ€” bool โ€” Specify if the container should unshare the ipc namespace (default: false) ๐Ÿซฅ
  • unshare_netns โ€” bool โ€” Specify if the container should unshare the network namespace (default: false) ๐Ÿซฅ
  • unshare_process โ€” bool โ€” Specify if the container should unshare the process (pid) namespace (default: false) ๐Ÿซฅ
  • unshare_devsys โ€” bool โ€” Specify if the container should unshare /dev (default: false) ๐Ÿซฅ
  • unshare_all โ€” bool โ€” Specify if the container should unshare all the previous options (default: false) ๐Ÿซฅ

The include option copies the attributes of a definition into another one. Recursive inclusions are allowed. It operates on the manifest file and the consequent distrobox containers have no relation of any kind. ๐Ÿšซ Please be aware that attributes in the including definition will not override nor shadow the ones in the included definition, they will simply duplicate. ๐Ÿซถ

For further explanation of each of the other options in the list, take a look at the distrobox create usage, each option corresponds to one of the create flags. iykyk ๐Ÿ’…

๐Ÿ”ฅ Advanced example

              [tumbleweed_distrobox]
              image=registry.opensuse.org/opensuse/distrobox
              pull=true
              additional_packages="acpi bash-completion findutils iproute iputils sensors inotify-tools unzip"
              additional_packages="net-tools nmap openssl procps psmisc rsync man tig tmux tree vim htop xclip yt-dlp"
              additional_packages="git git-credential-libsecret"
              additional_packages="patterns-devel-base-devel_basis"
              additional_packages="ShellCheck ansible-lint clang clang-tools codespell ctags desktop-file-utils gcc golang jq python3"
              additional_packages="python3-bashate python3-flake8 python3-mypy python3-pipx python3-pycodestyle python3-pyflakes python3-pylint python3-python-lsp-server python3-rstcheck python3-yapf python3-yamllint rustup shfmt"
              additional_packages="kubernetes-client helm"
              init_hooks=GOPATH="${HOME}/.local/share/system-go" GOBIN=/usr/local/bin go install github.com/golangci/golangci-lint/cmd/golangci-lint@latest;
              init_hooks=GOPATH="${HOME}/.local/share/system-go" GOBIN=/usr/local/bin go install github.com/onsi/ginkgo/v2/ginkgo@latest;
              init_hooks=GOPATH="${HOME}/.local/share/system-go" GOBIN=/usr/local/bin go install golang.org/x/tools/cmd/goimports@latest;
              init_hooks=GOPATH="${HOME}/.local/share/system-go" GOBIN=/usr/local/bin go install golang.org/x/tools/gopls@latest;
              init_hooks=GOPATH="${HOME}/.local/share/system-go" GOBIN=/usr/local/bin go install sigs.k8s.io/kind@latest;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/conmon;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/crun;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/docker;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/docker-compose;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/flatpak;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/podman;
              init_hooks=ln -sf /usr/bin/distrobox-host-exec /usr/local/bin/xdg-open;
              exported_apps="htop"
              exported_bins="/usr/bin/htop /usr/bin/git"
              exported_bins_path="~/.local/bin"

๐Ÿงฌ Clone example ๐Ÿงฌ

like, you make one container and then a whole lil family of them that all start from the same DNA. clone= and everything else is just your own tweaks on top:

[ubuntu]
additional_packages="git vim tmux"
image=ubuntu:latest
init=false
nvidia=false
pull=true
root=false
replace=true
start_now=true

[deno_ubuntu]
clone=ubuntu
init=false
nvidia=false
pull=true
root=false
replace=true
start_now=true
pre_init_hooks=curl -fsSL https://deno.land/install.sh | sh;

[bun_ubuntu]
clone=ubuntu
init=false
nvidia=false
pull=true
root=false
replace=true
start_now=true
pre_init_hooks=curl -fsSL https://bun.sh/install | bash;

๐Ÿš Custom login shell example ๐Ÿš

want your own shell to be the one that greets you when you walk in? okay, say less:

[ubuntu]
image=ubuntu:latest
pre_init_hooks="export SHELL=/bin/bash;"

๐Ÿซ‚ Include example (inherit fields from another distrobox) ๐Ÿซ‚

include= is the "borrow your bestie's whole closet" move โ€” you inherit every field from another distrobox entry and then override whatever you want. iconic behavior, fr fr:

[ubuntu]
image=ubuntu:latest
additional_packages="git vim tmux nodejs"
additional_packages="htop iftop iotop"
additional_packages="zsh fish"

[ubuntu-nvidia]
include=ubuntu
nvidia=true
Distrobox                           Mar 2026              DISTROBOX-ASSEMBLE(1)
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
DISTROBOX(1)                      User Manual                      DISTROBOX(1)

๐ŸŒˆ COMPATIBILITY ๐ŸŒˆ

okay so this is the part where I hold your hand and tell you it's all gonna be fine ๐Ÿ’–

This project does not need a dedicated image. It can use any OCI images from docker-hub, quay.io, or any registry of your choice. literally any of them. go wild.

Many cloud images are stripped down on purpose to save size and may not include commands such as which, mount, less or vi). Additional packages can be installed once inside the container. We recommend using your preferred automation tool inside the container if you find yourself having to repeatedly create new containers. Maintaining your own custom image is also an option.

The main concern is having basic Linux utilities (mount), basic user management utilities (usermod, passwd), and sudo correctly set.


๐Ÿซถ SUPPORTED CONTAINER MANAGERS ๐Ÿซถ

distrobox can run on either podman, docker or lilipod

It depends either on podman configured in rootless mode or on docker configured without sudo (follow THESE instructions)

  • Minimum podman version: 2.1.0
  • Minimum docker client version: 19.03.15
  • Minimum lilipod version: v0.0.1

Follow the official installation guide here:


๐Ÿฆ‹ CONTAINERS DISTROS ๐Ÿฆ‹

distrobox guests tested successfully with the following container images โ€” here's the whole roster, bestie, no gatekeeping ๐Ÿ‘‘

  • AlmaLinux (Toolbox) โ€” versions: 8, 9
    • quay.io/toolbx-images/almalinux-toolbox:8
    • quay.io/toolbx-images/almalinux-toolbox:9
    • quay.io/toolbx-images/almalinux-toolbox:latest
  • Alpine (Toolbox) โ€” versions: 3.20, 3.21, 3.22, edge
    • quay.io/toolbx-images/alpine-toolbox:3.20
    • quay.io/toolbx-images/alpine-toolbox:3.21
    • quay.io/toolbx-images/alpine-toolbox:3.22
    • quay.io/toolbx-images/alpine-toolbox:edge
    • quay.io/toolbx-images/alpine-toolbox:latest
  • AmazonLinux (Toolbox) โ€” versions: 2, 2022
    • quay.io/toolbx-images/amazonlinux-toolbox:2
    • quay.io/toolbx-images/amazonlinux-toolbox:2023
    • quay.io/toolbx-images/amazonlinux-toolbox:latest
  • Archlinux (Toolbox) โ€” no version tags listed
    • quay.io/toolbx/arch-toolbox:latest
  • ALT Linux โ€” versions: p10, p11, sisyphus
    • docker.io/library/alt:p10
    • docker.io/library/alt:p11
    • docker.io/library/alt:sisyphus
  • Bazzite Arch โ€” no version tags listed
    • ghcr.io/ublue-os/bazzite-arch:latest
    • ghcr.io/ublue-os/bazzite-arch-gnome:latest
  • Centos (Toolbox) โ€” versions: stream9, stream10
    • quay.io/toolbx-images/centos-toolbox:stream9
    • quay.io/toolbx-images/centos-toolbox:stream10
    • quay.io/toolbx-images/centos-toolbox:latest
  • Debian (Toolbox) โ€” versions: 11, 12, 13, testing, unstable
    • quay.io/toolbx-images/debian-toolbox:11
    • quay.io/toolbx-images/debian-toolbox:12
    • quay.io/toolbx-images/debian-toolbox:13
    • quay.io/toolbx-images/debian-toolbox:testing
    • quay.io/toolbx-images/debian-toolbox:unstable
    • quay.io/toolbx-images/debian-toolbox:latest
  • Fedora (Toolbox) โ€” versions: 38, 39, 40, 41, 42, 43, Rawhide
    • registry.fedoraproject.org/fedora-toolbox:38
    • registry.fedoraproject.org/fedora-toolbox:39
    • registry.fedoraproject.org/fedora-toolbox:40
    • quay.io/fedora/fedora-toolbox:41
    • quay.io/fedora/fedora-toolbox:42
    • quay.io/fedora/fedora-toolbox:43
    • quay.io/fedora/fedora-toolbox:rawhide
  • openSUSE (Toolbox) โ€” no version tags listed
    • registry.opensuse.org/opensuse/distrobox:latest
  • RedHat (Toolbox) โ€” versions: 8, 9
    • registry.access.redhat.com/ubi8/toolbox
    • registry.access.redhat.com/ubi9/toolbox
  • Rocky Linux (Toolbox) โ€” versions: 8, 9
    • quay.io/toolbx-images/rockylinux-toolbox:8
    • quay.io/toolbx-images/rockylinux-toolbox:9
    • quay.io/toolbx-images/rockylinux-toolbox:latest
  • Ubuntu (Toolbox) โ€” versions: 16.04, 18.04, 20.04, 22.04, 24.04
    • quay.io/toolbx/ubuntu-toolbox:16.04
    • quay.io/toolbx/ubuntu-toolbox:18.04
    • quay.io/toolbx/ubuntu-toolbox:20.04
    • quay.io/toolbx/ubuntu-toolbox:22.04
    • quay.io/toolbx/ubuntu-toolbox:24.04
    • quay.io/toolbx/ubuntu-toolbox:latest
  • Chainguard Wolfi (Toolbox) โ€” no version tags listed
    • quay.io/toolbx-images/wolfi-toolbox:latest
  • Ublue โ€” versions: ubuntu-toolbox, fedora-toolbox, wolfi-toolbox, archlinux-distrobox
    • ghcr.io/ublue-os/ubuntu-toolbox
    • ghcr.io/ublue-os/fedora-toolbox
    • ghcr.io/ublue-os/wolfi-toolbox
    • ghcr.io/ublue-os/arch-toolbox

okay so here's the whole โœจmenuโœจ of what you can actually spin up, bestie โ€” every distro, every version tag, every image path, no skips, no cap ๐Ÿ’…

  • AlmaLinux โ€” versions 8, 8-minimal, 9 โ†’ docker.io/library/almalinux:8, docker.io/library/almalinux:9
  • Alpine Linux โ€” versions 3.20, 3.21, 3.22, edge โ†’ docker.io/library/alpine:3.20, docker.io/library/alpine:3.21, docker.io/library/alpine:3.22, docker.io/library/alpine:edge, docker.io/library/alpine:latest
  • AmazonLinux โ€” versions 1, 2, 2023 โ†’ public.ecr.aws/amazonlinux/amazonlinux:1, public.ecr.aws/amazonlinux/amazonlinux:2, public.ecr.aws/amazonlinux/amazonlinux:2023
  • Archlinux โ†’ docker.io/library/archlinux:latest
  • Blackarch โ†’ docker.io/blackarchlinux/blackarch:latest
  • CentOS Stream โ€” versions 8, 9, 10 โ†’ quay.io/centos/centos:stream8, quay.io/centos/centos:stream9, quay.io/centos/centos:stream10
  • Chainguard Wolfi โ†’ cgr.dev/chainguard/wolfi-base:latest
  • Chimera Linux โ†’ docker.io/chimeralinux/chimera:latest
  • Crystal Linux โ†’ registry.gitlab.com/crystal-linux/misc/docker:latest
  • Debian โ€” versions 7, 8, 9, 10, 11, 12, 13 โ†’ docker.io/debian/eol:wheezy, docker.io/debian/eol:buster, docker.io/debian/eol:bullseye, docker.io/library/debian:bookworm-backports, docker.io/library/debian:stable-backports
  • Debian โ€” Testing โ†’ docker.io/library/debian:testing, docker.io/library/debian:testing-backports
  • Debian โ€” Unstable โ†’ docker.io/library/debian:unstable
  • deepin โ€” 20 (apricot), 23 (beige) โ†’ docker.io/linuxdeepin/apricot, docker.io/linuxdeepin/deepin:beige
  • Fedora โ€” versions 38, 39, 40, 41, 42, 43, Rawhide โ†’ quay.io/fedora/fedora:38, quay.io/fedora/fedora:39, quay.io/fedora/fedora:40, quay.io/fedora/fedora:41, quay.io/fedora/fedora:42, quay.io/fedora/fedora:43, quay.io/fedora/fedora:rawhide
  • Gentoo Linux โ€” rolling โ†’ docker.io/gentoo/stage3:latest
  • KDE neon โ€” Latest โ†’ invent-registry.kde.org/neon/docker-images/plasma:latest
  • Kali Linux โ€” rolling โ†’ docker.io/kalilinux/kali-rolling:latest
  • Mint โ€” 22.3 โ†’ docker.io/linuxmintd/mint22.3-amd64
  • Neurodebian โ€” nd120 โ†’ docker.io/library/neurodebian:nd120
  • openSUSE โ€” Leap โ†’ registry.opensuse.org/opensuse/leap:latest
  • openSUSE โ€” Tumbleweed โ†’ registry.opensuse.org/opensuse/distrobox:latest, registry.opensuse.org/opensuse/tumbleweed:latest, registry.opensuse.org/opensuse/toolbox:latest, registry.opensuse.org/opensuse/distrobox-bpftrace:latest
  • Oracle Linux โ€” versions 8, 8-slim, 9, 9-slim, 10, 10-slim โ†’ container-registry.oracle.com/os/oraclelinux:8, container-registry.oracle.com/os/oraclelinux:8-slim, container-registry.oracle.com/os/oraclelinux:9, container-registry.oracle.com/os/oraclelinux:9-slim, container-registry.oracle.com/os/oraclelinux:10, container-registry.oracle.com/os/oraclelinux:10-slim
  • RedHat (UBI) โ€” versions 7, 8, 9 โ†’ registry.access.redhat.com/ubi7/ubi, registry.access.redhat.com/ubi8/ubi, registry.access.redhat.com/ubi8/ubi-init, registry.access.redhat.com/ubi8/ubi-minimal, registry.access.redhat.com/ubi9/ubi, registry.access.redhat.com/ubi9/ubi-init, registry.access.redhat.com/ubi9/ubi-minimal
  • Rocky Linux โ€” versions 8, 8-minimal, 9 โ†’ quay.io/rockylinux/rockylinux:8, quay.io/rockylinux/rockylinux:8-minimal, quay.io/rockylinux/rockylinux:9, quay.io/rockylinux/rockylinux:latest
  • Slackware โ†’ docker.io/vbatts/slackware:current
  • SteamOS โ†’ ghcr.io/linuxserver/steamos:latest
  • Ubuntu โ€” versions 14.04, 16.04, 18.04, 20.04, 22.04, 24.04 โ†’ docker.io/library/ubuntu:14.04, docker.io/library/ubuntu:16.04, docker.io/library/ubuntu:18.04, docker.io/library/ubuntu:20.04, docker.io/library/ubuntu:22.04, docker.io/library/ubuntu:24.04
  • Vanilla OS โ€” VSO โ†’ ghcr.io/vanilla-os/vso:main
  • Void Linux โ€” glibc, musl โ†’ ghcr.io/void-linux/void-glibc-full:latest, ghcr.io/void-linux/void-musl-full:latest

Images marked with Toolbox are tailored images made by the community efforts in toolbx-images/images, so they're more indicated for desktop use, and first setup will take less time โœจ Note however that if you use a non-toolbox preconfigured image, the first distrobox-enter you'll perform can take a while as it will download and install the missing dependencies ๐Ÿ˜ญ

A small time tax to pay for the ability to use any type of image ๐Ÿ’ธ This will not occur after the first time, subsequent enters will be much faster ๐Ÿƒโ€โ™€๏ธ๐Ÿ’จ

NixOS is not a supported container distro, and there are currently no plans to bring support to it ๐Ÿ’€ If you're looking for unprivileged NixOS environments, we suggest you look into nix-shell or nix portable.

๐ŸŒฑ NEW DISTRO SUPPORT

If your distro of choice is not on the list, open an issue requesting support for it โ€” we can work together to check if it's possible to add support for it ๐Ÿซถ

Or just try using it anyway ๐ŸŽ€ if it works, open an issue and it will be added to the list! bestie that's literally the whole vibe

๐Ÿ‘ต OLDER DISTRIBUTIONS

For older distributions like CentOS 5, CentOS 6, Debian 6, Ubuntu 12.04, compatibility is not assured ๐Ÿ™ˆ

Their libc version is incompatible with kernel releases after >=4.11 ๐Ÿ’€ A work around this is to use the vsyscall=emulate flag in the bootloader of the host ๐Ÿ› ๏ธ

Keep also in mind that mirrors could be down for such old releases, so you will need to build a custom distrobox image to ensure basic dependencies are met ๐Ÿ˜ค

๐ŸŽฎ GPU ACCELERATION SUPPORT

For Intel and AMD Gpus, the support is baked in โ€” the containers will install their latest available mesa/dri drivers ๐Ÿงš

For NVidia, you can use the --nvidia flag during create, see distrobox-create documentation to discover how to use it ๐Ÿ‘‘

Alternatively, you can use the nvidia-container-toolkit utility to set up the integration independently from the distrobox's own flag ๐Ÿ’…


Distrobox                           Mar 2026                       DISTROBOX(1)
โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€
DISTROBOX-CREATE(1)               User Manual               DISTROBOX-CREATE(1)

๐ŸŽ€ NAME

distrobox create distrobox-create

๐Ÿ’ซ DESCRIPTION

distrobox-create takes care of creating the container with input name and image โœจ The created container will be tightly integrated with the host, allowing sharing of the HOME directory of the user, external storage, external usb devices and graphical apps (X11/Wayland), and audio ๐Ÿ”Š๐Ÿฆ‹

โœจ SYNOPSIS โœจ

distrobox create

okay bestie, buckle up, this is the big one โ€” distrobox create has a lot of knobs and honestly every single one of them is here:

  • --image/-i โ€” the image you're building the container from. default: ${container_image_default} ๐Ÿ’–
  • --name/-n โ€” what you're naming the distrobox. default: ${container_name_default} ๐ŸŽ€
  • --hostname โ€” the hostname for the distrobox. default: <container-name>.$(uname -n) ๐Ÿฆ‹
  • --pull/-p โ€” pull the image even if it already exists locally (heads up: this implies --yes) ๐Ÿ”ฅ
  • --yes/-Y โ€” non-interactive mode, so it'll pull images without asking you anything ๐Ÿ™ˆ
  • --root/-r โ€” launch podman/docker/lilipod with root privileges. real talk: if you need root, this is the preferred way over "sudo distrobox". (note: if you need a program other than 'sudo' for root privileges, specify it through the DBX_SUDO_PROGRAM env variable, or the 'distrobox_sudo_program' config variable) ๐Ÿ‘‘
  • --clone/-c โ€” name of the distrobox container to use as the base for a new container. this is useful to either rename an existing distrobox or have multiple copies of the same environment. โœจ
  • --home/-H โ€” pick a custom HOME directory for the container. super useful to avoid your host's home getting littered with temp files. ๐Ÿงน
  • --volume โ€” additional volumes to add to the container ๐Ÿ“ฆ
  • --additional-flags/-a โ€” additional flags to pass to the container manager command
  • --additional-packages/-ap โ€” additional packages to install during the initial container setup ๐Ÿ“
  • --init-hooks โ€” additional commands to execute at the end of container initialization
  • --pre-init-hooks โ€” additional commands to execute at the start of container initialization
  • --init/-I โ€” use an init system (like systemd) inside the container. this makes the host's processes invisible from inside the container. (assumes --unshare-process) it may need additional packages depending on the container image: https://github.com/89luca89/distrobox/blob/main/docs/useful_tips.md#using-init-system-inside-a-distrobox ๐Ÿ’…
  • --nvidia โ€” try to integrate the host's nVidia drivers into the guest ๐ŸŒˆ
  • --platform โ€” specify which platform to use, eg: linux/arm64
  • --unshare-devsys โ€” do not share host devices and sysfs dirs from the host
  • --unshare-groups โ€” do not forward the user's additional groups into the container
  • --unshare-ipc โ€” do not share the ipc namespace with the host
  • --unshare-netns โ€” do not share the net namespace with the host
  • --unshare-process โ€” do not share the process namespace with the host
  • --unshare-all โ€” activate all the unshare flags below ๐Ÿ›ก๏ธ
  • --compatibility/-C โ€” show the list of compatible images
  • --help/-h โ€” show this message
  • --no-entry โ€” do not generate a container entry in the application list
  • --dry-run/-d โ€” only print the container manager command that gets generated
  • --verbose/-v โ€” show more verbosity ๐Ÿ”
  • --version/-V โ€” show version
  • --absolutely-disable-root-password-i-am-really-positively-sure โ€” โš ๏ธ โš ๏ธ when setting up a rootful distrobox, this will skip user password setup, leaving it blank. โš ๏ธ โš ๏ธ
no cap, that last flag is named that way on purpose. the name is doing a vibe check on you. if you type it, you meant it, and you're leaving that password blank, fr fr. ๐Ÿ˜ญ

๐ŸŒธ COMPATIBILITY ๐ŸŒธ

for a list of compatible images and container managers, please consult the man page:

man distrobox
man distrobox-compatibility

or consult the documentation page on: https://github.com/89luca89/distrobox/blob/main/docs/compatibility.md#containers-distros


๐Ÿ’– EXAMPLES ๐Ÿ’–

okay this is the part where it all clicks. here's every example, exactly as it's meant to be typed. go off:

Create a distrobox with image alpine, called my-alpine container

distrobox create --image alpine my-alpine-container

Create a distrobox from fedora-toolbox:35 image

distrobox create --image registry.fedoraproject.org/fedora-toolbox:35 --name fedora-toolbox-35

Clone an existing distrobox container

distrobox create --clone fedora-35 --name fedora-35-copy

Always pull for the new image when creating a distrobox

distrobox create --pull --image centos:stream9 --home ~/distrobox/centos9

Add additional environment variables to the container

distrobox create --image fedora:35 --name test --additional-flags "--env MY_VAR=value"

Add additional volumes to the container

distrobox create --image fedora:35 --name test --volume /opt/my-dir:/usr/local/my-dir:rw --additional-flags "--pids-limit -1"

Add additional packages to the container

distrobox create --image alpine:latest --name test2 --additional-packages "git tmux vim"

Use init-hooks to perform an action during container startup

distrobox create --image alpine:latest --name test --init-hooks "touch /var/tmp/test1 && touch /var/tmp/test2"

Use pre-init-hooks to perform an action at the beginning of the container startup (before any package manager starts)

distrobox create -i docker.io/almalinux/8-init --init --name test --pre-init-hooks "dnf config-manager --enable powertools && dnf -y install epel-release"

Use init to create a Systemd container (acts similar to an LXC):

distrobox create -i ubuntu:latest --name test --additional-packages "systemd libpam-systemd pipewire-audio-client-libraries" --init

Use init to create a OpenRC container (acts similar to an LXC):

distrobox create -i alpine:latest --name test --additional-packages "openrc" --init

Use host's NVidia drivers integration

distrobox create --image ubuntu:22.04 --name ubuntu-nvidia --nvidia

Do not use host's IP inside the container:

distrobox create --image ubuntu:latest --name test --unshare-netns

Create a more isolated container, where only the $HOME, basic sockets and host's FS (in /run/host) is shared:

distrobox create --name unshared-test --unshare-all

Create a more isolated container, with it's own init system, this will act very similar to a full LXC container:

distrobox create --name unshared-init-test --unshare-all --init --image fedora:latest

Use environment variables to specify container name, image and container manager:

DBX_CONTAINER_MANAGER="docker" DBX_NON_INTERACTIVE=1 DBX_CONTAINER_NAME=test-alpine DBX_CONTAINER_IMAGE=alpine distrobox-create
that last one is peak group-chat energy tbh โ€” set the vars, fire the command, zero flags, immaculate. ๐Ÿ’…โœจ

๐ŸŒˆ ENVIRONMENT VARIABLES ๐ŸŒˆ

these are the env vars, bestie, the whole roster:

  • DBX_CONTAINER_ALWAYS_PULL
  • DBX_CONTAINER_CUSTOM_HOME
  • DBX_CONTAINER_HOME_PREFIX
  • DBX_CONTAINER_IMAGE
  • DBX_CONTAINER_MANAGER
  • DBX_CONTAINER_NAME
  • DBX_CONTAINER_HOSTNAME
  • DBX_NON_INTERACTIVE
  • DBX_SUDO_PROGRAM

DBX_CONTAINER_HOME_PREFIX defines where containers' home directories will be located. If you define it as ~/dbx then all future containers' home directories will be ~/dbx/$container_name

so yeah, one little variable and suddenly every container gets its own lil bedroom under ~/dbx. obsessed. ๐Ÿซถ

๐ŸŒˆ EXTRA ๐ŸŒˆ

okay so bestie, the --additional-flags flag (or -a if you're feeling lazy, we love her) is literally your cheat code for tweaking the defaults during container creation ๐Ÿ’…

For example:

distrobox create -i docker.io/library/archlinux -n dev-arch

podman container inspect dev-arch | jq '.[0].HostConfig.PidsLimit'
2048

distrobox rm -f dev-arch
distrobox create -i docker.io/library/archlinux -n dev-arch --volume $CBL_TC:/tc --additional-flags "--pids-limit -1"

podman container inspect dev-arch | jq '.[0].HostConfig,.PidsLimit'
0

See how the 2048 turned into a 0? That's the glow-up โœจ

You can also add extra volumes with the --volume flag. It plays by the exact same rules as docker and podman, so the format is --volume SOURCE_PATH:DEST_PATH:MODE.

distrobox create --image docker.io/library/archlinux --name dev-arch --volume /usr/share/:/var/test:ro

And when the container gets created, you can specify (using the additional-flags) some environment variables that will persist inside the container and stay completely independent from your own environment:

distrobox create --image fedora:35 --name test --additional-flags "--env MY_VAR=value"

The --init-hooks flag is the one for adding commands to the entrypoint (that's the init) of the container. Super useful when you wanna spin up containers that already have a whole set of programs installed, or add users and groups. Iconic behavior fr fr:

distrobox create  --image fedora:35 --name test --init-hooks "dnf groupinstall -y \"C Development Tools and Libraries\""

Then there's --init, which is giving container that runs its own separate init system. Like, actual systemd inside. For example:

distrobox create -i docker.io/almalinux/8-init --init --name test
distrobox create -i docker.io/library/debian --additional-packages "systemd" --init --name test-debian

Inside the container you'll be able to use normal systemd units, no cap:

~$ distrobox enter test
user@test:~$ sudo systemctl enable --now sshd
user@test:~$ sudo systemctl status sshd
    โ— sshd.service - OpenSSH server daemon
       Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
       Active: active (running) since Fri 2022-01-28 22:54:50 CET; 17s ago
         Docs: man:sshd(8)
               man:sshd_config(5)
     Main PID: 291 (sshd)
โš ๏ธ heads up bestie: turning on --init will disable host's process integration. From inside the container you will not be able to see or manage host's processes. This is needed because /sbin/init must be pid 1. That's just how it is, no negotiating ๐Ÿซถ

And if you wanna use a non-pre-create image, you'll need to add the additional package:

distrobox create -i alpine:latest --init --additional-packages "openrc" -n test
distrobox create -i debian:stable --init --additional-packages "systemd libpam-systemd pipewire-audio-client-libraries" -n test
distrobox create -i ubuntu:22.04 --init --additional-packages "systemd libpam-systemd pipewire-audio-client-libraries" -n test
distrobox create -i archlinux:latest --init --additional-packages "systemd" -n test
distrobox create -i registry.opensuse.org/opensuse/tumbleweed:latest --init --additional-packages "systemd" -n test
distrobox create -i registry.fedoraproject.org/fedora:39 --init --additional-packages "systemd" -n test

The --init flag is for making system containers โ€” the kind where the container acts way more like a full VM than an application-container. Inside you'll have a separate init, user-session, daemons and so on. main character energy, honestly ๐Ÿ‘‘

The --home flag lets you specify a custom HOME for the container. Note that this will NOT prevent the mount of the host's home directory โ€” it just makes sure that configs and dotfiles won't litter it. We love a tidy queen ๐Ÿ’–

The --root flag will let you create a container with real root privileges. At first enter, the user will be required to setup a password. This is done in order to not enable passwordless sudo/su โ€” in a rootful container this is needed because in this mode, root inside the container is also root outside the container! Yeah. Real stakes.

๐Ÿ’€ The --absolutely-disable-root-password-i-am-really-positively-sure will skip user password setup, leaving it blank. This is genuinely dangerous and you really, positively should NOT enable this. Like, the flag name is literally begging you. Listen to her.

From version 1.4.0 of distrobox, when you create a new container, it will also generate an entry in the applications list. Slay โœจ

๐Ÿฆ‹ NVidia integration ๐Ÿฆ‹

If your host has an NVidia gpu with installed proprietary drivers, you can integrate them with the guests by using the --nvidia flag:

distrobox create --nvidia --image ubuntu:latest --name ubuntu-nvidia
๐Ÿซถ Be aware that this is not compatible with non-glibc systems and needs somewhat newer distributions to work.

This feature was tested working on:

  • Almalinux
  • Archlinux
  • Centos 7 and newer
  • Clearlinux
  • Debian 10 and newer
  • OpenSUSE Leap
  • OpenSUSE Tumbleweed
  • Rockylinux
  • Ubuntu 18.04 and newer
  • Void Linux (glibc)

Distrobox โ€” Mar 2026 โ€” DISTROBOX-CREATE(1)


๐Ÿ‘‘ DISTROBOX-ENTER(1) โ€” User Manual ๐Ÿ‘‘

๐ŸŽ€ NAME ๐ŸŽ€

distrobox enter
distrobox-enter

๐Ÿ’œ DESCRIPTION ๐Ÿ’œ

distrobox-enter is the one that takes care of entering the container with the name you specified. By default the command it executes is your SHELL, but bestie you can specify different shells, or entire commands to run. And if you're using it inside a script, an application, or a service, you can specify the --headless mode to disable tty and interactivity. Very demure, very mindful.

โœจ SYNOPSIS โœจ

distrobox enter
  • --name, -n โ€” name for the distrobox (default: my-distrobox)
  • --, -e โ€” end arguments, execute the rest as the command to execute at login (default: default ${USER}'s shell)
  • --no-tty, -T โ€” do not instantiate a tty
  • --no-workdir, -nw โ€” always start the container from the container's home directory
  • --additional-flags, -a โ€” additional flags to pass to the container manager command
  • --help, -h โ€” show this message
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. Note that if you need root this is the preferred way over "sudo distrobox" (note: if using a program other than 'sudo' for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or distrobox_sudo_program config variable)
  • --dry-run, -d โ€” only print the container manager command generated
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

๐Ÿ“ EXAMPLES ๐Ÿ“

Enter a distrobox named "example":

distrobox-enter example

Enter a distrobox while specifying a command:

distrobox-enter --name fedora-toolbox-35 -- bash -l
distrobox-enter my-alpine-container -- sh -l

Use additional podman/docker/lilipod flags while entering a distrobox:

distrobox-enter --additional-flags "--preserve-fds" --name test -- bash -l

Specify additional environment variables while entering a distrobox:

distrobox-enter --additional-flags "--env MY_VAR=value" --name test -- bash -l
MY_VAR=value distrobox-enter --additional-flags "--preserve-fds" --name test -- bash -l

You can also use environment variables to specify the container manager and the container name:

DBX_CONTAINER_MANAGER="docker" DBX_CONTAINER_NAME=test-alpine distrobox-enter

๐ŸŒธ ENVIRONMENT VARIABLES ๐ŸŒธ

  • DBX_CONTAINER_NAME
  • DBX_CONTAINER_MANAGER
  • DBX_SKIP_WORKDIR
  • DBX_SUDO_PROGRAM

๐ŸŒŸ EXTRA ๐ŸŒŸ

This command is used to enter the distrobox itself. Personally, I just create multiple profiles in my gnome-terminal to have multiple distros accessible. It's giving organized ๐Ÿ’…

The --additional-flags or -a is useful to modify the default command when executing in the container. For example:

distrobox enter -n dev-arch --additional-flags "--env my_var=test" -- printenv &| grep my_var
my_var=test

This is possible also using normal env variables:

my_var=test distrobox enter -n dev-arch --additional-flags -- printenv &| grep my_var
my_var=test

If you'd like to enter a rootful container having distrobox use a program other than sudo to run podman/docker/lilipod as root, such as pkexec or doas, you may specify it with the DBX_SUDO_PROGRAM environment variable. For example, to use doas to enter a rootful container:

DBX_SUDO_PROGRAM="doas" distrobox enter -n container --root

Additionally, in one of the config file paths that distrobox supports, such as ~/.distroboxrc, you can also append the line distrobox_sudo_program="doas" (for example) to always run distrobox commands involving rootful containers using doas.

Distrobox โ€” Mar 2026 โ€” DISTROBOX-ENTER(1)


๐Ÿฆ‹ DISTROBOX-EPHEMERAL(1) โ€” User Manual ๐Ÿฆ‹

๐ŸŽ€ NAME ๐ŸŽ€

distrobox ephemeral
distrobox-ephemeral

๐Ÿ’œ DESCRIPTION ๐Ÿ’œ

distrobox-ephemeral creates a temporary distrobox that is automatically destroyed when the command is terminated. Like, it lives fast and dies young ๐Ÿ˜ญ so iconic of her.

โœจ SYNOPSIS โœจ

distrobox ephemeral
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. Note that if you need root this is the preferred way over "sudo distrobox" (note: if using a program other than 'sudo' for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or distrobox_sudo_program config variable)
  • --verbose, -v โ€” show more verbosity
  • --help, -h โ€” show this message
  • --, -e โ€” end arguments, execute the rest as the command to execute at login (default: default ${USER}'s shell)
  • --version, -V โ€” show version

๐Ÿ“ EXAMPLES ๐Ÿ“

distrobox-ephemeral --image alpine:latest -- cat /etc/os-release
distrobox-ephemeral --root --verbose --image alpine:latest --volume /opt:/opt

You can also use flags from distrobox-create to customize the ephemeral container to run. Yes bestie, you get to decorate her before she vanishes ๐ŸŒˆ

๐ŸŒˆ SEE ALSO ๐ŸŒˆ

distrobox-create --help
man distrobox-create

๐ŸŒธ ENVIRONMENT VARIABLES ๐ŸŒธ

distrobox-ephemeral calls distrobox-create, SEE ALSO distrobox-create(1) for a list of supported environment variables to use.

Distrobox โ€” Mar 2026 โ€” DISTROBOX-EPHEMERAL(1)


โญ DISTROBOX-EXPORT(1) โ€” User Manual โญ

โœจ NAME โœจ

distrobox-export ๐Ÿ’–

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

okay so. application and binary exporting. that's the whole thing bestie ๐Ÿซถ

distrobox-export is the one that takes care of exporting an app or a binary from the container over to the host. no cap.

and once it's exported? the app is just easily available in your normal launcher, zero drama, and it will automatically be launched from the container it is exported from. it's giving seamless. it's giving you-forgot-it-was-even-in-a-container. ๐Ÿ’…โœจ

๐ŸŽ€ SYNOPSIS ๐ŸŽ€

distrobox-export
  • --app, -a โ€” name of the application to export, or an absolute path to the desktopfile to export
  • --bin, -b โ€” absolute path of the binary to export
  • --list-apps โ€” list the applications exported from this container
  • --list-binaries โ€” list the binaries exported from this container, use -ep to specify custom paths to search
  • --delete, -d โ€” delete an exported application or binary
  • --export-label, -el โ€” label to add to the exported application name. use "none" to disable. defaults to (on $container_name)
  • --export-path, -ep โ€” path where to export the binary
  • --extra-flags, -ef โ€” extra flags to add to the command
  • --enter-flags, -nf โ€” flags to add to distrobox-enter
  • --sudo, -S โ€” specify if the exported item should be run as sudo
  • --help, -h โ€” show this message
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

so like, you're probably gonna want to install graphical applications or CLI tools inside your distrobox, right? and using distrobox-export from inside the container is literally how you get to use them from the host itself. that's the whole trick. ๐Ÿช„

๐Ÿ“ EXAMPLES ๐Ÿ“

distrobox-export --app mpv [--extra-flags "flags"] [--delete] [--sudo]
distrobox-export --bin /path/to/bin [--export-path ~/.local/bin] [--extra-flags "flags"] [--delete] [--sudo]

๐ŸŒธ App export example ๐ŸŒธ

distrobox-export --app abiword

this tool will simply copy the original .desktop files along with the needed icons, add the prefix /usr/local/bin/distrobox-enter -n distrobox_name -e ... to the commands to run, and save them in your home so they can be used directly from the host as a normal app. iconic behaviour honestly. ๐Ÿ‘‘

distrobox-export --app /opt/application/my-app.desktop

this one skips the whole searching-for-the-desktopfile-in-canonical-paths situation, and just uses the file path you handed it. periodt.

๐Ÿงš Binary export example ๐Ÿงš

distrobox-export --bin /usr/bin/code --extra-flags "--foreground" --export-path $HOME/.local/bin

for binaries you have to tell it where to put the thing (--export-path), and the tool will create a little wrapper script that will distrobox-enter -e from the host for the desired binary. super handy with direnv if you wanna have different versions of the same binary based on your env or your project. iykyk ๐Ÿ’œ

the exported binaries will be exported in the โ€œโ€“export-pathโ€ of choice as a wrapper script that acts naturally both on the host and in the container. best of both worlds fr fr.

โœจ Additional flags โœจ

you can specify additional flags to add to the command! like, say you wanna export an electron app โ€” you could add the โ€œโ€“foregroundโ€ flag to the command:

distrobox-export --app atom --extra-flags "--foreground"
distrobox-export --bin /usr/bin/vim --export-path ~/.local/bin --extra-flags "-p"

this works for binaries and apps. and heads up: extra flags are only used when the exported app or binary is used from the host โ€” using them inside the container will not include them. noted. ๐Ÿ“

๐ŸŽ€ Unexport ๐ŸŽ€

the option โ€œโ€“deleteโ€ will un-export an app or binary:

distrobox-export --app atom --delete
distrobox-export --bin /usr/bin/vim --export-path ~/.local/bin --delete

๐Ÿ’œ Run as root in the container ๐Ÿ’œ

the option โ€œโ€“sudoโ€ will launch the exported item as root inside the distrobox. ๐Ÿ”ฅ

๐Ÿฆ‹ Notes ๐Ÿฆ‹

note you can use โ€“app OR โ€“bin but not together. ๐Ÿšซ

[IMAGE: app-export] app-export

NOTE: some electron apps such as vscode and atom need additional flags to work from inside the container, use the --extra-flags option to provide a series of flags, for example:
distrobox-export --app atom --extra-flags "--foreground"

Distrobox ยท Mar 2026 ยท DISTROBOX-EXPORT(1)


โœจ NAME โœจ

distrobox generate-entry ๐ŸŽ€

๐ŸŒˆ DESCRIPTION ๐ŸŒˆ

distrobox-generate-entry will create a desktop icon for one of the available distroboxes. and get this โ€” it will then be deleted when you remove the matching distrobox. self-cleaning, we love a low-maintenance icon. โœจ

๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

distrobox generate-entry
  • --help, -h โ€” show this message
  • --all, -a โ€” perform for all distroboxes
  • --delete, -d โ€” delete the entry
  • --icon, -i โ€” specify a custom icon [/path/to/icon] (default auto)
  • --root, -r โ€” perform on rootful distroboxes
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

๐Ÿ“ EXAMPLES ๐Ÿ“

generate an entry for a container:

distrobox generate-entry my-container-name

specify a custom icon for the entry:

distrobox generate-entry my-container-name --icon /path/to/icon.png

generate an entry for all distroboxes:

distrobox generate-entry --all

delete an entry:

distrobox generate-entry container-name --delete

Distrobox ยท Mar 2026 ยท DISTROBOX-GENERATE-ENTRY(1)


โœจ NAME โœจ

distrobox-host-exec ๐Ÿ’…

๐ŸŒธ DESCRIPTION ๐ŸŒธ

distrobox-host-exec lets you execute a command on the host, while you're inside of a container. yes really. reaching back out through the wall like it's nothing. ๐Ÿซถ

under the hood, distrobox-host-exec uses host-spawn, a project that lets us execute commands back on the host. if the tool is not found, the user will be prompted to install it. no silent failures here bestie. ๐Ÿ‘€

๐ŸŽ€ SYNOPSIS ๐ŸŽ€

just pass to โ€œdistrobox-host-execโ€ any command and all its arguments, if any.

  • --help, -h โ€” show this message
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version
  • --yes, -Y โ€” automatically answer yes to prompt:
    • host-spawn will be installed on the guest system if host-spawn is not detected.
    • this behaviour is default when running in a non-interactive shell.

if no command is provided, it will execute โ€œ$SHELLโ€. ๐Ÿš

alternatively, you can symlink a command name to distrobox-host-exec and then call that command by its name on the host, while inside of a container. sneaky. genius. iconic. โญ

๐Ÿ“ EXAMPLES ๐Ÿ“

๐ŸŒธ Run individual commands ๐ŸŒธ

distrobox-host-exec ls
distrobox-host-exec bash -l
distrobox-host-exec flatpak run org.mozilla.firefox
distrobox-host-exec podman ps -a

๐Ÿ’œ Drop into host shell ๐Ÿ’œ

~$: distrobox-host-exec # No command, executes "$SHELL" on the host
~$: distrobox-host-exec # This command now runs on the host
You must run  distrobox-host-exec inside a container!

๐Ÿงš Symlinking host commands ๐Ÿงš

use the host command name to create a symlink to distrobox-host-exec. you can then call the host command from within the container. ๐Ÿช„

~$: git # We do not have git in the container
bash: git: command not found
~$: sudo ln -s /usr/bin/distrobox-host-exec /usr/local/bin/git
~$: git version
git version 2.51.1

you can control podman on the host from within the container as follows:

~$: ln -s /usr/bin/distrobox-host-exec /usr/local/bin/podman
~$: ls -l /usr/local/bin/podman
lrwxrwxrwx. 1 root root 51 Jul 11 19:26 /usr/local/bin/podman -> /usr/bin/distrobox-host-exec
~$: podman version
...this is executed on host...

Distrobox ยท Mar 2026 ยท DISTROBOX-HOST-EXEC(1)


โœจ NAME โœจ

distrobox-init ๐ŸŒธ

๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

init the distrobox (not to be launched manually). okay emphasis on that, bestie. ๐Ÿ™ˆ

distrobox-init is the entrypoint of a created distrobox. note that this HAS to run from inside a distrobox โ€” it will not work if you run it from your host. hard no. ๐Ÿšซ

this is not intended to be used manually, but instead used by distrobox-create to set up the container's entrypoint. so like, it's backstage crew. still important though. ๐Ÿ’…

distrobox-init will take care of installing missing dependencies (eg. sudo), set up the user and groups, and mount directories from the host to ensure the tight integration. it does a lot actually. main character energy but behind the scenes. โœจ

๐ŸŽ€ SYNOPSIS ๐ŸŽ€

distrobox-init
  • --name, -n โ€” user name
  • --user, -u โ€” uid of the user
  • --group, -g โ€” gid of the user
  • --home, -d โ€” path/to/home of the user
  • --help, -h โ€” show this message
  • --additional-packages โ€” packages to install in addition
  • --init, -I โ€” whether to use or not init
  • --pre-init-hooks โ€” commands to execute prior to init
  • --nvidia โ€” try to integrate host's nVidia drivers in the guest
  • --upgrade, -U โ€” run init in upgrade mode
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version
  • -- โ€” end arguments execute the rest as command to execute during init

๐Ÿ“ EXAMPLES ๐Ÿ“

distrobox-init --name test-user --user 1000 --group 1000 --home /home/test-user
distrobox-init --upgrade

Distrobox ยท Mar 2026 ยท DISTROBOX-INIT(1)


โœจ NAME โœจ

distrobox list distrobox-list ๐Ÿ‘‘

๐ŸŒˆ DESCRIPTION ๐ŸŒˆ

distrobox-list lists the available distroboxes. it detects them and lists them separately from the rest of the normal containers. so your distroboxes get their own lil spotlight. as they deserve. ๐Ÿ’–

๐Ÿฆ‹ SYNOPSIS ๐Ÿฆ‹

distrobox list
  • --help, -h โ€” show this message
  • --no-color โ€” disable color formatting
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. note that if you need root this is the preferred way over "sudo distrobox" (note: if using a program other than 'sudo' for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or 'distrobox_sudo_program' config variable)
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

Distrobox ยท Mar 2026 ยท DISTROBOX-LIST(1)

๐ŸŒธ EXAMPLES ๐ŸŒธ

Okay bestie, back to distrobox-list for one sec โ€” here's how you actually run it:

distrobox-list

And you can absolutely yeet the container manager choice in through an env var, like so:

DBX_CONTAINER_MANAGER="docker" distrobox-list

๐Ÿ’– ENVIRONMENT VARIABLES ๐Ÿ’–

These are the knobs the page says you get to play with:

  • DBX_CONTAINER_MANAGER โ€” tells distrobox which container manager you're vibing with.
  • DBX_SUDO_PROGRAM โ€” the program used to get root privileges.
  • and there's an image here in the original page: [IMAGE: image] image ๐Ÿ–ผ๏ธ (yes literally, that's what it says, not me being cute)
And that's a wrap on this one โ€” source and date: Distrobox, Mar 2026, page DISTROBOX-LIST(1). ๐Ÿ’…

โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

๐Ÿ‘‘ DISTROBOX-RM(1) โ€” User Manual

NAME

distrobox rm distrobox-rm

DESCRIPTION

distrobox-rm deletes one of the available distroboxes. Gone. Poof. It's giving โœจclosureโœจ.

SYNOPSIS

distrobox rm
  • --all, -a โ€” delete all distroboxes (yes, all of them, bestie, be so serious before you type this)
  • --force, -f โ€” force deletion
  • --rm-home โ€” remove the mounted home if it differs from the host user's one
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. Note that if you need root this is the preferred way over sudo distrobox (note: if using a program other than sudo for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or distrobox_sudo_program config variable)
  • --help, -h โ€” show this message
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

EXAMPLES

distrobox-rm container-name [--force] [--all]

You can also use environment variables to specify container manager and name:

DBX_CONTAINER_MANAGER="docker" DBX_CONTAINER_NAME=test-alpine distrobox-rm

ENVIRONMENT VARIABLES

  • DBX_CONTAINER_MANAGER
  • DBX_CONTAINER_NAME
  • DBX_NON_INTERACTIVE
  • DBX_SUDO_PROGRAM
Source and date for this one: Distrobox, Mar 2026, page DISTROBOX-RM(1). ๐ŸŽ€

โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

๐Ÿฆ‹ DISTROBOX-STOP(1) โ€” User Manual

NAME

distrobox stop distrobox-stop

DESCRIPTION

distrobox-stop stops a running distrobox. ๐Ÿ›‘

Here's the lore, bestie: distroboxes are left running, even after exiting out of them, so that subsequent enters are really quick. This is how they can be stopped. No cap โ€” that's the whole reason this command exists.

SYNOPSIS

distrobox stop
  • --all, -a โ€” stop all distroboxes
  • --yes, -Y โ€” non-interactive, stop without asking
  • --help, -h โ€” show this message
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. Note that if you need root this is the preferred way over sudo distrobox (note: if using a program other than sudo for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or distrobox_sudo_program config variable)
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

EXAMPLES

distrobox-stop container-name1 container-name2
distrobox-stop container-name
distrobox-stop --all

You can also use environment variables to specify container manager and name:

DBX_CONTAINER_MANAGER="docker" DBX_CONTAINER_NAME=test-alpine distrobox-stop

ENVIRONMENT VARIABLES

  • DBX_CONTAINER_MANAGER
  • DBX_CONTAINER_NAME
  • DBX_NON_INTERACTIVE
  • DBX_SUDO_PROGRAM
Source and date, one more time: Distrobox, Mar 2026, page DISTROBOX-STOP(1). ๐ŸŒˆ

โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€โ”€

๐Ÿ”ฅ DISTROBOX-UPGRADE(1) โ€” User Manual

NAME

distrobox-upgrade

DESCRIPTION

distrobox-upgrade will enter the specified list of containers and will perform an upgrade using the container's package manager. It's the "go freshen up, bestie" command fr fr. โœจ

SYNOPSIS

distrobox upgrade
  • --help, -h โ€” show this message
  • --all, -a โ€” perform for all distroboxes
  • --running โ€” perform only for running distroboxes
  • --root, -r โ€” launch podman/docker/lilipod with root privileges. Note that if you need root this is the preferred way over sudo distrobox (note: if using a program other than sudo for root privileges is necessary, specify it through the DBX_SUDO_PROGRAM env variable, or distrobox_sudo_program config variable)
  • --verbose, -v โ€” show more verbosity
  • --version, -V โ€” show version

EXAMPLES

Upgrade all distroboxes:

distrobox-upgrade --all

Upgrade all running distroboxes:

distrobox-upgrade --all --running

Upgrade a specific distrobox:

distrobox-upgrade alpine-linux

Upgrade a list of distroboxes:

distrobox-upgrade alpine-linux ubuntu22 my-distrobox123

Automatically update all distro. ๐Ÿค–

You can create a systemd service to perform distrobox-upgrade automatically, this example shows how to run it daily:

~/.config/systemd/user/distrobox-upgrade.service

[Unit]
Description=distrobox-upgrade Automatic Update

[Service]
Type=simple
ExecStart=distrobox-upgrade --all
StandardOutput=null

~/.config/systemd/user/distrobox-upgrade.timer

[Unit]
Description=distrobox-upgrade Automatic Update Trigger

[Timer]
OnBootSec=1h
OnUnitInactiveSec=1d

[Install]
WantedBy=timers.target

Then simply do a systemctl --user daemon-reload && systemctl --user enable --now distrobox-upgrade.timer


And that's the whole page, bestie!! ๐Ÿซถ Every last option, env var, example and systemd unit accounted for, not a single crumb left behind. This came from the Distrobox source, dated Mar 2026, closing out page DISTROBOX-UPGRADE(1) โ€” the final one of the set. Go forth and upgrade your little containers, you absolute icon. ๐Ÿ‘‘๐Ÿ’œ