boxr ships a single-binary, rootless, daemon-free OCI container engine in Rust

A container engine as one file

boxr is an OCI container engine written in Rust that arrives as a single statically linked executable. According to a guide published on dev.to, there is no background service to configure, no package repository to add and no need for sudo: downloading the file, verifying it and placing it on your PATH is the entire setup.

The project is young. The author is upfront that boxr sits in the 0.1.x beta range, that the core workflow is dependable but that rough edges should be expected. Because going rootless relies on Linux user namespaces, the walkthrough is aimed at Linux, although the GitHub releases page also carries ARM, macOS and Windows builds alongside Debian and RPM packages.

The setup process

The dev.to guide breaks installation into five steps. First, fetch the archive for your platform from the releases page together with its checksum file. Second, confirm the download with sha256sum -c and look for an OK result — the author treats verification as important rather than optional. Third, extract the archive; the only piece that matters is bin/boxr, which is the whole engine, with an install script and shell completions alongside it.

Fourth, copy the binary somewhere your shell already searches, such as /usr/local/bin if you administer the machine or ~/.local/bin if you do not — boxr works without elevated rights, and anyone choosing the home-directory route should make sure that path is exported in their shell configuration. Fifth, run boxr --version and boxr images; an empty image table at that point is normal.

Everything boxr writes goes into ~/.boxr inside the home directory, so uninstalling means deleting the binary and that folder, and upgrading repeats the same download-verify-replace procedure. Because the executable is statically linked, the author says it should behave consistently across Linux distributions without pulling in extra dependencies.

Why no daemon changes the security story

Under Docker, the command-line client hands work to a daemon running as root, and that daemon performs the privileged operations. boxr takes a different shape: nothing keeps executing once a command finishes, the binary carries no setuid bit, and all state stays within the user's home directory. A process that appears to be root inside a container is mapped to the ordinary unprivileged host account through user namespaces, so if isolation fails, the worst case is the compromise of one user account rather than the host's superuser.

The same post previews two follow-ups: one walking through the daily commands — pull, run, ps, logs, stop, rm and rmi — and another comparing the Docker, Podman and boxr architectures. That comparison reportedly measures a median startup of 134 ms for boxr against 217 ms for Podman across 20 warm runs, with the author disclosing that both engines ran as root in the test virtual machine. These are the author's own figures, and a root-based benchmark sits oddly with a rootless-first pitch, so treat them as indicative rather than settled.

Why it matters

Most container tooling still assumes either a root-owned daemon or an admin-approved installation. An engine that runs as an unprivileged user from one file is useful wherever that assumption fails: shared hosts, hardened corporate laptops, CI runners and any environment where requesting sudo is a non-starter. It also trims the attack surface, since there is no long-lived privileged process to misconfigure or exploit, and the distribution model makes installs trivially reproducible. boxr itself is beta and unproven at scale, and Podman already popularised the daemon-free, rootless approach it follows. But a Rust implementation with this single-binary delivery is a meaningful data point for where container tooling is heading, and the project is collecting issue reports on GitHub as it stabilises.