Rust container engine boxr beats podman by 38% in container startup benchmark

A benchmark posted on dev.to compares boxr, a young rootless container engine written in Rust, against podman on one narrow question: how fast can a container start? On the same virtual machine, boxr 0.1.44 brought up a minimal, already-cached Alpine container in a median of 134 ms, while podman 4.9.3 took a median of 217 ms — roughly 38% slower. The author documents the methodology in unusual detail and repeatedly asks readers to weigh the caveats before quoting the headline figure.

How the test was run

The workload was the simplest meaningful container operation: start a container from an already-pulled image, run true, and exit immediately. Both engines used the same image bytes — an identical Alpine config digest — and --network none. Timing was wall-clock around the full CLI invocation, which captures the latency a user actually feels, including CLI startup itself. After five cold runs per engine, the author ran 20 warm runs each, alternating engines on every iteration so that machine-load drift hit both sides equally. All 50 runs succeeded and no outliers were removed.

The warm-run numbers (20 runs per engine): boxr posted a median of 134 ms, mean of 150 ms, minimum of 107 ms and p95 of 207 ms; podman posted a median of 217 ms, mean of 225 ms, minimum of 181 ms and p95 of 288 ms. Cold runs told the same story, with medians of 128 ms for boxr and 212 ms for podman.

The environment was a 2 vCPU AMD EPYC VM with 7.7 GiB of RAM, running Ubuntu 24.04.5 on kernel 7.0.0-38-generic, with crun 1.14.1 as podman's runtime and a checksum-verified prebuilt boxr v0.1.44 binary.

The caveats that shaped the numbers

According to the dev.to post, this was not a rootless-versus-rootless comparison. The VM's own user-namespace restrictions made unprivileged user namespaces unusable, so podman ran rootful without a container user namespace while boxr ran in its --rootless mode. The author argues this flatters podman, since it skipped the user-namespace setup that boxr performed.

Networking was disabled on both sides because podman's default netavark setup could not run in the environment; boxr received --network none for symmetry. A separate measurement showed boxr's default auto mode, which sets up pasta networking, adds roughly 45 ms. Podman also needed workarounds: its storage graphroot was pointed at tmpfs so it could use native overlay with idmapped mounts, likely helping rather than hurting it, and it ran with the cgroupfs manager because no D-Bus was available.

One boxr quirk surfaced during testing: the engine does not normalize the docker.io/ registry prefix, so spelling the image docker.io/library/alpine:latest misses boxr's cache and triggers a re-pull and re-extract on every run, a penalty of about 1.7 seconds. The author worked around it and says a bug report has been filed with the maintainer.

It is also worth noting that both dev.to posts carry the same author handle, and the companion post describes the author's work building boxr's networking. The benchmark is therefore first-party rather than an independent evaluation, though the author labels speculation as speculation and argues the ~80 ms gap likely reflects architecture — podman's Go CLI shells out through conmon to crun with per-invocation configuration plumbing, while boxr is a single Rust binary with a shorter path from CLI to runtime.

What boxr actually is

The second dev.to post describes boxr as a rootless OCI engine written in Rust. Its networking supports several modes: auto, which uses pasta when installed and otherwise falls back to an embedded path called UserNet; explicit UserNet; pasta; bridge; host; and none. UserNet is an in-process Layer 2 through Layer 4 data path built on a TAP interface inside the container's network namespace, with an ARP handler for a virtual gateway and DNS resolver, ICMP echo replies, a DNS proxy over host UDP sockets, and a TCP path that tracks handshakes and sequence numbers. The author is explicit that the TCP implementation does not yet handle retransmission, window scaling, out-of-order segments or other production-grade behavior, and that boxr is labeled beta for that reason.

Why it matters

Startup latency is one of the few container-engine differences users actually feel day to day: CI steps that spin up one-shot containers, --rm helper containers in scripts, local dev loops that restart containers dozens of times daily, and scale-to-zero patterns. For long-running services, 80 ms is noise. The benchmark frames where a single-binary Rust design should win — short-lived containers — and where it matters least. The author's own list of open questions is fair: a true rootless podman run on bare metal as a non-root user, a real workload timed to first byte, cold page caches, and comparisons with Docker and nerdctl. Until those exist, the 38% figure is a promising but narrow data point, and the author invites anyone who reruns it with different results to post them in the project's GitHub discussion.