# Boxer: turning a Dockerfile into a WebAssembly distribution

> Boxer is an open-source project that converts container images and Dockerfiles into WebAssembly based distributions called Boxes, aiming to give workloads container-like isolation with the startup speed and footprint of Wasm. It is marked as under rapid development, licensed AGPL-3.0, and ships no tagged releases.

**dphilla/boxer** — Dockerfile → Universal Wasm Distribution

- Repository: https://github.com/dphilla/boxer
- Website: https://boxer.dev
- Stars: 1,045 · Forks: 25
- Language: HTML
- License: AGPL-3.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/dphilla-boxer

## The unit of deployment changes from an image to a Box

Boxer is an open-source project designed to reimagine cloud computing by transitioning from traditional container technology to WebAssembly based distributions, known as Boxes or Wasm-Boxes. The name change is the point. A container image bundles a filesystem and a userland around a kernel that the host provides. A Box is a Wasm binary, which means the execution environment is provided by a Wasm runtime rather than by the host operating system.

The project was introduced by a talk at Wasm IO in 2025, and the recording is linked from the README. That context matters for judging the state of the work. This is a research-to-product project, and the README says plainly that the project is under rapid development. The repository has no GitHub releases, so there is no version to pin and no changelog to read, and the last push was on 2026-10-05.

The repository layout is small and tells you where the project is concentrated. There is a `box/` directory, which is presumably the tool itself, a `boxer.dev/` directory holding the site, and an `examples/` directory with three subdirectories, `examples/c/`, `examples/python/`, and `examples/ruby/`. Three languages, one C and two scripting languages, is a deliberately small set of examples chosen to show that the approach is not tied to a single toolchain.

The default branch is `dev`, which is another sign that this is pre-stabilisation work.

The licence is AGPL-3.0, and for a build tool that produces artefacts you deploy, that choice is worth examining before you build a pipeline on it.

## The argument against containers is about the kernel and the startup cost

The motivation section states the case in one paragraph, and it is a specific argument rather than a general claim about the cloud.

Containers are described as a cornerstone of cloud computing that provides isolated environments for applications, and the project lists their drawbacks. They often result in larger, less efficient deployments with slower startup times, and they rely heavily on the underlying operating system and kernel for security, which can introduce vulnerabilities and platform lock-in.

Three separate claims are bundled there, and they have different strengths. The startup-time argument is the least controversial: a container needs a process, a filesystem view, and whatever the image contains before the application does useful work, while a Wasm module can be instantiated with a much smaller amount of state. The size argument follows from the same cause. The security argument is the one that deserves the most care, because it is a trade rather than a win.

A Wasm runtime is a sandbox, and it is a smaller and more uniform one than a full operating system kernel, but a runtime is still code that has to be correct. Moving trust from the kernel to the runtime is a change of subject, not an elimination. The project's own list of advantages phrases it as memory-safe, isolated execution that is independent of the operating system, and the honest reading is that independence from the host OS is a real property, not a claim of zero attack surface.

The lock-in point is the strongest of the four. A container image is a Linux distribution, and Linux is a substantial dependency with its own version matrix, syscall surface, and behaviour differences. A Wasm module is not tied to that.

## box build is the whole conversion, and the Dockerfile is the input

The example is short enough to take in at a glance, which is the best way to understand what Boxer does. Given this Dockerfile:

```Dockerfile
FROM scratch
RUN mkdir -p /app
COPY a.out /app
WORKDIR /app
CMD ["/app/a.out"]
```

you run:

```bash
box build -f Dockerfile
```

The explanation of what happens is worth reading closely. The build brings in libc interfaces as imports and creates the necessary filesystem state, thus declaratively creating a ready-to-run Wasm binary.

That is the entire trick, and it is a clever one. A Dockerfile is already a declarative description of a filesystem, a working directory, and an entrypoint, and Boxer maps that description onto a Wasm module. The libc calls that a C program expects are not compiled in; they are supplied as Wasm imports, resolved at instantiation by whatever runtime is hosting the module. The `RUN mkdir -p /app` step becomes filesystem state baked into the Box rather than a container layer, and `CMD` becomes the entrypoint the runtime invokes.

The consequence for a user is that the Dockerfile you already have is the interface. You do not rewrite your build for a Wasm-native toolchain, you translate it. That is what makes the `examples/` directory meaningful, since it holds the same idea expressed for C, Python, and Ruby.

The `FROM scratch` line is also worth pausing on. A scratch-based Dockerfile has no shell and no package manager, which is the closest container-world equivalent of a minimal program, and it is the case where the translation to Wasm is most likely to work. A Dockerfile with a full base image and a package install step is a much harder translation, and the summary does not claim otherwise.

## The advantage list is a claim about runtimes, not about your workload

The four key advantages of WebAssembly listed in the summary each carry an assumption that is easy to miss when the list is read quickly.

Reduced overhead comes from the compact binary instruction format, which the README credits for lightweight execution and cutting down the overhead seen in traditional containers. Enhanced performance follows from that efficiency, giving smaller, more efficient deployments suited for cloud computing. Superior security comes from the memory-safe, isolated execution environment being independent of the operating system. And run almost everywhere is the claim that Wasm can run anywhere there is a WebAssembly runtime, including browsers, servers, and embedded devices, with existing runtimes available for a wide variety of architectures, which the README backs with a link to a curated list of Wasm runtimes.

