Hardware-attested Nix builds! Blog at: garnix.io/blog/atteste...
18.12.2025 19:23
👍 3
🔁 0
💬 0
📌 0
On it
Thanks a lot for having had me on the podcast!
“It works on my machine!”
If you’ve ever uttered those words, then come & learn about Nix. Julian Arni joins me this week to discuss the tool that attempts to solve the problem of reproducible builds once and for all...
youtu.be/maw2hptpErI
Here's the blog post with the announcement: garnix.io/blog/garnix-...
The code is open source, and writing new modules is always possible. If this is something you're interested in doing, get in touch!
There are a lot of other advantages to this system, especially related to the hosting component, that we'll talk about in a future blog post.
In fact, you get to try out the system before even touching the repo. But in the end, we can generate a PR for you with this information captured in a flake.nix, so it's in version control, and so you can use it locally.
The way we did this, for the Nix users, is by using the familiar module system, but developing types and fields that are oriented towards making really nice HTML forms out of them. So you can fill things out with nice autocomplete, inline documentation, etc., and without touching a Nix file.
To focus in on just the first one of those: not only do you have to do no configuration at all in order to get build caching between CI runs, but the caching safely and transparently works across *all* users. If *someone* built it, you don't have to. This is leagues ahead of the alternatives.
But under the hood, we are using Nix (and NixOS) to make sure you get a lot of the benefits of that stack:
- Effective and automatic *global* caching
- Easy local reproducibility
- Development shells
- Deduplication of concurrent builds
And much more
We're releasing garnix modules today! At first blush, this looks a lot like the type of PaaS you are already familiar with: Heroku, Render, or Fly. You pick a repo, give us a couple of details about it, and we build, test and deploy it
Ah - any suggestions about how exactly we could convey that better? With a section of the docs?
Well, the configuration is in source (garnix.io/docs/yaml_co...). But the defaults are sane (build all packages, nixosConfigs, checks, devShells, ..., but only on x86_64-linux), so usually you can get away with no config at all.
If you don't use flakes, garnix.io/blog/convert... shows how to enable them (you can also keep using non-flake nix as well if you want).
garnix does the entire CI for you, without using GitHub actions (though you can integrate it: garnix.io/docs/gh-acti...). You just need to have a flake.nix, and enable garnix in your repo (it's a GitHub app).
Reminder that garnix has a generous free tier, is faster than GitHub actions with Magic Nix Cache, and will still be working come Feb 1st determinate.systems/posts/magic-...
It does ignore them :)
So instead of trusting n users for n caches (plus GitHub etc. which also usually gets the key), you just need to trust garnix for n caches.
The model is very different than cachix. cachix gives the owner the key, so they can upload anything, and you have to trust them. With garnix users don't get to upload directly - only things that garnix itself built are uploaded.