The binary-caches.json format

The binary-caches.json file configures the agent to use a binary cache.

A binary-caches.json with a single pushable cache looks like:

{ "mycache": (1)
    { "kind": "CachixCache" (2)
    , "publicKeys": ... (3)
    , ...
    }
}
1 An identifier for the cache. It has to be consistent with your other agents (if any). In case of Cachix, it must match the name of the cache; for example the mycache part from mycache.cachix.org.
2 A kind field to distinguish between cache types. Values: CachixCache or NixCache (since agent 0.7.1)
3 Further details about the cache.

Top-level dictionary

The top-level object represents a dictionary from cache names to objects with the cache’s details and secrets.

Multiple caches can be specified this way. Currently the cache name in the dictionary is also used directly as the Cachix cache name.

{ "mycache": ...
, "some-other-cache": ...
}

CachixCache

The name for a cache is taken from the key in the top-level dictionary, such as mycache in the example.

The details of a cachix cache can be specified with the following fields:

kind

A field of type string with the value CachixCache.

authToken

An optional field of type string.

This is a secret token to authenticate the agent to cachix.org.

This field should be omitted when configuring a publicly readable Cachix cache with a local signing key (as configured in signingKeys).

It is required when the cache uses a Cachix managed signing key via Write token.

publicKeys

A list of strings.

These are required to verify the integrity of cached store paths and to accept them into the Nix store. They are the public counterpart to the signing keys.

You may look up the public keys by going to <cache-name>.cachix.org.

A public key looks like mycache.cachix.org-1:WsUIffActpYsfyxIZrfm6OXRHdNHkHk+X/lUsDTGtJS=

signingKeys

A list of strings.

Omit when using a Write token instead of a local signing key. Otherwise, this is the cache-specific secret key to sign store paths.

You can find it in ~/.config/cachix/cachix.dhall or your key backup after following the setup instructions on cachix.org.

The keys are in Base64 format.

Only a single signing key is currently supported.

NixCache

Since agent 0.7.1

The details of a generic Nix-supported cache can be specified with NixCache.

The Nix manual has more information about operating an S3 binary cache.

You may use existing keys or you can use the nix-store --generate-binary-cache-key command to generate keys for a new cache.

kind

A field of type string with the value NixCache.

storeURI

The Nix Store URI to use when accessing the cache. For example

s3://my-nix-cache?region=us-east-1&profile=my-agent-cache-credentials

where my-nix-cache is the name of the bucket and my-agent-cache-credentials references an entry in ~/.aws/credentials in the agent’s home directory (typically ~hercules-ci-agent/.aws/credentials) AND in the root directory (~root/.aws/credentials). The latter is for nix-daemon, which is what most installations use.

publicKeys

A list of strings.

These are required to verify the integrity of cached store paths and to accept them into the Nix store. They are the public counterpart to the signingKeys.

signingKeys

A list of strings.

This is a cache-specific secret key to sign store paths.

The keys are in Base64 format. As of writing they are Ed25519 keys, where a signing key is about 88 characters after the colon. A public key is half as long.