When Containers Meet the Browser: Rethinking Image Builds in Pure JavaScript

Containers have long been celebrated for their openness: the OCI specification lays bare the structure of an image, and the tooling ecosystem is built on a handful of well‑understood primitives—layers, manifests, and configuration blobs. Ochagavía’s recent demo pushes this openness to an extreme by moving the entire build pipeline into the browser, relying only on client‑side code. The result is a web page where a user can select a base image, write a startup script, and download the resulting image as a tarball, ready to be loaded into any Docker daemon.

---

Core Argument: The Browser Is a Viable Build Host

The central claim of the article is that, because a container image is fundamentally a set of files, any environment capable of downloading, extracting, mutating, and re‑archiving those files can act as a builder. Modern browsers provide exactly those capabilities through a combination of fetch, WebAssembly‑based tar libraries, and the File System Access API. By leveraging the wasm‑tar and wasm‑gzip modules (see the source repository), the prototype demonstrates the full lifecycle:

1. Fetch the base image’s layer tarballs over HTTPS.
2. Decompress them in memory using a WebAssembly gzip decoder.
3. Apply a user‑supplied shell script by executing it in a sandboxed JavaScript interpreter that mimics a POSIX environment (the project uses the wasmer‑js runtime for this purpose).
4. Re‑compress the modified filesystem into a new layer.
5. Assemble a new OCI manifest and expose the final tar via a download link.

Because every step occurs in the browser’s sandbox, no server‑side resources are required beyond the static assets that host the JavaScript bundles. This eliminates the need for a build farm, reduces latency for developers experimenting with small images, and showcases how far the web platform has come in handling binary data.

---

Supporting Evidence: Speed, Simplicity, and Transparency

Ochagavía notes that in a consulting engagement he reduced image creation time to seconds, even for multi‑gigabyte images. While the demo itself is a research prototype and not tuned for production, the underlying principle holds: by customizing the build pipeline, one can bypass the overhead of Docker’s multi‑stage builds, context‑copying, and daemon communication. The prototype’s build logs, displayed in real time, illustrate how each layer is processed, offering transparency that traditional Docker builds obscure behind a monolithic CLI.

The article also references two earlier posts—Building containers without Dockerfiles and Using S3 as a container registry—which together form a small body of work demonstrating that the container ecosystem can be re‑engineered when developers understand the spec.

---

Implications: What This Means for the Future of Container Tooling

1. Empowerment through Specification Literacy – When developers internalize the OCI format, they can construct tools that fit niche performance or security requirements, such as on‑the‑fly image signing or deterministic builds that avoid Docker’s nondeterministic caching.
2. Edge‑First Build Scenarios – In environments where a full Docker daemon cannot be installed (e.g., IoT gateways, browser‑based IDEs, or CI runners with strict sandboxing), a JavaScript‑only builder can fill the gap.
3. Educational Value – A visual, interactive builder serves as a teaching aid, allowing newcomers to watch each layer being assembled and understand the impact of commands like COPY or RUN without needing a local Docker installation.
4. Potential for Distributed Build Networks – By exposing the builder as a WebAssembly module, it becomes feasible to run builds across a mesh of browsers, aggregating compute resources much like a peer‑to‑peer CDN.

---

Counter‑Perspectives: Why This May Remain a Gimmick

The author himself concedes that the approach is largely experimental. Several practical constraints limit its adoption:

• Memory Footprint – Browsers impose strict limits on heap size; building multi‑gigabyte images can cause out‑of‑memory failures.
• Performance Overheads – While WebAssembly is fast, it cannot match native file‑system I/O and compression speeds of a dedicated build server.
• Security Model – Executing arbitrary shell scripts inside the browser requires a sandboxed interpreter, which may not faithfully reproduce the behavior of a real Linux environment, leading to subtle bugs.
• Tooling Ecosystem – Docker’s ecosystem provides layers of integration (Compose, Swarm, Kubernetes) that a pure‑JS builder does not yet address.

These limitations suggest that, for now, the in‑browser builder is best suited for prototyping, education, and niche edge cases rather than as a replacement for production pipelines.

---

Conclusion: Choose Your Tools Consciously

Ochagavía’s experiment reminds us that the container toolchain is not monolithic; it is a collection of standards that can be re‑implemented in any language capable of handling binary streams. By learning the fundamentals—how layers are composed, how manifests are structured, and how caching can be customized—developers gain the agency to decide whether to rely on Docker’s convenience or to craft a bespoke solution that better serves their performance or deployment constraints.

In the end, the browser‑based builder is less a declaration that Docker is obsolete and more a proof of concept that choice exists. When the limits of existing tooling become a bottleneck, remembering that a container image is just a tarball of files may inspire the next generation of lightweight, client‑centric build tools.

---

For those interested in the implementation details, the full source code is available on GitHub: ochagavia/in-browser-container-builder.