What makes a build hermetic, and why is a hermetic build not automatically deterministic?

## Two different properties that get merged into one word Engineers routinely use "hermetic", "deterministic" and "reproducible" interchangeably. They are not the same claim, and an interviewer asking this question is usually checking whether you can separate them. **Hermeticity is about inputs.** A build is hermetic when the complete set of things it consumes is declared before it starts and pinned to exact content, and when nothing else can enter while it runs. "Declared" means written down somewhere the build system reads: a manifest, a lockfile, a build graph. "Pinned" means identified by content, not by a moving name, so that the same declaration cannot resolve to different bytes tomorrow. "Nothing else enters" means the build step does not open a network connection, does not read an unmanaged directory on the machine, and does not depend on whatever tools happen to be installed on the runner. **Determinism is about output.** A build is deterministic when the same declared inputs produce byte-identical output. When that holds not just twice on one machine but across different machines, directories and dates, people usually call it reproducible. ## Why the two do not imply each other All four combinations exist. - Hermetic and deterministic: the goal. Output is a pure function of declared inputs. - Hermetic but not deterministic: the common case, and the reason this question gets asked. The build consumed exactly the declared inputs, and still stamped the current time into an archive header, embedded the absolute path `/home/runner/work/build-9182` into debug information, and wrote archive members in whatever order the filesystem returned them. None of those are inputs; they are ambient facts about the run. - Deterministic but not hermetic: fragile luck. A build that fetches a dependency by a mutable tag can produce identical bytes on Monday and Tuesday and different bytes on Wednesday when someone republishes that tag. Nothing in your build changed; the world did. - Neither: the default state of most pipelines before anyone works on it. ## What counts as an input The list is longer than most people's first answer. Source, obviously. Third-party dependencies, pinned by digest or by a lockfile that records a hash per component rather than a version range. The compiler and every other tool the build shells out to. The base image or the container the step runs in, referenced by digest rather than by a tag such as `latest`, because a tag is a name that can be repointed while a digest names the content itself. Configuration and environment variables the build reads. Code generators and their templates. The two inputs people forget are the toolchain and the operating-system libraries underneath it. If the runner image is upgraded and your compiler minor version changes, your build consumed a different input even though nothing in your repository moved. ## What "no network mid-build" actually means It does not mean the build never touches the network. It means the fetching is a separate, earlier phase with its own verification, and the phase that transforms inputs into an artifact runs sealed. A typical shape is: resolve and fetch every declared dependency, verify each one's hash against the declaration, place them into a local input tree, then execute the build in a sandbox with no outbound access. If a build step needs something that was not fetched, the correct outcome is a hard failure, not a lookup. Enforcement matters more than intent. A build that is *supposed* to be offline but runs in a sandbox that permits egress is one careless script away from not being hermetic, and nobody will notice until an upstream host changes what it serves. ## Half-measures that look like hermeticity - A version range in a manifest is not a pinned input. `^2.4.0` resolves at build time and can resolve differently next week. - A lockfile with exact versions but no hashes is better but still names rather than pins: an exact version can be republished in some ecosystems. - Caching is not hermeticity. A cache changes where an input came from, not whether it was declared. - Disabling the network without declaring inputs just makes the build fail; declaring inputs without sealing the network just makes the failures silent. ## Why you want it The practical payoff is that the build becomes a function you can re-run. Failures stop being "it worked yesterday"; a change in output implies a change in something you wrote down. An upstream host cannot alter what you shipped without altering a declaration first. And a build cache becomes trustworthy, because a cache key computed over declared inputs actually describes the output.