Reproducible Builds

When compiling from the same source on independent infrastructure yields bit-by-bit idential results, this gives confidence that the build infrastructure was not compromised and the artifact really does correspond to the source.

Because a Nix derivation has deterministic references to all of its dependencies, and the build happens in a sandbox, Nix is an excellent starting point for achieving Reproducible Builds.

However, this alone is not sufficient: builds may still leak timestamps or have other nondeterminisms. For nixpkgs, such problems are tracked with the 'reproducible builds' issue tag. You can report a new issue using the issue template.

Checking reproducibility

Building a package twice can't prove it is reproducible: you might simply have gotten lucky. However, it is a useful first step.

To check whether you can reproduce a package on your machine, you can use nix-build '<nixpkgs>' -A hello --check --keep-failed or nix build nixpkgs#hello --rebuild --keep-failed.

For fixed-output derivations, run the build four times:

On failures, you can use diffoscope to analyze the differences in the outputs of the two builds. To view the build log of the build that produced the artifact in the binary cache you can use nix-store --read-log $(nix-instantiate '<nixpkgs>' -A hello).


As a general health check, we are producing reports on the reproducibility of the packages that make up our minimal and Gnome installation ISO's:

The 'build-time dependencies' reports include all packages that are needed to build the ISO. The 'runtime dependencies' reports only include the packages that 'make it into' the ISO, meaning they contain much less noise, but also might miss relevant build-time unreproducibilities.

Get involved!

For an overview of issues for those milestones see this Project. If anything seems wrong/incomplete ping raboof.

Helping make NixOS reproducible is a great way to contribute and learn - join us on Matrix at if you want to chat.

The source for this page can be found here.