Nix 101 for Flox people

Nix builds every package into its own hash-named folder under /nix/store, records exactly which other folders it needs, and can fetch a prebuilt copy from a cache instead of compiling. Flox keeps those guarantees and wraps them in a manifest, a catalog and a shared registry, so most users never write Nix.

This page is drawn from the Nix reference manual (https://nix.dev/manual/nix/stable/store/store-path, https://nix.dev/manual/nix/stable/glossary, https://nix.dev/manual/nix/stable/language/derivations, https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-flake, https://nixos.org/manual/nix/stable/package-management/binary-cache-substituter.html, https://nixos.org/), Flox’s docs (https://flox.dev/docs/concepts/packages-and-catalog, https://flox.dev/docs/concepts/base-catalog, https://flox.dev/docs/concepts/package-groups, https://flox.dev/docs/man/manifest.toml) and Flox’s blog posts cited inline. The Nix manual pages were fetched 2026-11-04 and showed Nix 2.34.9 (https://nix.dev/manual/nix/stable/store/store-path). Nix facts here come from the Nix project; Flox facts come from Flox.

The 30-second version

Nix, in Flox’s words, is “three complementary things rolled into one”: a cross-platform package manager, a virtual environment manager, and “a declarative build system, complete with its own functional expression language” (https://flox.dev/blog/enterprise-nix-its-time-to-bring-nix-to-work/). The Nix project says builds run “in isolation from each other”, so “if a package works on one machine, it will also work on another” (https://nixos.org/).

Flox’s relationship to it: “Under the hood, Flox uses Nix to ensure reproducibility” without requiring you to learn Nix (https://flox.dev/docs/).

The vocabulary, one idea at a time

flowchart LR
  N[Nixpkgs<br/>recipes] --> D[Derivation<br/>build spec with a hash]
  D -->|substituter has it| C[Binary cache<br/>download]
  D -->|cache miss| B[Sandbox build]
  C --> S[Store path<br/>/nix/store/hash-name]
  B --> S
  S --> CL[Closure<br/>path plus everything it needs]

Store paths

A store path is a name in the Nix store. The manual’s example is /nix/store/q06x3jll2yfzckz2bzqak089p43ixkkq-firefox-33.1, made of the store directory, a digest, and a readable name (https://nix.dev/manual/nix/stable/store/store-path). The digest is “A 20-byte digest for identification” (https://nix.dev/manual/nix/stable/store/store-path). Flox describes the effect: packages are “installed to unique paths with locations determined by the cryptographic checksum of their inputs and build instructions”, which avoids conflicts and allows “atomic upgrades and rollbacks” (https://flox.dev/blog/nix-pure-genius/).

Say: “Two versions of the same library never fight, because they live at different addresses.” You can see these paths in a Flox lockfile, which lists /nix/store/... paths for each package output (https://flox.dev/docs/concepts/environments).

Derivations

The Nix glossary: “A derivation can be thought of as a pure function that produces new store objects from existing store objects.” It runs in a sandbox that, by default, only reads the store objects it declared (https://nix.dev/manual/nix/stable/glossary). Flox’s explanation of why this matters: with Nix, “every input” (sources, compilers, flags, environment variables) is declared explicitly, so you do not begin with a package, “you begin with a build” (https://flox.dev/blog/the-experienced-novice-dives-into-nix/).

Closures

The glossary defines the closure of a store path as the set of store paths directly or indirectly reachable from it, and “For correct deployment it is necessary to deploy whole closures, since otherwise at runtime files could be missing.” (https://nix.dev/manual/nix/stable/glossary). Flox’s version: a package’s closure provides “everything that application requires all the way down to and including libc” (https://flox.dev/blog/nix-pure-genius/). This is also why Flox can make small container images: Nix knows the runtime closure, so images can contain only that (https://flox.dev/blog/nix-and-containers-why-not-both/).

Nixpkgs

Nixpkgs is the community recipe collection. The Nix site says “Choose from over 140 000 Packages” at the time of fetch (https://nixos.org/). Flox’s own post, dated 2026-01-03, says “over 120,000” [verify: the two counts differ and neither source says how it counts] (https://flox.dev/blog/nixpkgs-the-big-recipe-book-of-open-source/). Flox’s argument for it: “Nixpkgs maintains more packages than anybody with an order of magnitude fewer maintainers” because recipes share one reviewable language (https://flox.dev/blog/nixpkgs-the-big-recipe-book-of-open-source/).

Substituters and caches

A substituter is “An additional store from which Nix can obtain store objects instead of building them”, often a binary cache (https://nix.dev/manual/nix/stable/glossary). The default public cache is https://cache.nixos.org (https://nixos.org/manual/nix/stable/package-management/binary-cache-substituter.html). Flox explains the lookup: the derivation’s hash is checked against the cache; if the path exists Nix fetches it, and if not it builds locally. Flox calls this move “substitution” (https://flox.dev/blog/nixpkgs-the-big-recipe-book-of-open-source/).

Flox also runs a cache. Nix users add https://cache.flox.dev to extra-substituters and the Flox public key to extra-trusted-public-keys (https://flox.dev/docs/concepts/cuda-catalog-and-cache).

Flakes

The manual: “Flakes are the unit for packaging Nix code in a reproducible and discoverable way.” A flake is a tree with a flake.nix that declares inputs and outputs (https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-flake). That page also warns: “This program is experimental and its interface is subject to change.” (https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-flake). Flox supports installing from a flake: a manifest entry with a flake key accepts a flake installable (https://flox.dev/docs/man/manifest.toml), and a 2024 Flox post says it “probably won’t matter to most Flox users, but will matter a great deal to Nix experts” (https://flox.dev/blog/extending-flox-with-nix-flakes/).

Why Nix is hard

Flox says this plainly, which is useful when a customer already tried Nix:

• Three named obstacles. Flox’s founding post says Nix’s “user experience is unfamiliar and the learning curve is high”, it is so “un-opinionated and flexible” that using it feels like “inventing the universe”, and it is “decentralized by design” in a way that is “a hard sell for the enterprise” (https://flox.dev/blog/why-we-built-flox/).
• It inverts habits. Nix ignores the Filesystem Hierarchy Standard: it “builds everything into /nix/store and creates per-user environments by symlinking relevant store paths” (https://flox.dev/blog/the-experienced-novice-dives-into-nix/).
• Too much surface. “Nix isn’t one thing, it’s a whole thing”, and the surface area can distract from what it solves (https://flox.dev/blog/enterprise-nix-its-time-to-bring-nix-to-work/).
• The wizard problem. In many companies one person maintains all the Nix, which the same author calls “operational risk” that is “untenable” (https://flox.dev/blog/the-experienced-novice-dives-into-nix/).

What Flox adds on top

Flox’s summary of the split: “Nix begins with the build, Flox begins with the environment.” (https://flox.dev/blog/the-experienced-novice-dives-into-nix/). The README adds that Flox “is additive to Nix, not a replacement” (https://raw.githubusercontent.com/flox/flox/main/README.md).

Escape hatches for Nix people

• Nix expression builds. Files in .flox/pkgs/ are written in the Nix language and, per the docs, give “truly reproducible builds” (https://flox.dev/docs/concepts/nix-expression-builds).
• Flakes. Flox’s post says a flake lets you install a version missing from the catalog or apply overrides (https://flox.dev/blog/extending-flox-with-nix-flakes/).
• Existing Nix installs. The install script does not install Flox through Nix, and it will not modify your existing Nix installation (https://flox.dev/docs/install-flox/install).

How to explain it

Advice, with the facts underneath:

• To a developer. You type flox install and flox activate. The Nix store is why the result is the same on your teammate’s machine. Flox says its environments are portable “if I’m on Linux and you’re on macOS” (https://flox.dev/blog/the-experienced-novice-dives-into-nix/).
• To a Nix user. Say: keep your flakes, publish them to a private catalog, and teammates just flox install them (https://flox.dev/blog/enterprise-nix-its-time-to-bring-nix-to-work/).
• To security. The lock records exact store paths per package (https://flox.dev/docs/concepts/environments), and the home page says each environment carries a hash-pinned bill of materials (https://flox.dev/).

Gaps to flag

• Catalog age. The Base Catalog is a sampled subset of packages, and flox show metadata can differ from what flox install serves (https://flox.dev/docs/concepts/base-catalog).
• Flakes are experimental upstream. See the manual warning above (https://nix.dev/manual/nix/stable/command-ref/new-cli/nix3-flake).
• Version drift. The Nix manual pages above were for 2.34.9, while the nixos.org front page offered “Nix 2.35.4” for download (https://nixos.org/). Which Nix version Flox bundles is not stated on the pages read [verify].

Where to go next

• What Flox is: What Flox is
• The company and community: The company and the Nix world