DEV Community: Ryo Tanaka

I benchmarked boxr vs podman on container startup. Here are the honest numbers.

Ryo Tanaka — Sat, 26 Sep 2026 05:54:02 +0000

TL;DR: On the same VM, starting a minimal cached container 20 times each: boxr 0.1.44 median 134 ms, podman 4.9.3 median 217 ms. boxr was ~38% faster on median startup. The full methodology and every caveat are below — please read them before quoting these numbers, because the caveats matter more than the headline.

What I measured

The simplest meaningful container operation: start a container from an already-pulled image and exit immediately.

boxr: boxr run --rootless --rm --network none library/alpine:latest true
podman: podman run --rm --network none docker.io/library/alpine:latest true

Same image bytes on both sides (alpine, identical config digest sha256:320994c3…). Wall-clock time measured with date +%s%N around the full CLI invocation — that's the cost a user actually feels, including CLI startup. Five cold runs per engine, then 20 warm runs each, alternating boxr/podman per iteration so any drift in machine load hits both equally. Zero failed runs out of 50, and I kept every data point — no outliers removed.

Warm results (n=20 each):

	median	mean	min	max	p95
boxr 0.1.44	134 ms	150 ms	107 ms	262 ms	207 ms
podman 4.9.3	217 ms	225 ms	181 ms	310 ms	288 ms

Cold runs (first 5 invocations, image already pulled): boxr median 128 ms, podman median 212 ms — same story.

Environment: 2 vCPU (AMD EPYC 9D64), 7.7 GiB RAM, Ubuntu 24.04.5, kernel 7.0.0-38-generic. boxr was the prebuilt v0.1.44 Linux x86_64 release binary (checksum-verified). Podman came from Ubuntu's packages with crun 1.14.1.

