Hermetic, ephemeral, reproducible builds



This short note defines the notions of hermetic, ephemeral and reproducible software build, as used in my writing.


A build is said to be hermetic, if each build step only has access to the set of input artifacts that are minimally required for the build to succeed.

Hermeticity is useful to ensure build correctness – as it allows us to confirm that each build dependency step is well captured, and that none are omitted.

Hermeticity also makes a build parallelizable, because the minimum set of build dependencies is known and can be farmed out to multiple build servers if needed.


A build is said to be ephemeral, if the build relies only on the tooling that the build process installs or builds itself.

No pre-installed build-specific system state is necessary. When a build is invoked, it provides all the resources it needs, either by vendoring them within the source code repository, or by downloading appropriate integrity-checked build artifacts.


A build is said to be reproducible, if two identical instantiations of the same build process A and B build bit-identical artifacts.

For example, build systems that rely on pre-installed tools may end up not being reproducible. This could be due to inadequate version granularity of build dependencies, coupled with non-ephemeral build installations.