Skip to content

Glossary

Dense term index for the Nix stack. Each entry is a short definition; follow the relative link for the deep dive when one exists.

Activation (NixOS). Applying a built system configuration to the running machine: switching services, users, files under /etc, and bootloader entries. Driven by the activation script produced with the system closure. See activation script and rebuild operations.

access-tokens (nix.conf). Host→credential map so Nix can fetch private GitHub/GitLab (and similar) HTTPS sources—flake inputs, fetchGit, and related downloads. Keep tokens out of flakes and lockfiles; inject them via local nix.conf or CI secrets. See access tokens and private flakes and CI.

Age plugin / sops-nix host keys. age can use SSH keys as identities; agenix and sops-nix typically encrypt secrets to each host’s SSH public key and decrypt with host private keys during activation—keep those keys on durable storage on impermanent hosts. See SSH and age plugins, agenix / sops-nix, and secrets strategies.

AppArmor. Linux mandatory access control (LSM). NixOS exposes profiles and loading via security.apparmor.*; maturity is partial—usable options, incomplete end-to-end coverage. SELinux has no proper stock NixOS integration. Distinct from the Nix build sandbox. See AppArmor and SELinux.

Attribute set (attrset). The Nix language’s primary structured value: a map from names to values, written { key = value; ... }. Packages, modules, and flake outputs are almost always attrsets. See lists and attrsets.

Binary cache. A remote store of pre-built NAR archives (plus .narinfo metadata) that a substituter can fetch instead of building locally. Public caches (e.g. cache.nixos.org) and private ones share the same protocol. See binary caches, hosting, and private cache mesh for multi-host wiring.

Build phase. A named step in the stdenv build (unpack, patch, configure, build, check, install, fixup, …). Packages override or hook into phases rather than reimplementing the whole builder. See build phases and stdenv.

build-image (nixos-rebuild). Upstream command (NixOS ≥ 25.05) that builds a configured system into a named image variant (--image-variant amazon, google-compute, azure, …). Preferred over deprecated nixos-generators for new cloud/image work. See Amazon / GCE / Azure.

CA store / content-addressed store. Store model where an output’s path is derived from the hash of its contents (or a declared content hash), not solely from the derivation’s input hash. Enables better sharing when identical bytes are produced by different recipes. See content-addressed store and CA derivations.

Channel. A named, periodically updated snapshot of nixpkgs (or another tree) that classic tooling pins via nix-channel. Still common on NixOS; flakes largely replace channels for reproducible pins. See channel, nix-channel, and flakes vs channels.

Clan. Multi-machine NixOS management (clan-core) with inventory and optional mesh VPN (e.g. ZeroTier)—peer-oriented fleet tooling, not hub→host deploy (Colmena, deploy-rs) and not Digga / Hive flake layout. See Clan and mesh and machine mesh.

Closure. The transitive set of store paths needed to use a given path at runtime (or to realize a derivation’s runtime graph). What you copy to another machine or what GC must keep if the root is live. See closure.

Community (getting help). Where to ask Nix/NixOS questions (Discourse, Matrix, GitHub issues) and how to report bugs without dumping secrets. See getting help and community.

Cross-compilation. Building for a different system than the build host (e.g. aarch64-linux on x86_64-linux) via nixpkgs package sets and stdenv cross stubs. See cross-compilation.

CppNix. Community name for the reference C++ implementation (NixOS/nix)—what most docs mean by “Nix,” and the default on NixOS. Distinct from Lix, Tvix, and Snix. See CppNix.

Derivation. A build recipe: inputs (sources, dependencies, builder, env) map to one or more output store paths. Evaluation yields a derivation value and usually a .drv in the store; realization runs the builder. Default model is input-addressed. See derivation and derivation builtins.

Determinate Nix. Vendor distribution of CppNix from Determinate Systems (installer, defaults, and optional extras such as Determinate Nixd). Compare install paths and effective nix.conf with official CppNix and Lix; do not assume identical experimental-feature defaults. See installers and Nix variants.

devShell. A flake (or nix develop / nix-shell) environment that puts compilers and tools on PATH without installing them into a user profile. See packages, apps, and devShells and shells and direnv.

