Flakes: understanding the most used (and most debated) feature in the Nix ecosystem

There is a situation in the Nix ecosystem that deserves explanation before commentary. A feature now adopted by most Nix users, and recommended by default in a large share of open source projects, still carries the official “experimental” label eight years after introduction. That feature is flakes. At HeBeKo we regularly work with Nix environments for clients, and this status ambiguity comes up every time technical teams evaluate the tool. This article sets out the terms of the debate without sidestepping its conflictual side.

The problem flakes solve

Nix stands out from other package managers with a strong promise: giving the same expression to two different machines must produce a strictly identical result, bit for bit. That promise is one of the main arguments for adopting Nix in the enterprise, especially for teams that care about traceability and compliance of production environments.

Before flakes, that promise still had a gap. Nix projects relied on channels: global, mutable channels that could differ from machine to machine, and on a search path (NIX_PATH) whose resolution depended on the local environment. Two collaborators working on the same repository could get different build results without changing any code.

What flakes bring in practice

flowchart LR
    A["flake.nix<br/>declares inputs<br/>(nixpkgs, third-party flakes...)"] --> B["flake.lock<br/>pins each input<br/>to a precise commit"]
    B --> C["Bit-for-bit reproducibility<br/>nix develop produces the same<br/>environment everywhere"]

In 2019, Eelco Dolstra, creator of Nix, proposed flakes in response. The idea rests on four elements:

A flake.nix file that explicitly declares a project’s dependencies.
A flake.lock file, generated automatically, that pins each dependency to a precise commit.
A so-called “pure” evaluation, independent of environment variables and local machine state.
A standardised output structure (packages, devShells, nixosConfigurations) that makes any project immediately understandable by another team, without extra documentation.

The practical effect for an organisation is significant: clone a repository and run nix develop to get a development environment identical to the author’s, with no manual install steps. That is a real gain in reliability of technical environments, worth acknowledging before turning to disagreements.

A lasting disagreement in the community

That gain never produced consensus in the Nix community. The disagreement matters because it directly informs precautions for enterprise adoption.

First friction: how the feature was introduced

Part of the community reacted badly to the fact that the initial RFC for flakes was abandoned mid-way, while the feature itself was still integrated into Nix. Other contributors were not opposed in principle to shipping experimental features without a formal RFC (common practice in the project), but criticised that flakes never really behaved as experimental: little rollback, little deep redesign, and adoption so fast that any breaking change became politically hard to own.

Second friction: contested design choices

flowchart TD
    P["Your project"] --> A["Flake A<br/>nixpkgs @ a1b2"]
    P --> B["Flake B<br/>nixpkgs @ c3d4"]
    P --> C["Flake C<br/>nixpkgs @ e5f6"]
    A --> W["Three distinct nixpkgs copies<br/>build time and disk space potentially multiplied"]
    B --> W
    C --> W

Several users report concrete operational friction. Each third-party flake can ship its own nixpkgs version: if a project depends on three unharmonised third-party flakes, each may bring its own nixpkgs at a different commit, multiplying build times and disk use. Tight coupling with Git is also a frequent trap for newcomers, who must git add every change before rebuilding or see it silently ignored. These points affect development time and should be anticipated in a professional adoption.

Third friction: a design seen as too specific

Some critics argue flakes were originally designed for a single client’s needs, and that prolonged experimental status reduces the chance that implementation gaps will be fixed. The argument can be polemical, but it recurs in technical discussions and cannot be dismissed without examination.

The defenders’ position

Faced with these critiques, flake advocates have substantial arguments. Graham Christensen, co-founder of Determinate Systems (where Eelco Dolstra also works), has long argued that flakes are already stable in practice, and that the experimental label should never have lasted this long. His summary: the most common critiques (nixpkgs duplication, lack of native cross-compilation support, lockfile format) are either misframed, unrelated to flake design, or already being addressed. His company also ships a Nix distribution where flakes are marked stable by default.

Add a hard-to-dispute fact: most current Nix users also use flakes, de facto usage that weighs heavily when judging real maturity.

The institutional compromise: RFC 0136

Nix project governance tried to exit the impasse with RFC 0136. It first sets general principles for Nix evolution, then defines a progressive stabilisation plan: first the CLI, then flakes themselves, whose final design still needs another RFC.

The author explicitly asks “flake sceptics” not to reopen the design debate, to avoid reproducing long, inconclusive discussions from the past. That precaution alone shows how much tension has accumulated.

The RFC also explicitly recognises that flakes are widely adopted by new Nix users, de facto majority usage across the ecosystem, which sharply limits room for any substantial redesign.

Recommendations for enterprise adoption

At HeBeKo we recommend the following for organisations evaluating flakes:

Adopting flakes is not, at this stage, a high-risk technology choice. No serious stakeholder, including critics, seriously contemplates abandoning them.
The “experimental” label mainly protects against targeted breaking changes, not against removing the feature. Explicitly enable (experimental-features = nix-command flakes) and follow announced lockfile evolutions.
Git coupling is the main friction for teams new to Nix. An unstaged change does not exist for the tool.
Third-party dependencies need particular vigilance, especially poorly maintained ones, often a larger risk than flake design itself.

Conclusion

The flakes debate is not about to close, and its short-term outcome is uncertain. Both sides defend a legitimate demand: rigor in the stabilisation process on one side, recognition of already massive usage on the other. For an organisation evaluating Nix today, the essential is to understand that context rather than ignore it. That understanding lets you anticipate real friction instead of discovering it mid-project.

HeBeKo helps teams adopt NixOS and flakes in production. See NixOS at HeBeKo or contact us.

---

Sources