FlakeHub Cache

FlakeHub Cache is a powerful new binary caching concept for Nix that:

1. Enables you to control access at the Git repository level.
2. Uses a flexible and convenient authentication model that doesn’t require juggling access keys.

Using FlakeHub Cache

Pushing to the cache

FlakeHub Cache differs from existing Nix caching solutions because it forbids pushing to the cache in an ad-hoc way. That means no pushing from your laptop or from one of your servers. Instead, only trusted builders are allowed to push to the cache. At the moment, this includes only GitHub Actions runners but other options will be available in the future.

Here’s an example:

jobs:
  build-nix-package:
    runs-on: ubuntu-22.04
    permissions:
      contents: read
      id-token: write
    steps:
      - uses: actions/checkout@v3
      - uses: DeterminateSystems/nix-installer-action@main
        with:
          determinate: true
      - uses: DeterminateSystems/magic-nix-cache-action@main
      - run: nix build

In this configuration:

• The permissions section enables you to authenticate to FlakeHub Cache. No other authentication method, like public keys, is necessary.
• The Magic Nix Cache Action sets up authentication for FlakeHub Cache.

Pulling from the cache

In order to pull from the cache, you need to be properly authenticated in one of two ways:

1. On GitHub Actions runners, authentication happens automatically.
2. As an ordinary user on a laptop or workstation, you need to authenticate using determinate-nixd login.

Access control

Nix caching solutions based on nix-serve serve an entire Nix store as a single monolithic cache and make all store paths in that cache available to anyone with a public key. With FlakeHub Cache, on the contrary, you can grant or deny read access to specific users at the flake level, which affords substantially more granular access control.

Let’s say that you’re an admin for the org omnicorp. You could manage access to your org’s flakes in such a way that, for example:

• Only some trusted users would be allowed to pull store paths associated with the flake super-duper-secure.
• Anyone in your org can pull store paths associated with the dev-environments flake.

Authentication model

FlakeHub Cache authentication is based on JSON Web Tokens (JWTs or “jots”). We currently use GitHub and GitLab as our JWT authentication providers and will support more platforms over time. Down the road, the flexibility of JWTs will enable us to support a wide range of additional authentication solutions, including a variety of single sign-on (SSO) providers.

In contrast, existing Nix caching services use static tokens for authentication. This model places all of the operational burden of authentication on users; with FlakeHub Cache, however, we’ve opted to shift that burden to trusted authentication providers.