Digga / Hive (divnix). Flake layout / collector tools for hosts and modules—not a network mesh, not Clan’s mesh VPN, and not Colmena’s deploy “hive.” Digga is deprecated; Hive sits on std/Paisano. See Digga / Hive; contrast machine mesh and Clan.

disko. Declarative disk partitioning for NixOS (disko.devices); templates and layout patterns live under Disko recipes. Tool overview: disko.

.drv. The store object that serializes a derivation. Output paths point back to their deriver .drv; inspecting it shows inputs and planned outputs. See derivation.

E–H

Experimental feature. A Nix daemon/evaluator capability gated by experimental-features in nix.conf (or --extra-experimental-features). Examples: flakes, nix-command, ca-derivations. Behavior and stability vary by Nix release—check the tracking page. See experimental features and feature flags overview.

Fixed-output derivation (FOD). A derivation whose outputs are content-addressed by a hash you declare (outputHash / outputHashAlgo). Used for fetches and other cases where the result must match known bytes; the sandbox may allow limited network for FODs. See fixed-output derivation.

Flake. A directory (or other flake reference) with a flake.nix that declares locked inputs and typed outputs (packages, nixosConfigurations, …), plus a lockfile. Requires the flakes experimental feature on CppNix; Lix also supports flakes (CLI/flag details can differ by implementation—check your version). See flake (concept), flake anatomy, and experimental flakes.

Flake registry. A map from short names (e.g. nixpkgs) to flake URLs, used when resolving bare flake refs. Global, user, and flake-local registries can override each other. See registries and refs.

Freeform module (freeformType). Inside a submodule, set freeformType = someType; so undeclared attribute names merge through that type instead of failing _module.check (surfaces as _module.freeformType). Common for open settings = { … } maps in service modules; prefer freeform only in submodules, not at the root. See module system internals and options and types.

FHS environment (buildFHSEnv / steam-run). nixpkgs helper that wraps a command in an FHS-like /usr//lib view (bubblewrap) so unpatched Linux binaries can run on NixOS; Steam’s steam-run reuses that pattern. Not a security sandbox like Flatpak. See Flatpak and FHS and Gaming: Steam and Proton.

Garbage collection (GC). Deleting store paths that are not reachable from any GC root. Profiles, generations, result symlinks, and explicit roots keep closures alive. See garbage collection and nix-collect-garbage.

GC root. A registered reference that prevents GC from deleting a store path and its closure—user profiles, NixOS system generations, result links, and paths under /nix/var/nix/gcroots. See garbage collection.

Generation. A numbered snapshot of a profile (user env or NixOS system) that you can roll back to. Each successful profile update or nixos-rebuild creates a new generation. See generation, NixOS generations and boot, and rollbacks.

haskellPackages. Default GHC-backed Haskell package set in nixpkgs (Hackage-facing attributes; alias of a haskell.packages.* set for the current compiler). One pinned version per name—not a Cabal solver. See Haskell packaging.

Hermetic build. A build that sees only declared inputs: no ambient host packages, no undeclared network, sandbox-isolated filesystem and env. Closely related to purity; hermeticity is the build-time isolation story. See hermetic builds and builders and sandboxes.

Home Manager. A module system for declarative user environments (dotfiles, packages, services) that can run standalone or as a NixOS/nix-darwin module. See home-manager, standalone vs NixOS module, and module ecosystem note.

I–L

Impure / impure eval. Evaluation or builds that depend on ambient state (current time, impure env, unrestricted filesystem). Flake pure eval forbids many of these; --impure and impure-derivation features re-open controlled exceptions. See pure eval and impure, purity boundaries, and impure derivations.

Impermanence. Ephemeral root (tmpfs or wipe-on-boot) with declared persistent paths—undeclared state vanishes at reboot. Usually via nix-community/impermanence. See impermanence.

Import from derivation (IFD). Evaluation reads a store path produced by another derivation (via import, readFile, and similar), so Nix realises that path mid-eval. Slow and often banned in CI (allow-import-from-derivation = false). Distinct from FODs. See import from derivation.

Input-addressed. The default store addressing: output path hashes come from the derivation’s inputs (recipe), not from hashing the built files. Contrast FOD and CA store. See derivation and hashing and inputs.

