July 11, 2018·4 min read·engineeringnixcachesnetworking

Nix cache delivery expands beyond North America and Europe

cache.nixos.org enables all CloudFront edge locations, with published cold and hot cache measurements showing why download locality matters.

An available binary can still be expensive to use when downloading it takes most of a deployment. Graham Christensen announced on July 11 that cache.nixos.org now uses all AWS CloudFront edge locations. The change extends delivery beyond the previously enabled locations in the United States, Canada, and Europe. It addresses the network cost of obtaining existing results, separately from the work of producing those results.

His accompanying technical report gives Sydney measurements for a 1,660.95 MiB graphical ISO closure. Download time falls from 2,326.957 seconds before the change to 376.014 seconds with a cold cache and 25.328 seconds with a hot cache. Those are observations from the reported experiment, rather than a promised duration for every user or closure.

I find this significant for declarative infrastructure because obtaining the described system is part of using the description. A configuration can select an available build result while the distance to that result still makes deployment inconvenient. Improving delivery can change the usefulness of the existing package infrastructure without changing a package expression.

Availability and delivery time differ

The Nix 2.0 release notes describe HTTP binary caches as implementations of its store interface. Clients can obtain paths from those stores instead of building every requested result locally. That mechanism already exists. The July announcement changes where the public cache serves its traffic, rather than introducing substitution itself.

This is an important distinction when discussing the result. A package can have a binary substitute before and after the change. The selected derivation and the cached path need not change for the user to receive it more quickly. The affected operation is transfer of the available result, so attributing the entire improvement to a faster compiler or builder would identify the wrong mechanism.

The reported cold and hot cases also deserve separate treatment. A single statement that downloads now take less than half a minute describes only the hot-cache ISO observation in the published experiment. The cold-cache measurement is substantially different. The measurements show more than one state of the delivery system, so preserving their labels is part of reporting them accurately.

The service combines S3 storage with CloudFront distribution. Storage and edge delivery have different responsibilities in that arrangement. The announced change concerns the distribution settings. It does not require claiming that every object moved into a new package format or that the underlying archive became a different kind of Nix store.

Metadata operations participate in cache use

Nix 2.0 extends the store interface so commands can inspect remote caches as well as local paths. nix path-info can use an HTTP store through --store. Low-level store-listing operations can inspect contents, and nix log can try a substituter when the build log is unavailable locally. These operations show that cache interaction includes more than one large payload download.

The same release adds HTTP/2 support and describes it as improving binary-cache lookups. It also retries downloads on many HTTP errors. Those client changes address request handling and temporary failures, while the July infrastructure change addresses delivery locations. The mechanisms can affect the same user-visible workflow without being interchangeable explanations.

This distinction helps interpret what an operator sees. A period spent resolving information about paths is different from a period transferring their contents. A complete result includes both, and Nix exposes operations around the store that can explain what it is handling. The geographical distribution announcement should not be reduced to a claim about processor speed merely because it improves the time required to obtain a system.

Another relevant command is nix why-depends. It explains why one store path belongs to another closure by showing a chain of references. That supplies a separate way to understand why a download contains a particular dependency. The CDN change reduces delivery cost, while dependency inspection explains the contents that create that cost.

Configuration terminology in Nix 2.0 reflects this broader role for stores. The older binary-caches option becomes substituters, with the old name retained for compatibility. A substituter can be an arbitrary supported store URI, rather than necessarily this public HTTP service. That means the public-cache improvement benefits one important configured source without defining the performance or availability of every other store a client may use.

Faster transport retains acceptance rules

The trust policy remains a separate part of substitution. Nix 2.0 records and propagates signatures for store paths and requires signatures for binary substitutions by default. Its release notes distinguish that evidence from the ultimately trusted marker assigned to local builds, which does not travel when a path is copied to another store.

A delivery improvement can therefore preserve the client question of whether a result is acceptable. The edge location supplying the bytes is not itself the complete trust decision. The receiving package manager still applies its configured acceptance mechanisms. Faster retrieval and trusted substitution describe different properties of the same transfer.

Content-addressed paths have their own documented rule, because their content identifies them in the relevant way. That exception also belongs to the package manager model. It does not follow simply from placing a cache behind a larger set of network locations. The infrastructure change operates within the existing distinction between locating bytes and accepting a store path.

I regard this as a useful example of where infrastructure work can improve adoption. The package descriptions and build results may already be adequate, while the delivery arrangement makes them costly for some users to consume. Addressing that cost extends the practical reach of the work already represented by the public cache.

The published measurements give the announcement a concrete scope. They identify one closure, one reported location, and separate cold and hot observations. Nix already provides the store interface and trust rules around that retrieval. Enabling the wider edge distribution changes the transport part of that arrangement while leaving those package-manager responsibilities distinct.