The Magic Nix Cache, a GitHub Action for speeding up your Nix workflows

We at Determinate Systems are excited to announce the Magic Nix Cache, a GitHub Action that can dramatically speed up your Nix workflows. It uses the GitHub Actions Cache API as a repo-level Nix binary cache, it automatically pushes any newly created Nix store paths during workflow runs, and it gracefully handles any rate limiting by the Actions Cache API. We’re confident that this will provide immediate zero-cost benefits to Nix projects of all kinds.

To enable it:

- uses: DeterminateSystems/magic-nix-cache-action@main

For a more detailed intro, see the announcement blog post.

40 Likes

Yes! This is awesome! Looking forward to near-instant nix flake check runs in my workflows :slight_smile:

3 Likes

I tried adding the one line of yaml to my workflow, but everything is still downloaded from cache.nixos.org. How is nix supposed to know about the local binary cache daemon? Do we need to configure this explicitly when not using the DS action to install nix?

1 Like

It uses cache.nixos.org as its upstream cache by default (though you can select a different one). See the available options. The Magic Nix Cache explicitly avoids caching anything that it fetches from the configured upstream cache.

You don’t need to explicitly configure Nix because the Action updates your Nix configuration to use the running daemon as a substituter (see this line), and it does so regardless of how you install Nix in the environment.

3 Likes

Hmm, why can’t we cache also the store paths that were fetched from the cache? It would at least reduce traffic to cache.nixos.org and instead fetch from an internal github resource.

1 Like

While GitHub is pretty generous with cache space (see here), it’s not unlimited. The Magic Nix Cache Action strives to be parsimonious about what it caches, and when it “knows” that it will be able to fetch rather than build something in the future, it opts not to cache.

6 Likes

The approach seems to be quite similar to what this project is doing:

2 Likes

Currently, I am snapshotting /nix/store instead of saving individual derivations. I was going to build this exact project to improve caching :sweat_smile: I guess less work for me :wink:

It’s quite likely that I’ll keep snapshotting as an optional feature, I assume it is more performant for larger builds

3 Likes

would there possibly be a forgejo-compatible version in the future?

4 Likes

Nice! I was about to switch one of my projects to it, but then reminded myself that I already have cachix intergration in that project (which I want anyways). There is probably little point adding the magic-nix-cahe-action in that case, is there?

Hi @nomeata I work at Determinate Systems :wave:

You may well see some benefit. The Magic Nix Cache uses GitHub cache infrastructure which means artifacts from prior builds are cached and available from infrastructure directly adjacent to the GitHub builders.

I’d certainly be interested to see what benefits you see after several build cycles with the Magic Nix Cache enabled :+1:

1 Like