Nix Package Management

Nix Package Management is a purely functional package management system designed to provide reliable and reproducible software builds and deployments. It uses a novel approach where packages and their dependencies are stored in an isolated, content-addressed store, ensuring that packages do not interfere with each other and enabling precise control over package versions and configurations. This model allows multiple versions of the same package to coexist seamlessly, facilitates atomic upgrades and rollbacks, and supports multi-user environments with minimal conflicts.

Nix Store

The Nix store is the central repository where all packages and their dependencies are stored. It is located at a fixed path (commonly /nix/store) and contains directories named by cryptographic hashes derived from the build inputs, configurations, and source code. This hash-based addressing guarantees that different package variants are uniquely identified and stored without collision.

The store is immutable once a package is built, meaning packages cannot be altered in-place, which eliminates side effects and ensures reproducibility. The Nix store also supports garbage collection by tracking references from profiles and other roots, enabling safe cleanup of unused packages.

Derivations and Build Inputs

A derivation is a low-level build instruction that describes how to build a package. It specifies build inputs, environment variables, build scripts, and outputs. Derivations are written in a domain-specific language and represent the build actions declaratively.

Build inputs include source code, dependencies, compilers, and libraries required for building a package. Because each input is also stored in the Nix store and identified by its hash, derivations ensure that builds are deterministic and isolated from the system environment. This approach avoids "dependency hell" and inconsistent builds.

Nix Package Sources and Nixpkgs

Nixpkgs is the extensive collection of package expressions for Nix, maintained as a large repository of package definitions. It provides a comprehensive set of build instructions, configurations, and metadata for thousands of software packages.

Packages in Nixpkgs are defined using the Nix expression language, which allows parameterization and composition of package builds. Users and maintainers can customize builds by overriding attributes or adding patches without modifying the original package definitions.

Nix also supports importing external sources such as Git repositories, tarballs, or HTTP URLs as inputs, integrating them seamlessly into the build process.

Binary Substitutes and Caches

To optimize build times and resource usage, Nix supports binary substitutes: pre-built package binaries stored in caches. When installing a package, Nix first checks whether a binary substitute matching the exact build parameters is available in a trusted cache (such as the official cache at cache.nixos.org).

If a substitute is found, Nix downloads and installs the binary package directly without rebuilding. This mechanism accelerates deployment and ensures that users benefit from reproducible and verified builds.

Administrators can also set up private binary caches to share builds across teams or systems, further improving efficiency.

Nix Profiles

Profiles are user or system-specific collections of installed packages and configurations. They are implemented as directories containing symbolic links to the corresponding packages in the Nix store.

Profiles enable multiple versions of packages to coexist and allow atomic upgrades and rollbacks by switching symlinks to new or previous package versions. Each user can maintain separate profiles, or system-wide profiles can be managed by administrators.

The profile mechanism provides a flexible way to manage environments without polluting or conflicting with the global system state.

Multi-Version Package Coexistence

Because each package variant is stored in a unique directory identified by its build input hash, Nix inherently supports multiple versions of the same software installed simultaneously. This eliminates conflicts caused by incompatible dependencies or version mismatches.

Developers can easily switch between versions or test new package builds without affecting existing setups. The isolation provided by the Nix store and profiles ensures that environment variables, paths, and dependencies remain consistent and controlled.

Nix Package Operations

Nix provides a rich command-line interface for managing packages, including installing, upgrading, removing, and querying packages. Primary commands include:

• nix-env: Manipulate user profiles and install packages.
• nix-build: Build derivations from expressions or files.
• nix-store: Manage the Nix store directly, including garbage collection.
• nix-shell: Create temporary development environments with specified dependencies.

Operations are transactional and atomic, ensuring system integrity even if a process is interrupted.

Garbage Collection and Store Roots

Nix tracks references to packages from active profiles and other roots to determine which store paths are in use. Unreferenced paths become candidates for garbage collection.

Garbage collection is performed safely via nix-collect-garbage, which removes unneeded packages and frees disk space without affecting active environments. Users can protect specific store paths by adding them as roots.

This approach maintains a clean and efficient store while preserving reproducibility and rollback capabilities.

Nix Configuration

Nix is highly configurable through system-wide and user-specific configuration files, typically located in /etc/nix/nix.conf or ~/.config/nix/nix.conf. Configuration options control aspects such as:

• Binary cache URLs and trust settings.
• Store path locations.
• Build sandboxing and resource limits.
• Multi-user mode behavior.
• Garbage collection policies.

Configuration allows tailoring Nix behavior to diverse environments, from single-user desktops to large-scale CI systems.

User-Scoped and Multi-User Nix

Nix supports both single-user and multi-user modes. In single-user mode, the Nix store and daemon run under one user, suitable for desktops or development machines.

In multi-user mode, a system-wide Nix daemon manages the store and builds on behalf of multiple users with proper permission isolation. This mode provides enhanced security and resource control, ideal for shared servers and production environments.

Multi-user Nix also supports user-specific profiles with independent package sets, while sharing build results and caches globally.

Store Verification and Trust

To ensure security and integrity, Nix verifies the contents of store paths against their cryptographic hashes. This prevents tampering or corruption of packages.

Binary substitutes obtained from caches are cryptographically signed to establish trust. The Nix daemon enforces sandboxed builds and strict dependency declarations to avoid side effects.

Together, these mechanisms guarantee that installed software matches exactly the declared build inputs, supporting reproducible and trustworthy package management.