Inter-machine trust (inter-trust). How a group of Nix(OS) machines trusts each other across reachability, remote builds, binary caches, deploy authority, secrets, and supply chain—distinct from daemon trusted-users. See inter-machine trust and machine mesh.

Lanzaboote / Secure Boot (NixOS). Community UEFI Secure Boot (and measured-boot) stack for NixOS: custom stub, lzbt, and a NixOS module that signs boot artifacts and replaces stock systemd-boot install when enabled. Advanced; pin a release. See Secure Boot and Lanzaboote and TPM and measured boot.

Lix. Community-maintained fork of CppNix (lix.systems)—compatible for many day-to-day packaging and NixOS/Home Manager/nix-darwin workflows, with separate governance and documented technical differences. Not a claim of identical feature sets. Distinct from Tvix and Snix. See Lix.

Lockfile (flake.lock). JSON pin of every flake input to exact revisions and content hashes so evaluation is reproducible across machines and time. Updated with nix flake update / nix flake lock. See lockfile.

lib (nixpkgs). The shared Nix library of helpers (lib.mkIf, lib.optional, fetchers wrappers elsewhere, etc.) shipped with nixpkgs and used by packages and modules. See lib.

M–P

Machine mesh. A group of Nix(OS) devices that share builds, closures, secrets, and/or deploy authority over a shared reachability fabric—not a VPN brand, not Digga / Hive, and not “the mesh” by itself. Concept page: machine mesh. For private substituter topology across that fabric, see private cache mesh. Contrast hub→host fleet tools (Colmena, deploy-rs) and peer inventory tooling (Clan).

Measured boot. Binding LUKS (or similar) unlock to TPM PCR measurements of the boot chain—on NixOS usually via Lanzaboote + systemd-pcrlock. Experimental edges; LUKS2-oriented; not ZFS/Btrfs native encryption. See TPM and measured boot.

mitmCache (Gradle). nixpkgs Gradle helper (gradle.fetchDeps) that pins dependency downloads into a FOD-backed MITM cache (deps.json); refresh via the cache’s updateScript when deps change. See JVM / PHP and others.

mkDerivation. The usual nixpkgs entry point for defining a package: stdenv.mkDerivation { pname; version; src; ... }. Wraps builtins.derivation with stdenv phases, setup hooks, and conventions. See mkDerivation and stdenv.

Module (NixOS). A function or attrset that declares options and/or sets config, merged by the module system with imports, types, and priority. Home Manager and nix-darwin reuse the same pattern. See module system and writing a module.

Multiple outputs. Splitting one derivation into several store paths (out, dev, doc, …) so dependents can pull only what they need. See multiple outputs.

NAR / narinfo. NAR is Nix’s archive format for store objects; .narinfo is the binary-cache metadata (hash, size, references, signature) for a path. See substitutes and narinfo.

nix-command. Experimental feature enabling the unified nix CLI (nix build, nix flake, nix profile, …) as opposed to only classic nix-* tools. Often enabled together with flakes. See nix-command and modern build/develop/run.

nix.conf. Daemon and client configuration (/etc/nix/nix.conf, ~/.config/nix/nix.conf): substituters, trusted users, experimental features, build sandboxes, and more. See nix.conf.

nix-darwin. Declarative macOS system configuration using a NixOS-like module system. See nix-darwin.

nixos-hardware. Optional NixOS modules for machine-specific quirks (laptops, SBCs, common PCs)—complements generated hardware-configuration.nix, does not replace it. See nixos-hardware.

NixOS. A Linux distribution whose entire system is a Nix derivation: modules evaluate to a system closure, then activation switches the running machine. See NixOS.

nixpkgs. The package collection and stdenv/lib/module library that most Nix users evaluate—channels and flakes both typically pin a nixpkgs revision. See nixpkgs.

Option (NixOS). A typed, documented configuration knob declared with mkOption (or helpers); modules assign values that merge into config. Query with nixos-option / docs. See options and types, config vs options, and options cheatsheet.

Overlay. A function final: prev: { ... } that extends or replaces attributes in a nixpkgs package set without forking the whole tree. Distinct from per-package .override / .overrideAttrs. See overlay, overlay vs override, and writing overlays.

