Determinate is the future of Nix today: Wasm, provenance, and flake schemas

Nix is a tool that we all know, love, and benefit from immensely. But as a long-standing user and contributor, I think that the upstream Nix project has long been suffering under the weight of stagnation and an inability to rally around a coherent vision for the future. When we at Determinate Systems released Determinate Nix 3.0 a year ago, we set out to change the tenor of the Nix ecosystem and push the envelope decisively forward—our vision on our terms.

We did this because we see Nix as more than just a build tool or developer tool or configuration management system. It does those thing with quiet competence, sure, but we see it above all as a platform that could act as the substrate for the future of computing—if we think big and act boldly.

Why? Because Nix stands outside other tools, letting them shine but also magnifying their power. Nix isn’t opinionated about what you’re making or doing. You follow its rules and you reap the voluminous benefits of reproducibility. This simple formula has given Nix a vitality that has fueled its 23-year history of success and growth. But potential and reality are two different things, and we’re narrowing the gap.

What’s landing in Determinate Nix

This week, we’re shipping some of our most important work to Determinate Nix thus far, tackling tough problems surrounding evaluation, supply chain integrity, and the extensibility of flakes. I’m confident that these changes will prove to be the most transformative since the introduction of Nix flakes.

Wasm and WASI support

The most radical change is support for WebAssembly (Wasm) and WebAssembly System Interface (WASI) in Determinate Nix. I believe that this will open up vast new possibilities for Nix, both in Nix evaluation (Wasm) and realisation (WASI).

Across years of working together before we founded Determinate Systems, Eelco Dolstra and I saw a lot of fascinating uses of Nix in the wild, especially at larger companies that need to scale Nix to thousands of developers. We saw teams do things like creating their own replacement for Nixpkgs’ standard environment (stdenv), implementing Bazel by hand in Nix (though often not terribly well), and authoring elaborate machinery in Nix to deal with their monorepos.

A sore point for each of those teams was how hard it was to write high-performance, well-tested Nix expressions to implement their custom logic. With Wasm and WASI, teams with this pain point will be able to re-architect this logic in full-fledged languages, like Rust, that offer a full suite of tools for making exceptional software, and then seamlessly call that software from Nix. All of these are now possible with Wasm:

• Parsing go.mod and go.sum files for Go at evaluation time
• Parsing and generating YAML without needing derivation wrappers
• Implementing proper IP address management for your router, right in your flake

And with WASI, which, unlike plain Wasm, provides filesystem access, you can now do things like create derivations in languages that aren’t Nix.

I believe that Wasm and WASI will be like a power tool for Determinate Nix users, shifting responsibility away from the Nix language and Nixpkgs lib functions and toward more robust languages.

Eelco will have much more to say about Wasm and WASI in a blog post tomorrow.

Provenance

I’ve been greatly pleased to see the world of software engineering “catch up” to Nix in some ways. In the domain of dependency management, I see tools like pnpm for JavaScript and uv for Python recording hashes and thereby dramatically improving packaging precision. In the supply chain domain, I see a number of tools providing granular representations of artifacts’ dependency graphs, which Nix has offered for many years via commands like nix path-info.

But thus far, Nix’s provenance story has been restricted to representing graphs of derivations. That’s certainly a powerful component and building block but it doesn’t tell you much about where a store path comes from more concretely. Was it store path built locally? Built on a CI machine then pushed to a cache? If so, which machine and which cache?

As of recently, Determinate Nix has experimental support for storing provenance data about store paths—data about where, concretely, that store path came from. And this data is signed and stored automatically for store paths pushed to FlakeHub Cache. Check out our recent webinar on SBOMs and provenance in Determinate Nix for a lot more detail.

At Determinate Systems, we’re currently using this for things like attaching GitHub Actions workflow data so that we know exactly when and where a path was built. In the future, we’re excited to extend this to TPM-attestable information (Trusted Platform Module) about the identity and condition of the machine that built the store path too, making it possible to trust and distrust specific build machines.

I’ll have more to say about this in a blog post later this week.

Flake schemas

The work we’re doing is focused on making Determinate Nix a paradigm-defining tool for the next decade. And we’re making it flexible enough for teams to shape it in the ways they need to be successful. But historically, flakes have forced flake outputs into an inflexible mold, with a static, pre-set list of known output types.

We are changing that with the introduction of flake schemas in Determinate Nix. Announced some time ago and finally shipping this week, schemas will enable you to define your own flake output structures in semantically meaningful ways.

Are you using Nix to build and share things that don’t conveniently fit into packages, nixosConfigurations, devShells, or a handful of others? Now you can write a bit of Nix code and people inspecting your flake using nix flake show and other means will be able to get meaningful information about those outputs—a vast improvement over unknown.

Luc Perkins will say much more in a blog post later this week.

Where this is all going

Wasm and WASI in Determinate Nix will free users to express complex expression and build logic unconstrained by the limitations of the Nix language. Provenance will mean that Nix store paths aren’t just reproducible but rather verifiable, all the way down to the hardware that built them. And flake schemas mean that the structure of your Nix projects is no longer pre-ordained, which will make individual flakes much better citizens of a more decentralized Nix ecosystem.

What we’re releasing right now is more than a set of features—it’s the next phase of Nix as a platform. Nix has spent 23 years showing that a qualitatively better model for building and distributing software is possible. We are extremely excited to continue pushing the limits of that model, making Nix expressive enough for the most complex use cases, trustworthy enough for the most security-conscious orgs, and open enough to grow in directions we can scarcely imagine.