Cachix

Last updated: Oct 30, 2026

---

Rationale

Cachix is the hosted binary cache that Fluid Attacks uses for Nix. Each job pushes the derivations that it builds to one of the private caches of Fluid Attacks. Each later job that uses the same cache downloads these derivations and does not build them again. Jobs that run only on the protected branch use the trusted cache of Fluid Attacks. Jobs of all the other branches use a different private cache.

These are the primary reasons why Fluid Attacks selected it and not other alternatives:

• It is a hosted service that its team built only for Nix. There is no cache server to operate. The client is one command that configures the cache and pushes new store paths when they appear.
• It serves cryptographically signed store paths. The machines of Fluid Attacks trust only the public keys of the caches that Fluid Attacks configures. Thus, Nix does not substitute a path that one of these keys did not sign.
• It supports private caches with authentication tokens. Thus, Fluid Attacks can cache all that it builds in the monorepo without public exposure.
• It integrates with GitLab CI and with the Batch jobs that run Nix, because it uses only the Nix configuration that the job templates and container images of Fluid Attacks already have.
• It operates for the two architectures where the jobs of Fluid Attacks run. This is because Nix caches each store path for each system, and the runners of Fluid Attacks build on x86_64 and aarch64.
• Flakes integrate with it easily. This is one of the reasons why Fluid Attacks selected Nix Flakes and not other environment managers.

Alternatives

As the CI of Fluid Attacks changed, Fluid Attacks became more interested in a cache that is nearer to the runners. These are the approaches that Fluid Attacks examined. The list starts with the approach that is most interesting for the requirements of Fluid Attacks.

Local Nix store on a persistent runner

• Jobs would have two stages. A build stage puts packages in the local Nix store of a runner, and an execution stage uses this store again. Fluid Attacks would make the runner on demand and keep it for some time after it becomes idle.
• It would remove the round trip to a remote cache and decrease the data transfer costs.
• The cache would continue only while the machine continues. Thus, the first job after a cold start would build everything.
• If Fluid Attacks uses this approach, build and execution must be separate. At this time, they occur in the same job.

Pre-built container images per execution flow

• Each flow would run from an image that already has everything that it must have. Thus, a cache would not be necessary.
• It is good for production workloads, for example, Batch jobs, which already run from a purpose-built image.
• For development jobs, the team thinks that it is too expensive because of its complexity and maintainability.

Usage

Fluid Attacks uses Cachix for these tasks:

• To substitute the Nix derivations that each GitLab CI job must have, and to push the derivations that each job builds to the cache that agrees with the trust of its branch. Thus, the next jobs that use the same cache do not build them again.
• To substitute the Nix derivations that the Batch jobs of Fluid Attacks and their container image must have, from the trusted cache.
• To trust the public key of the cache in the Nix configuration of the CI container image of Fluid Attacks, next to the public cache of the Nix project.

Fluid Attacks does not use Cachix for these tasks:

• To cache container images. Fluid Attacks publishes them to Amazon ECR and Docker Hub.
• To cache package manager downloads, for example, pnpm stores. GitLab CI caches them in S3.