Overlay network (Nix context). VPN or mesh fabric (WireGuard, Tailscale/Headscale, ZeroTier, …) used so builders, deploy SSH, and private caches can reach each other—not a general VPN tutorial. See overlay networks and Clan and mesh.

Override. Changing one package’s arguments (.override) or derivation attrs (.overrideAttrs) locally, without a full overlay. See overlay vs override and patches and overrides.

Pinning. Fixing nixpkgs or other inputs to exact revisions (flake lock, fetchTarball + hash, Niv/npins, channel generation) so builds do not drift. See pinning and lockfile.

PipeWire. Desktop audio/video server on NixOS (services.pipewire), usually with PulseAudio-protocol and ALSA shims; WirePlumber is the common session manager. See Audio and PipeWire.

Profile. A user- or system-managed symlink forest of installed packages, versioned as generations. Classic nix-env and modern nix profile both operate on profiles. See profile and nix profile.

Purity. Evaluation and builds that depend only on declared inputs—same expression and inputs → same result. Flake pure eval and the build sandbox enforce different layers of this ideal. See purity and reproducibility and purity boundaries.

Q–T

Realization. Building or substituting a derivation so its output store paths exist on disk. Evaluation alone does not realize; nix build, nix-build, and nix-store --realise do. See derivation.

Remote builder. Another machine the local Nix daemon can offload builds to over SSH (or similar), still producing paths for the local store. See remote builders.

Sandbox. The isolated build environment (namespaces, bind mounts, restricted network) that enforces hermetic builds. Configurable in nix.conf; FODs may get network exceptions. See builders and sandboxes and sandbox escape surface.

Snix. Modular Rust reimplementation of Nix components (evaluator, store, builders)—continuation of the Tvix stack under independent hosting; early / research maturity, not a drop-in for CppNix or Lix. See Snix.

specialArgs (module system). Arguments passed into lib.evalModules that are available during import resolution and in module bodies—use for flake inputs, modulesPath, and anything referenced from imports. Contrast _module.args (module bodies only, after merge). See module system internals and config repo layout.

Specialisation (NixOS). Named alternate system closure built alongside the parent configuration (specialisation.<name>), linked under /run/current-system/specialisation/<name>/ and switchable via that child’s activation script. See specialisations.

stdenv. The nixpkgs standard environment: compilers, core utilities, and the default builder/mkDerivation phase machinery for a platform. Almost every package builds inside some stdenv. See stdenv.

Store. The content-addressed (by path hash) filesystem tree, usually /nix/store, holding .drv files, outputs, and sources registered with Nix. See store layout.

Store path. A concrete path under the store (/nix/store/<hash>-<name>) naming a single store object—an output, source, or .drv. Hashes encode addressing mode and identity. See store path.

Substituter. A configured store URL Nix queries to download a path instead of building it (substituters / extra-substituters in nix.conf). Usually a binary cache; signatures and trusted-user rules matter. See substitutes and narinfo, trusted users and substituters, and signing.

Trusted user. A nix.conf principal allowed to set extra substituters or use restricted store operations that ordinary users cannot. Misconfiguration is a common cache/signing footgun. See trusted users and substituters and trusted users (security).

Tvix. Experimental Rust Nix reimplementation by TVL (modular evaluator/store/builder); not a production NixOS drop-in. Active modular continuation often tracked as Snix. See Tvix.

U–Z

vendorHash. Content hash pinning a language builder’s vendored dependency tree as a FOD (notably PHP Composer via php.buildComposerProject2; same idea as cargoHash / npmDepsHash). Mismatch means refresh the pin after lock/deps change. See JVM / PHP and others and fixed-output derivation.

XDG Desktop Portal. Desktop integration bus for sandboxed and Wayland apps (file choosers, screenshare, …), configured on NixOS via xdg.portal.*. See Wayland and compositors and Flatpak and FHS.

Aliases: FOD → fixed-output derivation; IFD → import from derivation; CA → CA store; HM → Home Manager; GC → garbage collection; Secure Boot (NixOS) → Lanzaboote / Secure Boot; Hive (Digga) → Digga / Hive; age secrets → Age plugin / sops-nix; specialisation → Specialisation.

References

See also