Why We Built StableBuild: When Unchanged Code Stops Building

By Mariku Kimoto, Founder and CEO

The founding team at Edge Impulse was running more than 40 containers in production. Every few weeks, a build would break without anyone changing the application code.

A Docker base image had updated or disappeared. An apt package had moved. A Python dependency had drifted despite being pinned.

Each failure was urgent. When you cannot build your software, you cannot ship a fix. Finding the cause often required the most senior engineers, particularly when the failure sat deep in the stack. Work stopped while they traced a problem outside their own code.

Jan Jongboom and Zach Shelby backed StableBuild to solve that recurring problem. Edge Impulse became our first customer and rolled it out across every container they ran.

Before we sold StableBuild to anyone else, the product had already been put to work in a real production environment.

Why a company, not a script?

Many engineering teams already protect their builds with internal caches, mirrors, or proxies. These approaches can work. The question is who takes responsibility for running them.

Each company pays to host its own infrastructure. Someone has to maintain it, investigate failures, and keep it working as the surrounding software changes. That responsibility sits alongside the product the team actually sells.

The same work gets repeated across companies.

We built StableBuild to provide that infrastructure as a shared service. Instead of each team building and hosting its own version, we operate it for multiple customers. The hosting cost is spread across the companies using it, rather than duplicated at each one.

That is the reason to build a company around the problem. A script can address a particular failure. An ongoing service needs people responsible for keeping it working after that incident is over.

The dependencies really do disappear

In September 2026, the minio/minio and minio/mc repositories disappeared from Docker Hub. Builds that referenced them began failing, including builds pinned to specific releases. Historical images remained available on Quay, but teams still had to investigate and change where they retrieved them.

We encountered this ourselves. One of our subsystems pulled MinIO directly from Docker Hub, and its smoke tests failed. A customer who had already pulled the image through StableBuild could still access the cached copy. We documented both experiences in our MinIO incident post.

NVIDIA CUDA images illustrate the same risk. NVIDIA has explicitly announced the deletion of end-of-life container tags from Docker Hub and NVIDIA NGC. Specifying a precise tag does not exempt an image from that lifecycle. NVIDIA’s CUDA support-policy announcement describes that policy.

Pinning and preservation solve different problems. A version reference tells a build what to request. It does not require the registry to keep serving it.

For container images, StableBuild’s Docker mirror stores an image when it is first pulled through the service and serves that preserved copy on later pulls. It cannot recover an image it never captured. Preservation has to happen while the dependency is still available. Our CUDA article explains the mechanism and its limits.

Why this problem matters to me

I spent years engineering embedded and regulated systems, where software needs to remain maintainable long after its first release.

At Symax, my work included embedded programming and IoT hardware. As CTO at Epigno, I built medical enterprise software from scratch. Later, at Soracom, I led engineering teams responsible for different parts of the product.

Those roles required attention to what happens after software ships. A customer may still depend on an older deployment. A team may need to investigate a fault or release a patch years later. Being able to retrieve the dependencies behind that software is part of supporting it.

That experience shaped my approach to StableBuild. Edge Impulse gave us a concrete production problem. My background gave me a reason to take its long-term consequences seriously.

Preserving a dependency does not mean keeping outdated software in production indefinitely. Teams still need to assess vulnerabilities, test upgrades, and move to supported versions. The aim is to make those changes deliberately, without first having to recover a missing build input.

I built StableBuild because maintaining access to those inputs should not require every engineering team to operate the same infrastructure independently.

We take on that work so they can spend more time maintaining and improving the products their customers rely on.

Learn more about StableBuild.