The caveats (please don't skip these)

This is not a "rootless podman" measurement. I wanted both engines rootless, but this VM is itself a user-namespaced container with restrictions that made unprivileged user namespaces unusable (unprivileged uid_map writes fail, and setuid helpers can't elevate under the inherited no-new-privs flag — I verified this several ways before giving up). So both engines ran as root. boxr ran in its --rootless mode; podman ran rootful, without a container user namespace. If anything, that flatters podman: it skipped the user-namespace setup that boxr performed.

Networking was disabled on both sides. Podman's default netavark networking physically cannot run in this environment (setns: Operation not permitted), so podman required --network none. I gave boxr --network none too, for symmetry — its default auto mode sets up pasta networking and I measured that at roughly +45 ms. So: this compares engine + runtime startup, not network-stack setup.

Podman needed environment workarounds. Default podman storage chose fuse-overlayfs (no /dev/fuse here), so I pointed its graphroot at tmpfs, which lets it use native overlay with idmapped mounts — that likely helped podman, not hurt it. I also used --cgroup-manager=cgroupfs because there's no D-Bus here.

One VM, one image, one workload. n=20 is enough to see the gap is real (the distributions barely overlap — boxr's max warm run was 262 ms, podman's min was 181 ms), but it's still one machine and true is the most trivial workload possible. Real workloads with volume mounts, port publishing, and actual processes will look different.

A boxr quirk I had to work around: boxr doesn't normalize the docker.io/ registry prefix, so docker.io/library/alpine:latest misses its image cache and re-pulls + re-extracts on every run (~1.7 s penalty each time). I used the library/alpine:latest spelling boxr's cache recognizes. Same image, but worth knowing — I've written it up as a bug report for the maintainer to review.

What I think the numbers mean (speculation — labeled as such)

Speculation starts here. The ~80 ms gap is consistent with architectural differences rather than tuning: podman is a Go CLI that shells out through conmon to crun with a fair amount of configuration plumbing per invocation, while boxr is a single Rust binary with a shorter path from CLI to runtime. I'd guess CLI startup + per-run setup dominates at this scale, not the OCI runtime itself (both ultimately drive containers the same way).

What would change the picture: a heavier workload would shrink the relative gap (fixed startup cost amortized over real work); podman's daemonless-but-heavier CLI is a per-invocation tax, so short-lived containers are exactly where boxr's design should win and long-running ones where it matters least. I haven't measured any of that — it's inference, not data.

Where startup latency actually matters (and where it doesn't)

For long-running services, 80 ms is noise — nobody picks a container engine over a tenth of a second at deploy time. Startup latency matters in a narrower but real set of cases: CI jobs that spin up one-shot containers per test step, --rm helper containers in scripts, local dev loops where you restart a container dozens of times a day, and anything resembling scale-to-zero. If your containers live for hours, stop reading and go tune something else. If you launch hundreds of short-lived ones a day, per-invocation overhead is one of the few engine differences you'll actually feel.

What I'd measure next

This benchmark answered one narrow question. The honest follow-ups, in order of how much they'd change my confidence:

As a non-root user. The single biggest gap in this data. True rootless podman (user namespaces, pasta/slirp networking, fuse-overlayfs) has a meaningfully different startup path than the rootful podman I could run here. If someone reruns this on bare metal as an unprivileged user, that's the comparison I actually wanted.
A real workload. true measures engine overhead and nothing else. Next step up: a container that starts a web server and serves one request, timed to first byte. That folds in network setup — where the engines genuinely differ — instead of excluding it.
Cold page cache. Everything here was page-cache warm. Dropping caches between runs (echo 3 > /proc/sys/vm/drop_caches) would show the storage-driver side of the story.
More engines. Docker and nerdctl belong in this comparison before any strong claims.

Reproduce it

Pull alpine once in each engine, then time run --rm <image> true in a loop, alternating engines. If you run this on your own machine — especially as a non-root user, which I couldn't do here — I'd genuinely like to see your numbers. The methodology that matters: same image digest, warmed cache, no cherry-picking, report the setup you actually used.

Run Your First Rootless Container with Boxr (No Daemon, No sudo)

Ryo Tanaka — Sat, 26 Sep 2026 05:35:38 +0000

Run an nginx container as an unprivileged user — no daemon, no sudo — and understand what boxr does differently under the hood.

If you know docker run -p 8080:80 nginx, you already know 90% of boxr. Boxr is an OCI container engine written in Rust that runs containers rootless by default: there is no root-owned daemon sitting in the background, no sudo in front of every command, and no setuid helper binaries. Your unprivileged user creates a Linux user namespace, maps the container's root user (UID 0) to your own UID, and the container runs as you.

This is a hands-on tutorial. In about ten minutes you will install boxr, run nginx as a non-root user, look at how the isolation works, switch network modes, exec into the container, and clean up. Boxr is beta software in the 0.1.x series, so expect rough edges — but the core workflow will feel familiar.

What you need

A Linux machine. Rootless containers depend on Linux user namespaces (CLONE_NEWUSER), so this walkthrough is Linux-only. Most mainstream distributions (Ubuntu, Fedora, Debian) enable user namespaces out of the box. Boxr reads /etc/subuid and /etc/subgid to map a range of subordinate user IDs into the container — on a typical single-user workstation those entries already exist for your account.

Install

Two straightforward paths, both documented in the repo README:

Homebrew (Linux or macOS):

brew tap kchaitanya863/tap
brew install boxr

From source with the installer script:

curl -fsSL https://raw.githubusercontent.com/kchaitanya863/boxr/main/install.sh | sh

The script builds boxr with cargo and installs the binary to ~/.boxr/bin — make sure that directory is on your PATH. If you prefer to build by hand, clone the repo and run cargo build --release; the binary lands at target/release/boxr. Native .deb / .rpm packages and Windows builds are also published on the project's release pages.

Verify the install:

boxr --version

Run your first container

boxr run -d --name web -p 8080:80 nginx:latest

Every flag here translates directly from Docker: -d detaches the container into the background, --name web gives it a name, and -p 8080:80 publishes the container's port 80 on host port 8080. Boxr pulls nginx:latest from the registry on first use, exactly like you'd expect.

Confirm it's serving:

curl -s http://localhost:8080 | head -5

You should see the top of nginx's welcome page. Two more commands worth knowing immediately:

boxr ps
boxr logs web

boxr ps lists running containers (it's an alias — boxr ls works too), and boxr logs web streams the container's stdout, which for nginx shows its startup lines.

What "rootless" means here

With Docker, your CLI talks to a root-owned daemon that does the privileged work. Boxr has no daemon. When you run the command above, the boxr process itself:

Forks a small single-threaded helper before its async runtime starts. This matters because the kernel refuses unshare(CLONE_NEWUSER) from a multi-threaded process, so boxr does the namespace setup in a clean one-thread child (the codebase calls this the trampoline).
The child unshares a user namespace; the parent writes your UID and GID mappings for the child's PID.
Inside the namespace, the container's UID 0 is mapped to your unprivileged UID on the host.

The mapping looks like this:

inside the container              on the host
UID 0 (root)            <-->      UID 1000 (you)
UID 1..65536            <-->      100000..165535 (your subuid range)

Everything the container does as "root" is, from the host's perspective, just you. A container escape doesn't hand over host root — it hands over your user account, which is a much smaller blast radius. Port publishing works without privileges too: boxr runs a user-space TCP proxy that forwards host port 8080 into the container's network namespace, so binding low or high ports never needs CAP_NET_BIND_SERVICE.

One practical consequence you'll notice with bind mounts: files the container writes as root show up on the host owned by your user, not by root. That makes this behave sanely:

mkdir -p ~/boxr-data
boxr run -d --name files -v ~/boxr-data:/data:rw alpine sleep 3600
boxr exec files sh -c "echo hello > /data/greeting.txt"
cat ~/boxr-data/greeting.txt
boxr stop files && boxr rm files

No sudo chown dance afterwards.

Choose a network mode

The --network flag (default: auto) controls the container's network setup. These are the real mode names from boxr's source:

auto — the default. Uses pasta when the pasta binary is found on your system; without pasta installed, the container runs without an isolated network namespace. If you want the embedded stack for certain, name it explicitly.
usernet — boxr's embedded pure-Rust user-mode TCP/IP stack: a TAP device inside the container's network namespace, with ARP, DNS, and TCP handled in-process. Zero external dependencies.
pasta — the external passt/pasta rootless networking driver, attached to the container's network namespace. Requires the pasta binary on your PATH.
bridge — a boxr-managed bridge network with IPAM address allocation.
host — no network isolation; the container shares the host's network namespace.
none — an isolated network namespace with loopback only.

Try the embedded stack explicitly — it's the most interesting thing boxr does:

boxr run -d --name web-usernet --network usernet -p 8081:80 nginx:latest
curl -s http://localhost:8081 | head -3

Same nginx, but now every packet crosses a Rust TCP/IP implementation running inside the boxr process: Ethernet frames read from a TAP device, ARP and DNS answered by an in-memory engine, TCP proxied out through ordinary host sockets. If you want the full design — the five-stage packet path, the checksum discipline, and the honest list of what the TCP state machine doesn't do yet — that's covered in the deep-dive linked at the bottom.

Exec into the container

boxr exec web-usernet cat /etc/os-release

boxr exec runs a command inside a running container, the same shape as docker exec. Try poking around: boxr exec web-usernet ls /usr/share/nginx/html shows the files nginx is serving, and boxr top web-usernet lists the processes running in the container.

Troubleshooting the common bumps

operation not permitted when running a container. User namespaces are disabled or restricted. On Debian/Ubuntu check sysctl kernel.unprivileged_userns_clone — it should be 1. Some hardened kernels and containers-within-containers block CLONE_NEWUSER entirely.

Errors about UID/GID mapping. Your user needs a subordinate ID range. Check that /etc/subuid and /etc/subgid contain a line for your username (e.g. you:100000:65536). Most desktop distros create these at install time.

--network auto behaves like host networking. Pasta isn't installed, so auto didn't isolate the network namespace. Either install pasta or pass --network usernet explicitly.

Port already allocated. Another process owns the host port. Pick a free one — -p 8082:80 — and move on.

Clean up

boxr stop web web-usernet
boxr rm web web-usernet
boxr ps

boxr stop halts the containers, boxr rm removes them, and the final boxr ps should show an empty list.

Where to go next

That's the whole loop: install, run, inspect, exec, remove — all as an unprivileged user. From here, the natural next steps are boxr build (Dockerfile-compatible image builds), boxr compose (multi-container apps from a compose file), and boxr volume / boxr network for persistent state and custom networks. The full command reference lives in the repo.

Repository: https://github.com/kchaitanya863/boxr — README, architecture docs, and the CLI reference.
Deep-dive: Why I Put a TCP/IP Stack Inside a Rootless Container Engine — https://dev.to/ryo_tanaka_dev/why-i-put-a-tcpip-stack-inside-a-rootless-container-engine-8c — the UserNet design this tutorial only skimmed.
Discussions: https://github.com/kchaitanya863/boxr/discussions — design threads and Q&A. Boxr is beta and single-maintainer, and the most useful thing you can do after this tutorial is run something unusual in it and report what breaks.

Why I Put a TCP/IP Stack Inside a Rootless Container Engine

Ryo Tanaka — Sat, 26 Sep 2026 05:13:48 +0000

Inside Boxr’s pure-Rust UserNet: TAP frames, ARP, DNS, TCP proxying, and the trade-offs that keep it beta.

Rootless containers have a networking problem that looks simple until you follow the packet.

Creating an isolated network namespace is only the first step. The application inside the container still expects DNS, outbound TCP, port forwarding, and behavior close enough to a normal Linux host that tools such as curl or a package manager do not care how the connection was built. Meanwhile, the runtime cannot rely on host root privileges to create and configure everything the traditional way.

The common answer is a separate user-mode networking helper. That is a good answer, and mature tools have earned their place. But while building Boxr, a rootless Open Container Initiative (OCI) engine written in Rust, I wanted to explore a second path: could the runtime carry a small, understandable networking path inside its own binary?

That experiment became UserNet, an embedded Layer 2 through Layer 4 data path written in Rust. It is not a claim that a young implementation can replace every mature networking tool. It is a working fallback, a learning surface, and one of the most interesting pieces of Boxr to review.

Rootless containers still need a way out

Inside a private network namespace, a process can have its own interfaces, routes, and loopback device. That isolation is valuable, but it also cuts the process off from the host network.

A rootful runtime can create bridges, virtual Ethernet pairs, routing rules, and network address translation with host-level capabilities. A rootless runtime has to work within a tighter boundary. It needs to translate traffic without assuming it can reconfigure the host.

Boxr exposes several network modes because there is no single correct answer for every machine:

Auto uses pasta when it is installed, then falls back to UserNet.

UserNet selects the embedded Rust path explicitly.

Pasta uses the external rootless networking driver.

Bridge, host, and none support their expected isolation and connectivity models.

That ordering is deliberate. Shipping an embedded fallback makes a minimal installation useful, while keeping pasta available recognizes the value of a mature implementation. Engineering is usually better when “built here” does not become “must be used everywhere.”

A packet crosses five explicit stages

UserNet begins with a TAP interface inside the container’s network namespace. From the application’s point of view, it is using normal POSIX sockets and a normal Linux network stack. The Linux stack emits Ethernet frames through the TAP device, and Boxr reads those frames in user space.

The outbound path is:

Container application -> POSIX socket -> Linux network stack in the container namespace -> TAP interface (eth0) -> Boxr UserNet -> ordinary host UDP or TCP socket -> destination

The return path runs in reverse. Boxr receives bytes from a host socket, builds the protocol headers the container expects, computes checksums, wraps the packet in an Ethernet frame, and writes it back to TAP.

The implementation keeps the layers visible rather than hiding them behind a large abstraction. Ethernet parsing chooses between Address Resolution Protocol (ARP) and IPv4. IPv4 parsing then dispatches Internet Control Message Protocol (ICMP), User Datagram Protocol (UDP), or Transmission Control Protocol (TCP). That directness makes the code approachable, but it also makes every protocol assumption visible—and reviewable.

The small protocols are where trust begins

Before TCP can work, the container has to believe there is a network on the other side of its interface.

UserNet gives the container a small virtual network: the documented defaults use 10.0.2.15 for the container, 10.0.2.2 for the gateway, and 10.0.2.3 for DNS. When the container asks who owns the gateway or DNS address, the ARP handler returns a virtual gateway Media Access Control (MAC) address.

IPv4 handling validates the header shape and calculates the standard one’s-complement checksum for generated packets. ICMP echo requests to the virtual gateway receive matching echo replies. These pieces are small, but they matter: if ARP, lengths, byte order, or checksums are wrong, the higher layers fail in ways that are difficult to diagnose from inside the container.

DNS adds a more practical bridge. UserNet intercepts UDP queries sent to the virtual DNS address, forwards them through a host UDP socket to a resolver, then packages the response as UDP over IPv4 over Ethernet for the container. The application sees a DNS server. The host sees an ordinary UDP client. Boxr owns the translation between them.

This is also where defensive parsing becomes essential. The input is a byte slice, not a trusted Rust object. Every header needs length checks before fields are read. Declared payload lengths have to be bounded by the bytes actually received. Checksums must be generated over exactly the right pseudo-header and payload. Rust removes broad classes of memory errors, but it does not make protocol logic correct by itself.

TCP is the part that keeps the project honest

ARP, ICMP, and a DNS proxy are finite enough to explain in a few paragraphs. TCP is where the state space expands.

The current UserNet path recognizes connection setup and teardown flags, tracks sequence and acknowledgment numbers, opens unprivileged host TCP sockets for outbound destinations, and translates response data back into packets for the container. That is enough to demonstrate the architecture and exercise real traffic paths.

It is not the same as claiming a production-grade, general-purpose TCP implementation.

Real TCP behavior includes retransmission, duplicate acknowledgments, out-of-order segments, window scaling, backpressure, half-closed connections, resets, timing behavior, long-lived streams, and resource cleanup under failure. A happy-path handshake is the beginning of the work, not the end.

That is why Boxr is labeled beta. The most valuable review is not “nice project.” It is a packet trace that shows the state machine made the wrong choice, a reproducible teardown failure, a malformed frame that escapes a boundary check, or a workload that exposes blocking behavior.

I would rather make the boundary explicit than hide it behind the phrase “TCP/IP stack.” UserNet is useful today as an embedded path and a testable architecture. It still needs adversarial protocol review and sustained real-world use before anyone should treat it as mature network infrastructure.

In-process networking trades isolation for simplicity

Moving the networking path into the Boxr process changes the shape of the system.

The benefits are tangible:

One implementation language. Packet parsing, container lifecycle, and the surrounding runtime are all Rust.

A smaller installation surface. UserNet does not require an additional networking binary to exist on the machine.

A direct lifecycle. The engine owns the TAP loop and can stop it with the container.

An inspectable data path. A contributor can follow a frame from Ethernet parsing to a host socket without crossing a foreign-function boundary.

But “in process” is not automatically safer. A separate helper creates another component and another lifecycle to manage, yet it also creates a process boundary. With an embedded stack, packet parsing and the container engine share a fault domain. A panic, logic flaw, or resource-exhaustion bug can affect more of the runtime.

So the security question is not “Rust or C?” It is: what inputs cross the boundary, what privileges does each component hold, what happens on failure, and which design can be tested and maintained well enough for the intended threat model?

Boxr’s auto mode reflects that trade-off. It uses pasta when available and keeps UserNet as a zero-extra-dependency fallback. The goal is not purity. The goal is a rootless container that can reach the network while the architecture remains honest about its maturity.

The fastest path forward is to break it usefully

If you want to inspect the idea, the repository documents a direct UserNet path:

git clone https://github.com/kchaitanya863/boxr
cd boxr
cargo build --release
./target/release/boxr run --network usernet -p 8080:80 nginx:latest

Rootless networking depends on the host environment, including Linux user-namespace support and access to /dev/net/tun, so the most useful reports include the kernel, distribution, architecture, exact command, logs, and a minimal reproducer. A short packet capture is even better when the failure is in the data path.

The project recently shipped v0.1.44, which included Linux build and exec user-namespace fixes alongside refreshed launch assets. Boxr remains a young, single-maintainer beta, and that is precisely why focused contributors can have disproportionate impact now.

Three areas would benefit most from experienced eyes:

TCP behavior under unhappy paths. Retransmission, teardown, long-lived connections, and sequence handling deserve adversarial tests.

Isolation boundaries. Is an in-process stack the right fault domain, or should the design preserve the same Rust implementation behind a process boundary?

Packet-loop architecture. The current path is easy to understand; the next challenge is concurrency and throughput without making correctness impossible to reason about.

If those problems sound interesting, read the networking architecture, join the design discussion, or open an issue with a workload that fails. If Boxr runs on your setup, report that too—the boring compatibility matrix is what turns an experiment into infrastructure.

And if you want to follow a Rust container engine while the core design is still moving, star Boxr on GitHub. The next useful contribution might be a protocol test, a packet trace, or one carefully argued “this boundary should be somewhere else.”