Cloudsmith now supports hosting public and private Nix binary caches. Teams that use Nix and NixOS can point existing nix copy and nix build workflows at Cloudsmith without any additional tooling.
(Note: Nix format support is currently in Early Access.)
Nix builds work differently from most package ecosystems. Initiating a build in Nix begins with an evaluation of all the inputs that go into the build. This includes source code, dependencies, and build instructions, and each item gets hashed. The evaluation output is a derivation (a .drv file), which is a build recipe that describes what’s in the build. Nix then hashes the derivation to compute the package’s store path. Because downloading a pre-built version is faster than building from source, Nix then asks its substituters (remote binary caches like the default cache.nixos.org) whether that store path already exists. If it does and is signed by a key that Nix trusts, then Nix will download it. If it doesn’t exist, Nix builds it from scratch.
Nix users can pull prebuilt nixpkgs packages from the public cache, but their own builds require a private binary cache, which is typically self-hosted. Relying on the public cache means accepting availability and bandwidth limits, which may not meet the needs of compliance-focused teams. Self-hosting a private cache with nix-serve or S3 means patching, scaling, and on-call duty for infrastructure that only serves packages.
Cloudsmith supports upstreams for Nix release channels. You must configure a separate upstream for each channel you want to use.
The first time you request a store path that Cloudsmith doesn’t have, it fetches the package from the configured NixOS channel, caches it, and serves it. Subsequent pulls are served from Cloudsmith’s cache, so builds are fast and keep working during a cache.nixos.org outage.
You can also push new Nix builds to a Cloudsmith repo, which then functions as a private Nix binary cache, but without the overhead tax of self-hosting.
Where other ecosystems use package name and version number to identify packages, Nix uses a cryptographic hash to identify and verify them. Cloudsmith signs each package’s narinfo with the repository’s ED25519 key on every read, and Nix verifies that signature against trusted keys. Because signing happens on every read rather than once at upload, key rotation takes effect immediately, with no backlog of packages to re-sign, and multiple keys can be active and signing simultaneously.
To get started using Nix with Cloudsmith, you can create a dedicated Nix repository. Add that repo to your Nix extra-substituters list, and the repository’s public key to extra-trusted-public-keys. This configuration means Nix treats Cloudsmith like cache.nixos.org. To proxy a public channel, add that as an upstream to the repo.
For private repos, authenticate with an entitlement token in a netrc file. Push Nix packages you build locally to your Cloudsmith Nix repo using nix copy --to. Add the --no-check-sigs flag because locally built packages are unsigned and Cloudsmith handles signing on read.
For detailed setup instructions, see our Nix documentation.
Cloudsmith allows you to consolidate cached Nix packages in a single, cloud-native environment with multi-format repositories. Teams no longer rely on public cache availability, or pay the operational tax of self-hosting. Upstreams cache public channel packages in Cloudsmith for fast, reliable pulls.
Nix packages often sit outside the access controls and audit logging that cover the rest of your software supply chain. Bringing Nix into a Cloudsmith workspace, with 30+ formats in multi-format repositories, lets you govern Nix packages with the same access controls, entitlement tokens, and audit logs that you use on the rest of your software supply chain.
Check out the Nix format page for more information about using Nix in Cloudsmith.
