Nix Store

Nix Store is the central content-addressed storage area used by the Nix package manager to hold all installed packages, dependencies, and build outputs in a purely functional manner. It ensures reproducibility and isolation by storing every package or build artifact under uniquely hashed paths derived from their build inputs and environment. This design eliminates global side effects and conflicts typical of traditional package management systems, enabling multiple versions and variants of software to coexist seamlessly.

Structure and Location

The Nix Store is typically located at /nix/store on Unix-like systems. It is organized as a flat directory containing subdirectories named by their cryptographic hash prefixes combined with human-readable identifiers. Each directory represents a single store path, which corresponds to an immutable build output or package.

Store paths follow the pattern:

/nix/store/<hash>-<name>-<version>

• <hash> is a fixed-length cryptographic hash (usually SHA256 truncated) that uniquely represents the exact content and build environment.
• <name> is the package or derivation name.
• <version> is the version or other identifying information.

This naming scheme guarantees that no two different builds produce the same store path, and the hash acts as a content address.

Content and Immutability

Each store path contains the fully built package or derivation output, including binaries, libraries, documentation, and metadata. Crucially, contents in the Nix Store are immutable: once a store path is created, it never changes. This immutability is fundamental to Nix’s model and enables:

• Reproducibility: identical inputs always yield identical outputs stored at the same paths.
• Atomic upgrades and rollbacks by swapping references to store paths without overwriting data.
• Safe sharing of packages between users and environments without risk of corruption.

Content Addressing and Hashing

The hash prefix in a store path is derived from the complete set of inputs and build instructions used to create that package. This includes:

• Source code
• Dependencies and their exact versions
• Build scripts and environment variables
• Compiler flags and configuration options

By hashing these inputs, Nix ensures that even minor changes produce a different hash, resulting in a new unique store path. This content-addressing mechanism prevents conflicts and guarantees that builds are deterministic and verifiable.

Garbage Collection and References

Because the Nix Store accumulates many package versions over time, it includes a garbage collection mechanism to remove unreferenced store paths. References to store paths come from:

• User profiles (symlinks pointing to specific store paths)
• System configurations using specific packages
• Running processes or environment variables holding references

Paths without any references become candidates for garbage collection, freeing disk space while preserving isolation and reproducibility.

Integration with Nix Package Management

The Nix Store is tightly integrated with the Nix package manager and its build system:

• When a package is built or installed, Nix computes the hash of its inputs, builds the package, and stores it in the corresponding store path.
• Profiles and environments are constructed as sets of symlinks to store paths, facilitating easy switching and rollback.
• The store acts as the source of truth for package binaries and dependencies, decoupling them from system-wide mutable state.

This architecture enables powerful features such as atomic upgrades, multi-user package installations, and per-user environments without root privileges.

Summary

The Nix Store is a content-addressed, immutable storage hierarchy that holds all Nix-built packages and derivations. By encoding build inputs into cryptographic hashes, it achieves reproducible builds and conflict-free coexistence of multiple software versions. Its design forms the foundation for Nix’s purely functional package management model, supporting strong guarantees of isolation, sharing, and referential transparency in software deployment.