Formats/Nix

Host and secure your Nix binary cache

Cloudsmith is a managed Nix binary cache that speaks the native Nix protocol, so your nix copy and nix build commands point straight at it. Keys rotate instantly, and NixOS channel proxying keeps builds running through a public outage.

Universal format support

Host your Nix binary cache, managed and secured by Cloudsmith.

  • Use Nix along with 30+ other formats
  • Host container images and ML models alongside your Nix binary cache
  • Bring raw files and NixOS release channels into one centrally managed repository

How we support Nix

Cloudsmith hosts your Nix binary cache as a managed service, with native signing and upstream proxying built in, governed alongside your other formats.
    Public and private binary caches
    Serve NAR and narinfo files over the standard Nix HTTP binary cache protocol, publicly or restricted to authenticated users.
    Signed on every read
    Every repository has its own ED25519 signing key, and narinfo files are re-signed with the current key on every read, so rotation is instant with zero re-signing backlog and multiple keys can be valid at once.
    NixOS channel proxying
    Proxy and cache packages directly from a NixOS release channel, so builds substitute from Cloudsmith instead of hitting upstream every time.
    Native nix copy workflow
    Point your existing nix build and nix copy commands at Cloudsmith directly, with no new upload tooling or self-hosted cache to operate.
    One governed platform for every format
    Nix lives alongside your containers, language packages, and ML models in one repository, giving you a single audit trail across every format you ship through Cloudsmith.

Why teams choose Cloudsmith for Nix

Self-hosted Nix caches mean infrastructure to run and keys to manage by hand. Cloudsmith replaces both with a managed cache that signs, scans and proxies for you.
Without CloudsmithStanding up your own binary cache means running nix-serve or an S3 bucket, and babysitting the infrastructure behind it.
With CloudsmithCloudsmith hosts your public or private Nix binary cache as a managed service, so there is no nix-serve instance or storage bucket to run.
Without CloudsmithSigning keys are usually managed by hand, and rotating one means a backlog of unsigned or re-signed packages to work through.
With CloudsmithCloudsmith signs every narinfo with the repository's current ED25519 key on every read, so rotation takes effect instantly, with no re-signing backlog and support for multiple valid keys at once.
Without CloudsmithRelying on the public cache at cache.nixos.org, or running Nix as a standalone tool, leaves it sitting outside whatever governance covers the rest of your stack, with its own availability and bandwidth limits to accept.
With CloudsmithCloudsmith proxies and caches NixOS release channels directly, so a public cache outage does not take your builds down, and Nix sits inside the same governed platform as your other 30+ formats.

Signs you're ready to switch to Cloudsmith for Nix

If your team is running its own Nix cache infrastructure and managing signing keys by hand, it's a sign the tooling has outgrown what makes sense to self-host.
    Self-hosted cache is a maintenance burden
    Running nix-serve or your own S3-backed cache means patching, scaling and monitoring infrastructure just to serve packages your teams already built.
    Nix sits apart from everything else you manage
    Point tools and per-format caches leave Nix as its own island. Cloudsmith brings Nix packages into the same governed repository as your containers, language packages and ML models.
    Manual key rotation across every cache
    Rotating a self-managed signing key means reworking a backlog of already-signed packages. Cloudsmith signs on every read, so rotation applies instantly with zero backlog.
    Latency for distributed teams
    A cache hosted in one region slows down teams and CI runners elsewhere. Cloudsmith serves packages from edge locations worldwide for consistent build speed anywhere.

Get started with Nix on Cloudsmith

Frequently asked questions

  1. Yes. Cloudsmith hosts a public or private Nix binary cache using the standard Nix HTTP binary cache protocol, so your existing nix build and nix copy workflows point straight at Cloudsmith with no new upload tooling to learn.

  2. Packages are published using the native nix copy command, for example nix copy --to your repository URL. Uploading Nix packages through the Cloudsmith CLI or web app is not currently supported.

  3. Configure a netrc file with your Cloudsmith entitlement token as the password, then reference it in your Nix configuration, or embed the token directly in the substituter URL.

  4. Every repository has its own ED25519 signing key. Cloudsmith signs the narinfo for each package on every read rather than once at upload, so key rotation takes effect immediately across every package.

  5. Yes. Configure a NixOS release channel as an upstream and Cloudsmith fetches and caches store paths on request, then serves them from the cache on subsequent builds.

  6. Yes. Add your repository's ED25519 public key to trusted-public-keys in your Nix configuration before running nix build or nix copy, or Nix will refuse to substitute from the cache even though the request succeeds.

  7. Yes. Cloudsmith replaces a self-hosted binary cache such as nix-serve or a self-managed S3 bucket, so there is no cache infrastructure for your team to patch or scale.

  8. Yes. Nix sits in the same multi-format repository as your containers, language packages and ML models, so you get one governed store instead of a separate tool per format.

  9. The public cache works well for many teams, but its availability and bandwidth aren't guaranteed, which is a risk many compliance-driven teams can't accept. Cloudsmith gives you a managed alternative that speaks the same Nix binary cache protocol, so nix copy and nix build point at it exactly as they would any other substituter.

Formats

There’s more than just Nix on Cloudsmith