Fully in-browser container builds | Adolfo Ochagavía

Adolfo Ochagavía

Blog
Consulting

Fully in-browser container builds

24 May, 2026

Containers are fun. The ecosystem is incredibly open, with the internals right there for anyone to explore. Once you wrap your head around the specifications, you unlock the power to build custom tools and may even discover unexpected use cases1. Speaking of “unexpected use cases”, today I have a demo to share: a web application that builds containers right in your browser, relying only on client-side code.
Try it out
Seeing is believing, so why don’t you head to the demo and build a container? You will be able to:

Pick a base image
Specify a shell script to run upon container startup
Export the resulting image as a tar file, which you can then load into docker

Important: this is a research prototype, don’t use it for anything serious. If you need something production-ready, let’s talk.
How does it work?
Container images are just sets of files (see this article for a dissection). We can download them, unpack them, manipulate them, and repack them, all without leaving the browser! The possibilities are endless, as long as you are able to build your layers inside the browser’s sandbox.
There is little more to say, really. If you try out the demo, you will see build logs describing each build step. Also, the source code of the builder is available here, in case you are interested in the gory details.
Beyond browsers
Honestly, I think in-browser container builds are mostly a gimmick, which is probably why nobody has spent time documenting them before. The experiment is fun, though, and it serves to showcase the powers of custom container tooling.
The thing is… while custom tools are fun to develop, it is often more practical to follow the well-trodden path. Hence, we forget that custom tools can be developed at all, and we sometimes resign ourselves to the limitations of docker build and friends.
As it turns out, however, sometimes the wins unlocked by custom tools are too good to pass up. For example, in one of my recent consulting projects, we brought down image creation time to mere seconds, even for images that were multiple GiB in size! When you craft your own tools, you get to control the architecture, optimizations and caching strategies, leading to massive speedups.
So… the next time you find yourself hitting the limits of your container tools, remember that we actually have a choice. If you learn container fundamentals, you can build tools that solve your problem better than docker build ever could! Or, if you prefer, you can stick to the standard tooling, this time by conscious choice rather than by necessity.

See Building containers without Dockerfiles and Using S3 as a container registry. ↩︎

#Containers

For more articles like this, feel free to subscribe
Could you use my help? Let's collaborate

Adolfo Ochagavía explores the concept of fully in-browser container builds, highlighting the open nature of the container ecosystem and the potential for users to develop custom tools by understanding the underlying specifications. He presents a demonstration of a web application that allows users to build containers entirely in the browser using client-side code. This prototype allows users to select a base image, define a shell script to execute upon container startup, and export the resulting image as a tar file, which can subsequently be loaded into Docker. Ochagavía cautions that this is a research prototype and should not be used for serious production tasks, suggesting that for production readiness, serious consultation is required.

The underlying mechanism for these in-browser operations relies on the understanding that container images are fundamentally sets of files that can be downloaded, unpacked, manipulated, and repackaged without leaving the browser environment. This capability stems from being able to build layers within the browser's sandbox. While Ochagavía suggests that in-browser container builds function primarily as an experiment showcasing the power of custom container tooling, he acknowledges the potential of such tools. The text posits that developing custom tools can yield significant performance advantages, as demonstrated by projects where image creation time was reduced to mere seconds, even for very large images, by optimizing architecture, caching strategies, and other operational aspects.

Despite the advantages of custom tools, the author reflects that following established paths, such as utilizing standard tools like docker build, is often more practical. This leads to a philosophical consideration regarding the boundaries between experimentation and practical application in container technology. Ochagavía concludes by suggesting that mastering container fundamentals empowers individuals to create tools that surpass standard tooling when addressing specific problems, or alternatively, to consciously choose standard tooling when expediency is prioritized over deep customization. The core message is that containers can be leveraged for advanced tool development, offering alternative methods for addressing limitations encountered with conventional container systems.