A hermetic build isolates the build from the host machine, so only declared inputs matter. A reproducible build produces bit-for-bit identical artifacts from the same source, environment and instructions. Hermeticity is a way of getting there. You can have one without the other, so test for reproducibility directly.
Two definitions, side by side
Bazel's documentation says a hermetic build system always returns the same output, given the same input source code and product configuration, by isolating the build from changes to the host system. It has two aspects. Isolation means tools are treated like source code, downloaded and stored in managed file trees. Source identity means the system tries to ensure the sameness of inputs, for example by using Git hashes.
Reproducible Builds defines a build as reproducible if, given the same source code, build environment and build instructions, any party can recreate bit-by-bit identical copies of all specified artifacts.
| Question | Hermetic | Reproducible |
|---|---|---|
| What does it describe? | How isolated the build is from the host | Whether the output bytes match |
| How do you check? | Look for host dependencies, run in a clean container | Rebuild and compare hashes |
| Main benefit | Predictable inputs, caching, parallel runs | Anyone can verify the artifact |
| Can it fail alone? | Yes, if a step writes a timestamp | Yes, if the build quietly uses a host library |
How they differ in practice
A fully isolated build can still embed the current time in the output. Isolation stops the host from leaking in, but the build itself may add a build date, a random identifier or a path. That build is hermetic and not reproducible.
The other way round is also possible. A build that bytes-match across two runs on the same machine may still depend on a library installed on that host. It is reproducible there, but it is not hermetic, and it may fail to match on another machine.
Finding non-hermetic steps
Bazel's page lists common sources of non-hermeticity:
- arbitrary processing in makefiles,
- tools that create files non-deterministically, usually involving build IDs or timestamps,
- system binaries that differ across hosts, such as those in /usr/bin and system compilers,
- writing to the source tree during the build.
It suggests running the same build twice, checking that a second run rebuilds nothing, and comparing content hashes across runs or machines. It also suggests executing a build in a container that holds only the checked out source tree and an explicit list of host tools, so implicit system dependencies show up as errors.
What to do with this
- Make inputs explicit: pin the toolchain, lock dependencies, and verify downloads by checksum.
- Remove the host from the picture, with a clean container or a build system that manages its own tools.
- Remove time, paths and ordering from the output, using the specific fixes in the posts on tar archives and timezones and locales.
- Test by rebuilding. For background, see what a reproducible build is.
Quick check
Is a hermetic build automatically reproducible?
No. It controls host influence, but the build can still write timestamps or random values into its output.
Do I need a special build system to be hermetic?
Not necessarily. A clean container with pinned tools gets you part of the way, but a build system that manages its own tools makes it easier to keep.
Safeguard's SBOM and dependency scanning is generally available, and records the exact dependencies in each build input. You can try the free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
