A hermetic build is isolated from the machine it runs on, so the same inputs give the same result. A reproducible build produces bit for bit identical output when rebuilt. Hermeticity is about the process, reproducibility is about the artifact, and the first usually has to come before the second.
Two words, two different promises
People swap these terms constantly, which causes real planning mistakes. Here is the short version.
| Hermetic build | Reproducible build | |
|---|---|---|
| Core idea | Isolation from host tools and state | Same output bits every time |
| What you check | Does it depend on anything undeclared? | Do two builds hash the same? |
| Typical blocker | Host compilers, absolute paths, network fetches | Timestamps, build IDs, file ordering |
| Main payoff | Trustworthy caching, clear input list | Independent verification of an artifact |
Bazel's documentation defines a hermetic build as one that returns the same output for the same source and configuration by isolating the build from changes to the host system. Its troubleshooting advice includes a hash comparison: if you run steps twice or on different systems and the content hashes differ, the build is not reproducible.
Why you can be hermetic without being reproducible
Isolation controls what the build can see. It does not control what the tools write. A compiler may embed a timestamp or a random identifier, and an archive tool may order files differently on each run. The build still used only declared inputs, so it is hermetic, but two outputs hash differently.
The reverse also happens. A build can look reproducible on one machine because the host is stable, while quietly depending on a system compiler. Move it to a new host and the bits change.
Which one to chase first
For most teams, work in this order:
- Pin the inputs: tools, dependencies, base images, with checksums.
- Remove host leakage: use declared toolchains and a clean build environment.
- Hunt non-determinism: timestamps, ordering, embedded paths.
- Only then compare hashes across independent builders.
Step 4 is where reproducibility pays off for security, because a second party can rebuild and confirm the artifact matches what you shipped. Steps 1 and 2 pay off sooner, because they make shared build caches safe to trust.
What neither one proves
Neither property says the code is free of vulnerabilities. A reproducible build of a vulnerable library is still vulnerable. Treat both as ways to make the question "what exactly is in this artifact?" answerable, then pair them with dependency scanning and advisory monitoring.
Where Safeguard fits
Safeguard can inventory the dependencies your repository declares through SBOM and dependency scanning, and reachability analysis helps you decide which findings matter first. You can try a free scan on a repository to see what it finds. Check coverage for your specific build files before relying on it.
Quick check
Can a hermetic build still produce different output each time?
Yes, if a tool embeds timestamps or random identifiers. Isolation fixes what the build reads, not what the tools write.
Do I need reproducible builds to use a remote cache safely?
You need the build to be deterministic enough that a cached output is correct for the same inputs. The Bazel documentation says outputs from one machine can be safely reused on another if the build is reproducible.
Sources
Last reviewed: 19 October 2026.