The fourth is the most consequential and the most qualified. The word almost is doing real work. A Box with libc interfaces as imports needs a runtime that provides those imports, and runtimes differ in what they support, which is a compatibility question that has nothing to do with Wasm's portability in principle. A module that runs on a browser is not automatically runnable on a minimal server runtime, and neither is automatically runnable on an embedded device with a few hundred kilobytes of memory.

So the portability claim is about the format, and the practical portability is about the runtime you choose and what your program actually asks for. The examples directory, with C, Python, and Ruby, is the natural place to look for how much of a language runtime you need to bring along before a Box is usable.

## How Boxer compares with running the container unchanged

The alternative to Boxer is straightforward and needs no advocacy against containers to be a fair comparison. You keep the Dockerfile, you build the image, you run the image, and you get the same workload running today on any machine with a container runtime.

The difference in approach is where the isolation boundary sits. A container delegates isolation to the host kernel through kernel namespaces and cgroups, and the workload shares the kernel with everything else on the host. A Box delegates isolation to a Wasm runtime that implements the sandbox itself, and the module sees only the imports the runtime chose to give it. That is a genuinely different structure, not a faster version of the same one, and it is why the project's list of advantages emphasises independence from the operating system alongside performance.

The trade is that the WebAssembly path constrains what the workload can do. A program that opens a socket, reads a file, or calls into a native library needs those capabilities provided by the runtime as imports, and a runtime that does not offer them cannot run the program. The libc import mechanism in the example is exactly the boundary where that negotiation happens. A container has the opposite property: nearly anything a program can do on Linux works, because it is Linux.

So the honest framing is that Boxer is a different isolation contract with a different compatibility surface. For a self-contained service that talks to the network and does computation, the Wasm contract is often a good fit. For a program that depends on the depth of the Linux userland, it is not, and the container path is not the legacy option but the correct one.

## What to check before betting on an AGPL build tool

There are practical cautions, and they are the ordinary ones for adopting a young infrastructure project, multiplied by the licence.

The first is the absence of releases. With no GitHub releases, no version to pin, and the default branch named `dev`, a Box you build today is not reproducible from a tag later. If you need reproducibility, capture the tool version and the Box artefact itself, because the tool can change under you without a version number telling you.

The second is the rapid development warning in the README, which is a plain statement that interfaces and behaviour may change. Plan for that by wrapping Boxer in your own pipeline layer rather than calling it directly from every build.

The third is the scope of the examples. Three languages, one of them C, tells you what has been demonstrated. If your workload is in a language or uses a system capability not represented there, the translation from Dockerfile to Box is where the work will land, and it will land on you rather than on the tool.

The fourth is AGPL-3.0. The tool is the point at which the licence question bites, because a build tool that produces artefacts you distribute is different from a library you link. The AGPL's network clause is what makes it unusual among build tools, and whether it applies to your use depends on how the tool is deployed and whether you distribute the result. This is a question for whoever handles licensing in your organisation rather than something to guess at, but the answer should exist before the tool is in a release pipeline rather than after.

Finally, the site directory named `boxer.dev/` tells you the project is still being shaped as a product, and the homepage is boxer.dev. Documentation for a tool at this stage tends to live in the repository rather than in a manual, which means the README and the examples directory are the documentation.

## Conclusion

Boxer fits a team that already has a Dockerfile and wants to try running the same workload as a Wasm module on a runtime that is not a full operating system, and it is not a container replacement for production today, since the project itself says it is under rapid development and publishes no tagged releases. Before you build on it, check three things: that your workload only touches libc-level interfaces Boxer can supply as imports, that you can live with AGPL-3.0 for the tooling you adopt, and that the Wasm runtime you intend to run the resulting Box on actually supports the interfaces your program needs, since the project claims near-universal deployability rather than universal compatibility.

## FAQ

### What is Boxer and what does it convert?

Boxer is an open-source project that converts existing containerised workloads and definitions into near-universally deployable WebAssembly distributions called Boxes. It provides tooling for turning a Dockerfile into a ready-to-run Wasm binary, and the examples directory holds C, Python, and Ruby builds.

### How do I build a Box from a Dockerfile?

The command is `box build -f Dockerfile`. Boxer brings in libc interfaces as imports and creates the necessary filesystem state, so the result is a ready-to-run Wasm binary rather than a container image.

### What are the stated advantages of WebAssembly over containers in Boxer?

The project lists reduced overhead from the compact binary instruction format, improved performance and smaller deployments, a memory-safe isolated execution environment that is independent of the operating system, and the ability to run almost anywhere there is a WebAssembly runtime, including browsers, servers, and embedded devices.

### Is Boxer stable and released?

The project summary states that it is under rapid development, the repository has no GitHub releases, and the default branch is `dev`. The last push to the repository was on 2026-10-05, and the licence is AGPL-3.0.

## Sources

- [dphilla/boxer on GitHub](https://github.com/dphilla/boxer)
- [Issues](https://github.com/dphilla/boxer/issues)
- [License: AGPL-3.0](https://github.com/dphilla/boxer/blob/dev/LICENSE)
- [Project website](https://boxer.dev)
- [README](https://github.com/dphilla/boxer/blob/dev/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dphilla-boxer