Bringing back the Magic Nix Cache Action

A while back, we announced the end of life for our Magic Nix Cache Action, a GitHub Action that uses Actions’ built-in cache to share the results of Nix builds between workflow runs. Nix users responded quite positively to getting a viable Nix binary cache for free and with zero configuration and we were happy to provide it to them. And then we were sad when GitHub announced that the Actions cache was being deprecated in favor of a new (and undocumented) API.

Today, we’re happy to announce that Magic Nix Cache Action is back. GitHub user jchv submitted a heroic pull request to make Magic Nix Cache communicate with the new version of Actions’ cache API. That means that as of the most recent release of Magic Nix Cache you can once again use the Magic Nix Cache Action in your workflows.

Here’s an example configuration:

jobs:
  nix-build:
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
    steps:
      - uses: actions/checkout@v4
      - uses: DeterminateSystems/determinate-nix-action@v3
      - uses: DeterminateSystems/magic-nix-cache-action@main
      - name: Build and cache with Nix
        run: nix build

Limitations

Please be aware, though, that Magic Nix Cache Action continues to have some deep limitations:

1. It provides caching only between runs of a specific workflow in a specific repository and thus doesn’t serve as a standard Nix binary cache available across a wide variety of clients. That means that you can’t, for example, cache some Nix package builds in Actions and make those available to you and your teammates.
2. GitHub Actions’ cache API is not a purpose-built Nix binary cache. Unsurprisingly, its performance is decent but not great.

For most use cases, you should opt for FlakeHub Cache instead, which offers true all-purpose binary caching and dramatically better performance and use Magic Nix Cache Action only when you want better performance between CI runs.

An important caveat

On a similarly sober note, we do need to make something clear. As I said above, the approach provided by jchv is based on a reverse engineering of GitHub’s new caching API. GitHub has not published the Protobuf sources for that API and that means both that there’s a good bit of guesswork here and that the API could change at any time, which could in turn make the new approach nonviable. We at Determinate Systems do hope that this will continue to work for years and years but the rug could in principle be pulled at any time. C’est la vie.

We’d like to express our most sincere gratitude to jchv for their help. Happy (free) caching, everyone!