BoxBuddy: a GTK4 front end for Distrobox containers

A GUI over Distrobox, and what it does not include

BoxBuddy is described as an unofficial GUI for managing your Distroboxes, written with GTK4 and Libadwaita, and the readme is direct about what that means in practice: it does not come with Podman or Distrobox, and those need to be installed on the host.

That single line defines the project. BoxBuddy is not a container runtime, it is not a reimplementation of Distrobox, and it does not bundle the tools it drives. It is a front end, and the readme repeats the point in its issues section: BoxBuddy is just a GUI, the maintainer is not a developer of Distrobox itself, and any issues with created boxes are probably better logged upstream in the Distrobox repository.

The distinction matters for anyone evaluating it, because it tells you where the bugs live. If a container starts with the wrong image or a bind mount does not appear, the answer is in Distrobox, and a GUI cannot fix that. What the GUI can do is make the operations discoverable: which image, which name, which extra packages, which home directory to share, and then entering it.

The visual design follows the GNOME conventions. GTK4 with Libadwaita at version 1.4 is the stack, and the main menu screenshot in the readme is the reference for what the application looks like. The topics list the same stack, plus containers, distrobox, flatpak, podman and linux, which is a good description of the dependency surface.

The application is called BoxBuddy, and the underlying Rust crate is named boxbuddy-rs at version 0.1.0 on edition 2021. The Rust crate version is the internal one; the user-facing releases are 2.6.x, with 2.6.2 from 2026-10-02, 2.6.1 from 2026-09-05 and 2.6.0 from 2026-08-15.

Two ways to install, with different capabilities

The readme documents two installation routes, and they are not equivalent.

The first is the Flatpak, with a Flathub badge linking to the app page for io.github.dvlv.boxbuddyrs. The second is the local binary: visit the releases section, download and unzip the release, and execute the install script.

./install.sh

The important caveat comes immediately after the Flathub badge, and it is the kind of thing that decides whether the Flatpak is usable for you: the Flatpak does not have filesystem access by default, so some features are disabled. The readme points to the tips documentation for details.

This is not a BoxBuddy bug but a consequence of the Flatpak sandbox. A container manager needs to write to directories the sandbox does not expose by default, so the Flatpak either runs with reduced permissions or needs the user to grant access explicitly. The consequence is that the Flatpak build and the local binary are not the same product with a different download method, and a feature that matters to you may be present in one and missing in the other.

The local binary route avoids that entirely, at the cost of managing updates yourself and needing the system libraries the binary links against.

The repository layout supports both routes. There is a Makefile with a flatpak target that runs flatpak-builder against io.github.dvlv.boxbuddyrs.json and then builds a bundle, and the root holds the Flatpak manifest io.github.dvlv.boxbuddyrs.json alongside the desktop entry io.github.dvlv.boxbuddyrs.desktop, the GSettings schema io.github.dvlv.boxbuddyrs.gschema.xml, the compiled schema gschemas.compiled, and the appstream metadata io.github.dvlv.boxbuddyrs.metainfo.xml.

How the project is built and the Rust dependency set

The Makefile shows the development loop, and it is a small one.

The default goal is f40, which builds a release binary with cargo and runs it, with GETTEXT_SYSTEM=true set so the translation machinery links against the system gettext rather than bundling it:

GETTEXT_SYSTEM=true cargo build --release && target/release/boxbuddy-rs

The run target uses GSETTINGS_SCHEMA_DIR=. with cargo run, which points the GSettings lookup at the schema in the repository root so the settings work without installing them system-wide. The lint target is cargo fmt followed by cargo clippy. There are separate targets for the Flatpak bundle, for cleaning, for a version check through scripts/version-check.sh, and a small family of translation targets: potfile to create the translation template through scripts/create-pot.sh, translate to compile the translations with scripts/compile-translations.sh, and update-translations to run scripts/update-translations.sh.

The dependency list in the manifest is short and each entry says something about the design. libadwaita 0.7.1 with the v1_4 feature gives the GNOME widget set, and gtk4 0.9.5 with the v4_12 feature is the toolkit underneath. gettext-rs 0.7.1 with the gettext-system feature is the translation layer, and the system variant is why the build sets GETTEXT_SYSTEM=true. async-channel 2.3.1 provides the channel used to move results between the UI thread and background work, which is what lets a container operation run without freezing the window.

