Nix binary caches reduced to three HTTP functions enabling any static file host as a store

The core insight is that Nix binary caches require only three HTTP functions to operate: serving a nix-cache-info file, providing narinfo metadata for a store path, and delivering the compressed archive referenced in that metadata. This minimal interface means any static file host, GitHub Pages, Releases, or even pastebins, can act as a Nix store without additional Nix-specific infrastructure. The requirement is simply that the host allows cross-origin requests (CORS) with a permissive policy, which many static hosts already provide by default.

The separation of transport from signature validation is what makes this flexibility possible. Nix signatures cover the store path, nar hash, nar size, and references, but not the URL, file hash, or compression method. This means the archive can be fetched from any location, even a different protocol or domain, without breaking signature validation. Once fetched, Nix decompresses the archive and verifies its nar hash, ensuring the content matches what was signed. This design allows binaries signed by cache.nixos.org to be redistributed through any intermediary cache while retaining cryptographic trust.

The practical implications are significant for decentralized or ephemeral caching. Engineers can now use existing static file hosts (e.g., GitHub Pages) as Nix stores by committing the output of `nix copy --to file://` to a repository. Experimental implementations have already demonstrated this with unconventional backends: Git’s object database (gachix), DNS TXT records, OCI registries, pastebins, and even YouTube videos. These approaches leverage the three-function interface to repurpose existing infrastructure, though some (like DNS or pastebins) require chunking archives due to size limits.

The trade-offs of this approach center on performance and reliability. Static file hosts may not be optimized for large binary downloads, and some (like pastebins) enforce expiry policies that could break long-term reproducibility. However, the flexibility outweighs these limitations for use cases like temporary caches, personal projects, or proof-of-concept deployments. The discovery also highlights that Nix’s design is transport-agnostic by default, which could encourage further experimentation with alternative storage backends or protocols beyond HTTP.