FlakeHub Cache is a binary cache with access control that makes sense for teams. FlakeHub’s API and policy engine extend the binary cache to make deployments easy and fast. You’re going to love it.
FlakeHub combines with Determinate’s unified authentication primitives to make a new team member’s onboarding (and offboarding!) immediate and straightforward. No more long-winded “how to set up our cache” documents.
Feel free to contact us on Discord with any questions or requests!
This looks useful for typically larger companies with strict policies that want to purchase supported infrastructure geared toward Nix, and need enforced access control on flakes, caches etc. I once worked for a digital animation company that produced animations for automotive companies, Game of Thrones television series, etc. They were looking for something very similar to this to control the releases and code distribution to teams around the world. Looks like you’re trying to maintain this as a layer over the open source version of nix, and keep contributing back to FOSS nix.
Oh dang, that is a perfect fit! The design of the cache is a collection of “slices”, where each flake (typically but not necessarily, 1:1 Git repository) gets its own slice. The idea here is that access control can be super specific, and in some cases down to precisely a single output of a single flake. You could imagine this being used for ACLs across teams, or countries, or even applying different access control based on export restrictions.
And, yes, definitely. This is in complement to Nix. We want the Nix project to be as good as can be. Like we talked about in our blog post from Monday, Determinate Nix is about providing a “high-policy” distribution to the otherwise traditionally “low-policy” upstream.
In reading the referenced blog post I noticed the phrase “Specific team members need access to specific subsets of flake outputs and artifacts”.
I wish I had access to something like this in previous roles when I was managing SBOM for multiple projects for container builds. But could you provide some more specifics on this use case? It really sounds intriguing.
Sure! The most straightforward scenario is a machine you want to deploy to, but you don’t want that machine to have access to all your flakes and the entire binary cache.
Today, you can create a “resolve only token” for that machine. It’ll be allowed to convert a flake reference like DeterminateSystems/demo/0.1#nixosConfigurations.ethercalc-demo into a specific store path, and download the closure of that store path. That token can’t be used to fetch anything outside of that closure, and it also can’t download any sources, or query any other APIs. This is something you can do today: Deploying with resolve-only tokens
In the future, we’ll expand this to support more robust policies across users/roles/teams. For example, your company might produce software with export restrictions. Or, you might have internal security boundaries where source code shouldn’t traverse between teams, but binaries can. You’ll be able to implement policy to grant fine-grained access to flake sources, outputs, caches, etc. based on rules around their role.