Cachix makes independent Nix binary caches easier to publish

A package collection has to choose defaults, but not every user needs the same build. The Cachix launch article makes that disagreement part of its case for hosted binary caches. Domen Kožar describes differences over minimal packages, optional capabilities, and maintenance complexity. His answer is to let distinct choices coexist in separate places that can still distribute their build results.

Kožar announced Cachix on June 1 as Binary Cache as a Service. Saving repeated build time is one motivation, but he gives decentralization particular weight. A usable cache outside the central package set changes which work can be shared conveniently, even when that work does not meet the preferences or inclusion requirements of Nixpkgs.

I am interested in declarative infrastructure partly because a configuration can state its chosen inputs and options. Distribution of the resulting builds should not require every configuration to choose identical defaults. Cachix addresses the operational work of making those separate choices available as binaries.

The package set and the cache have different jobs

The launch article describes Nixpkgs as the place where many developers contribute updates that receive coverage from the global cache. It also identifies projects that may not fit there, including software with frequent releases or requirements that differ from those of Nixpkgs maintainers. The argument is about where a build result can be shared, without requiring every package description to enter the same collection.

This separation is useful when evaluating the service. A binary cache does not decide every option in a package expression. It makes already built results available to clients that request the relevant paths. Hosting a cache can therefore support a package set with its own decisions, while the client still evaluates the descriptions that select those results.

The launch article also contrasts package-granular caching with caching an entire continuous-integration build. A pipeline can reuse independently cached package results instead of treating the complete build as one indivisible artifact. This matters when part of a build changes while other requested packages remain reusable.

That is the resource-saving argument in a more precise form. A cache does not remove the need for somebody to perform the build. It provides a way for another compatible request to reuse the available result. The benefit depends on which paths the client requests and which results the cache has, rather than on the mere presence of a hosted service account.

Nix already supplies the transfer model

The Nix 2.0 release notes describe binary caches as implementations of the general store interface. An HTTP cache can supply store information and paths, while local filesystem and S3 caches provide other storage arrangements. The hosted service enters an ecosystem that already has a protocol and client operations for consuming binary substitutes.

That distinction limits what is new in the announcement. Cachix is offering a hosted operational service for caches. It is not announcing that Nix has only now gained binary caching or that every consumer must replace the package manager with a service-specific installer. The distribution mechanism and the service that operates it are separate components.

The launch discussion makes the consumer boundary explicit. Asked whether everyone using a cache needs an account and the Cachix tool, Kožar says consumers only need the corresponding nix.conf changes. He describes cachix use as making that configuration change without authentication. The statement is part of the June 1 discussion, rather than a claim about an interface added later.

This is significant for sharing a build with somebody who only wants to consume it. Publication can require service-side work without making every recipient a participant in that publication workflow. Configuring the package manager to use the cache is the relevant consumer operation described in the announcement thread.

Acceptance still requires trust

Nix 2.0 documents signatures as part of store-path transfer. It retains signatures for local paths and propagates them when copying paths between stores. Locally built paths can be signed with configured keys. This supplies an acceptance mechanism for results obtained from another store, including a cache operated outside the central infrastructure.

The same notes distinguish the local ultimately trusted marker, which does not propagate when a path is copied. A result built locally has a local reason for acceptance. Another machine needs its own reason, such as a signature it trusts. Hosting the bytes is therefore only one part of making them useful to a receiving client.

Substitutions require signatures by default in Nix 2.0, a policy the release says NixOS already used. Content-addressed paths have a separate rule because their identity can be established through content. These distinctions prevent the phrase shared cache from implying that a client automatically accepts every file an arbitrary server offers.

For an independent package set, the cache configuration and trusted keys are consequently part of its distribution arrangement. They describe where results can be found and whose signatures are acceptable. The hosted service reduces operational work, while the package manager retains the documented acceptance rules.

I regard that as a useful division of responsibility. A team can choose where to host its results without treating all hosting destinations as interchangeable trust decisions. The explicit configuration is consistent with the reason I find declarative systems useful in the first place.

Sharing builds does not settle package policy

Kožar illustrates disagreements over packages that enable many capabilities by default and packages that remain minimal. He also discusses whether a build system should expose configuration choices such as cross compilation or library substitution. Those are choices about supported use cases and maintenance cost. A cache can distribute the resulting variants without proving that one choice belongs in every central package definition.

This gives decentralization a practical meaning. Contributors can publish work that follows their requirements and allow interested consumers to use it. The arrangement does not require the central collection to accept every variation or to keep its binary infrastructure responsible for every independent release schedule. It reduces the pressure to resolve unrelated use cases through a single default.

The service also cannot make different build inputs equivalent merely by storing their outputs together. The package manager still selects the paths corresponding to the evaluated descriptions. A published variant is useful when a consumer asks for that variant. Stating the intended package configuration remains necessary even when obtaining the resulting binary becomes easier.

The launch therefore concerns an infrastructure constraint on experimentation and distribution. Maintaining a package expression outside Nixpkgs is only part of making it convenient for others. Without available results, recipients may have to build it themselves. A hosted cache gives the publisher another way to supply those results without operating all of the cache infrastructure.

The store interface also provides inspection operations useful around publication. Nix 2.0 can obtain a build log from a substituter when the log is unavailable locally. Its path-information command can target a binary cache, and its store-listing operation can inspect the files of a cached path. These capabilities let a recipient investigate the available result without reducing every question to another local build. The release describes cache support for logs and content listings as part of the store abstraction, so a distribution service can participate in more of the development workflow than downloading the package payload alone.

Cache availability and reproducibility remain distinct

Nix 2.0 describes separate support for pure evaluation and binary reproducibility. Pure evaluation restricts undeclared external influences, such as environment access and unpinned fetches. Build-round comparison and a diff hook address differences in output from repeated builds. A cached result does not replace either mechanism.

This distinction matters to the interpretation of a fast installation. Receiving a binary demonstrates that a suitable result was available and accepted under the client rules. It does not by itself demonstrate that repeated evaluation always chooses the same inputs, or that independent executions of the builder produce identical bytes. Those are additional properties with their own mechanisms.

The launch article makes the immediate goal narrower and concrete. Cachix aims to save waiting and compute through shared package results, while supporting work that does not fit one central package collection. The June discussion explains that consumers can participate through cache configuration. Together with the existing store and signature model, that describes how independent package choices can become easier to distribute as usable binaries.