A team proposes making every build hermetic - pinned toolchains and dependencies, no network access during the build, byte-identical output from the same commit. What does that buy and what does it cost?

What is gained, in order of practical value

• Caching that is actually correct. A hermetic build's inputs are fully known, so its output can be cached and reused with confidence. On a large repository this is frequently the largest measurable win - build times falling by a large multiple because unchanged targets are never rebuilt - and it is the benefit that pays for the work.
• Debuggability across time. A build from a commit eighteen months old produces the same artefact, so "does this bug exist in the version the customer is running?" is answerable by building it rather than by reasoning.
• A supply-chain claim you can defend. Reproducibility lets a second party rebuild and compare, which is the difference between "we signed this" and "anyone can verify this came from that source". Provenance frameworks such as SLSA, published in its 1.0 form in 2023, are built on this property.
• Removal of a class of flake. "It built yesterday" failures from a mutable upstream tag or a network-fetched dependency disappear.

What is paid

• Every input must be pinned and vendored, including compilers, system libraries, base images and build tools. This is not a sprint; on an existing codebase it is a long tail of discoveries.
• Ongoing friction on every dependency change. Adding a library becomes a lockfile and vendoring change rather than a one-line edit, and engineers will feel it daily.
• Non-determinism has to be hunted down: timestamps embedded in archives, file ordering from the filesystem, absolute paths, locale, random seeds, parallel-build ordering. Each is small and there are many.
• Frequently a different build system, which is the largest cost by far - a migration that touches every team.

When the cost becomes visible

At adoption, and then never again - which is the unusual and attractive shape of this trade. The pain is concentrated in the migration; the benefits accrue continuously afterwards. That is the opposite profile from most infrastructure work, and it is why teams that do it rarely regret it and teams that have not done it find it hard to justify.

The middle position, which is usually right

Full determinism is not required to get most of the benefit. Ranked by value per unit of effort:

1. Lockfiles for every dependency, including transitive ones. Cheap and removes most "it built yesterday" failures.
2. Pinned base images by digest, never by tag. One change, large effect.
3. A pinned toolchain version checked into the repository.
4. No network access during the build step, which forces the remaining unpinned inputs to reveal themselves.
5. Byte-identical output, which is the expensive last step and is only required if you want third-party verification.

Most teams should stop after 3 or 4. Stopping is a legitimate outcome, and framing hermeticity as all-or-nothing is how the proposal gets rejected entirely.

When this is the wrong investment

For a small codebase with a fast build and one deployment target, the caching benefit - the main payer - is small, and steps 1 to 3 give you the reproducibility that matters for debugging at almost no cost. Byte-level reproducibility earns its keep when someone outside your organisation needs to verify your artefacts, or when build times are a measured constraint on delivery.