FlakeHub Cache

FlakeHub Cache is a Nix binary cache (opens in a new tab) that works in conjunction with FlakeHub. It has two main features that distinguish it from other Nix caching services:

1. It enables you to control access at the flake (opens in a new tab) level.
2. It uses a flexible and convenient authentication model that doesn't require juggling access keys.

FlakeHub Cache is currently in private beta but you can sign up for the beta here and we'll add you as soon as we're ready:

Access control

Nix caching solutions based on nix-serve (opens in a new tab) serve an entire Nix store (opens in a new tab) 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 (opens in a new tab) 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 (opens in a new tab) (JWTs or "jots"). We currently use GitHub (opens in a new tab) as our JWT authentication provider but will be adding support for GitLab (opens in a new tab) in the near future. Down the road, the flexibility of JWTs will enable us to support a wide range of additional authentication solutions, including SAML (opens in a new tab) and Single sign-on (opens in a new tab) (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.

Pushing to the cache

FlakeHub Cache differs from existing Nix caching solutions because it forbids pushing to the cache in an ad-hoc way. Thus, you can't push to the cache 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 (opens in a new tab) but other options will be available in the future.

In order to push to FlakeHub Cache from GitHub Actions, your GitHub organization needs to be registered for the beta. Once you've been added—you'll be notified via email—you can configure your org's GitHub Actions workflows to use the cache. 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
      - uses: DeterminateSystems/magic-nix-cache-action@main
      # Build default package
      - 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 (opens in a new tab) sets up authentication for FlakeHub Cache.

jobs:
  DeterminateCI:
    uses: DeterminateSystems/ci/.github/workflows/workflow.yml@main
    permissions:
      id-token: "write"
      contents: "read"

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 fh login (opens in a new tab).