The one thing not in the dependency list is a container library. There is no podman API client and no distrobox crate, which confirms that the application drives the external tools rather than doing the container work itself.

Translations, the roadmap and where to report problems

The readme's help wanted section is entirely about translations, which says something about where the maintainer wants help.

The list of implemented languages is Czech, German, Greek, Spanish, French, Hindi, Italian, Dutch, Polish, Brazilian Portuguese, Russian, Ukrainian, and Chinese in both Simplified and Traditional. Any other translation is welcomed. The repository has a po/ directory for the catalogues and the Makefile targets for generating the template and compiling them, and there is separate translator documentation linked from the contributing section.

The contributing documentation is split in two: dev documentation for people working on the code, and translator documentation for people working on the translations. That split, together with a dedicated translator guide, is the sign of a project that expects more contributors than the original author.

For problems, the readme points at a roadmap file in the docs directory, so a feature request should be checked against what is already planned before being filed. And for issues with the containers themselves, the guidance is to file them in the upstream Distrobox repository rather than here.

Two other details are worth noting. There is a boxbuddy-dev-environment.ini at the root, which is presumably a devcontainer or dev environment definition for contributors, and a generated-sources.json which records where the generated files come from, useful for a project that regenerates schemas and translation artefacts as part of its build.

The documentation itself lives on GitHub Pages at dvlv.github.io/BoxBuddyRS, and the tips section there is where the Flatpak filesystem access question is answered in detail.

Where BoxBuddy is the wrong choice

The first limitation is that it needs the host tooling. Podman and Distrobox must be installed on the host, and the Flatpak build additionally has restricted filesystem access that disables some features. So for a user who wants containers without touching the command line, BoxBuddy still requires a host setup step, and for a user who cannot grant the Flatpak the access it needs, some of the application is simply out of reach.

The second is that it is explicitly unofficial and it is a GUI over someone else's tool. When something goes wrong, the maintainer is not the maintainer of Distrobox, and the readme tells you to go upstream. That is honest, and it is also a limitation: you are running a front end whose behaviour is bounded by an API you do not control, and there is no guarantee that a Distrobox change will be reflected promptly.

The third is that the scope is container management on the desktop, not orchestration. There is no indication in the readme of remote hosts, no declarative definition of a set of boxes, and no CI-oriented output. A team that wants reproducible container definitions checked into a repository is looking for something else, and the description of the project as a graphical interface makes that clear.

The fourth is that the Flatpak and the binary diverge. Because the sandbox disables features by default, a user on Flathub and a user on the local binary are running different feature sets from the same version number. When something is missing, the first question is which installation you have, and the readme does not enumerate the disabled features in the place where you would look for them.

The fifth is the crate version oddity, which is a small thing but a real signal. The Rust crate in the manifest is version 0.1.0 while the released application is at 2.6.2, and the manifest carries the comment about seeing more keys and definitions in the Cargo reference, which is what a scaffolded manifest looks like. A crate version that never moves is not a problem for a desktop application that is versioned as a whole, but it does mean the published crate metadata is not a useful indicator of anything.

Editorial conclusion

BoxBuddy fits a Linux desktop user who already runs Distrobox and wants the common operations, creating a container, entering it, managing it, reachable from a window rather than from the shell, since the project wraps the existing tooling rather than replacing it. It is the wrong choice if you want Distrobox itself, since the readme is explicit that this is only a GUI and that problems with created boxes belong upstream, and it is the wrong choice if you cannot install Podman or Distrobox on the host, because the application ships neither. Before adopting it, check whether the Flatpak's restricted filesystem access disables the features you need, note that the Flatpak path and the local binary behave differently, and consider that the last push was on 2026-10-05 with version 2.6.2 released on 2026-10-02.

Frequently asked questions

Official sources

1. Dvlv/BoxBuddyRS on GitHub
2. Issues
3. License: MIT
4. README
5. Releases