The Core Principle: Hermetic Builds

The Sealed Room Analogy

Imagine trying to bake a cake.

• A non-hermetic recipe says: "Add flour and sugar from the pantry, mix with water from the tap, and bake." The result depends on what brand of flour is in the pantry and the mineral content of the tap water. It will taste different in different kitchens, and on different days.
• A hermetic recipe comes with a sealed kit containing pre-measured, specific packets of flour, sugar, and distilled water. It says: "Open the provided packets, mix them, and bake." The result will be exactly the same, no matter which kitchen you are in, because every input is fixed and controlled.

Hermeticity in Software

A hermetic build is one that is completely isolated from the host operating system's ambient environment. Specifically:

• It cannot read environment variables like $PATH, $JAVA_HOME, or $CC that happen to be set on the developer's machine.
• It cannot access global system libraries like /usr/lib/libssl.so or /usr/local/include/boost.
• It cannot reach the internet during the build phase to download packages on the fly (no pip install or npm install happening mid-build).

Everything the build needs — compilers, linkers, libraries, source code, even the version of the standard library — must be explicitly declared as an input. The build tool runs each action inside a sandboxed environment (often using Linux namespaces or a chroot) with access only to those declared inputs. If you forget to declare a dependency, the build fails loudly and immediately, rather than silently succeeding on your machine and failing in CI.