What factors affect the reproducibility of Nix builds?

The first that comes to mind are variable inputs, whose effects can be mitigated by pinning the dependencies and source(s). I used the word “mitigated” because I remember reading somewhere that even with all inputs fixed, impurities could still be introduced to the builds. Could be wrong, and may have misinterpreted what I read.

Anyway, I would love to hear about your experiences. Thanks!

1 Like
  • -march=native flag
  • reading from /dev/random
  • creating any other hashes which include some randomness
  • not respecting SOURCE_DATE_EPOCH and embedding system time
  • not using a sandboxed build, can read from host system

I’m sure there’s many others

Also, Deterministic build systems — reproducible-builds.org is mostly applicable to nix builds as well.


@jonringer’s answer seems to cover things that would break the byte-for-byte reproduction of outputs.

But, if you just mean the reproduction of the final derivation, I have something of a list here: To flake or not to flake - #4 by colemickens. These don’t apply if you’re using flakes.


For some real-world examples, check out the “reproducible builds” tag on Nixpkgs:



you may be interested in grahams nixos related site about this. Interesting reading.

$ nix-build . -A hello
$ nix-build . -A hello --check --keep-failed
error: derivation '/nix/store/...hello.drv' may not be deterministic:
output '/nix/store/...-hello' differs from '/nix/store/...hello.check'
$ diffoscope /nix/store/...hello /nix/store/...hello.check
1 Like