Reproducible Builds in May 2026

If builds were reproducible, lots of the complexity in the software delivery ecosystem would have been avoided. Taking Kubernetes deployments as an example, you need a build pipeline and a continuous delivery system (like ArgoCD) because of non-reproducible builds. With reproducible builds, you can just say deploy this commit hash to dev and then later deploy same hash to prod, there will not be any drift (assuming the deployment system knows how to package the source code properly). Avoids the need for a build pipeline, artifact storage, defining image tags for each env, CD system etc.

I have been building a deployment platform OpenRun based on the deploy from source model. It is targeting internal tools, so non-reproducible builds are fine to some extent. But build tooling moving to a reproducible mode would simplify deployments generally.

I'm working alongside the team who built kettle (mentioned in TFA) and it's a really cool innovation. Making builds reproducible in practice is a PITA, but making the inputs predictable and running the build in a TEE gives a lot of the practical guarantees without spending your life fiddling with your build system