Skip to content

Store Path

Overview

A store path is the on-disk location of a single object in the Nix store. Every built package, fetched source, and derivation file lives at a path of the form /nix/store/<hash>-<name>. The hash identifies the object's build identity—traditionally from the derivation and its inputs (input-addressed)—so distinct inputs never share a path. Once realized, a store path is immutable; upgrades and rollbacks add or select different paths rather than modifying existing ones.

Store paths are the unit Nix uses for caching, garbage collection, and substitution: if a path already exists locally or on a binary cache, Nix can skip building it. How digests are computed from inputs (or content) is covered in hashing and inputs.

flowchart TD
  drv["Derivation .drv"]
  realize[Realize or substitute]
  path["/nix/store/hash-name"]
  refs[Recorded references]
  drv --> realize --> path
  path --> refs
  refs -->|"transitive"| closure[Closure]

Details

Path shape

The store root is /nix/store (configurable per store). Each entry is <hash>-<human-readable-name>, for example /nix/store/…-hello-2.12. The hash portion is a 32-character Nix base-32 encoding of a 20-byte digest. The name aids debugging; the digest is what makes the path unique. Treat the digest as opaque for most operations—exact fingerprint rules differ by store-object kind.

For a normal derivation, the hash is computed from the derivation and the store paths of its dependencies. Same recipe and same input closure → same output path on any machine that can build or substitute it. Change any input and you get a new path; old paths remain until garbage collection removes unreferenced ones. Fixed-output derivations instead key the path off a declared output hash. See Immutability and rollback.

Realization and substitution

A path becomes valid when Nix realizes it—builds it, copies it from a substitute, or imports it—and every path in its closure is likewise valid. Until then, only the derivation (.drv file) may exist. After realization, the tree at that path is not modified in place.

Before building, Nix checks whether the output path is already in the local store. If not, it can substitute a bit-identical copy from a configured binary cache. The store path is the key for both local reuse and remote fetch.

Each store object records references to other store paths. Garbage collection deletes paths nothing references anymore. Profiles, generations, and other GC roots keep paths alive. The closure of a path is the full set reachable via those references. For how objects are laid out under /nix/store, see Nix store layout.

Boundaries (what this page is not)

  • Not the derivation recipe — how .drv files are produced from Nix code is derivation.
  • Not binary cache protocol — NARs, .narinfo, and substituters are substitutes and narinfo.
  • Not profile symlinks — user-visible ~/.nix-profile links point at store paths but are managed via profile and generation.

Examples

  • Inspect a path: nix-store --query --references /nix/store/…-hello-2.12 lists direct dependencies; --requisites lists the full closure.
  • Path from a build: With nix-command (and usually flakes) enabled, nix build nixpkgs#hello prints or symlinks to the realized output under /nix/store/…. Classic equivalent: nix-build '<nixpkgs>' -A hello.
  • Same inputs, same path: Rebuilding the same derivation with unchanged dependencies yields the identical store path; bumping a dependency hash produces a new one alongside the old.

References

See also