Skip to main content
Determinate Systems logo
Nix-based deployments

Deployments that skip the build and even the evaluation

A traditional Nix deploy has to evaluate your configuration and realise its closure on the target machine, the two most expensive steps in the whole process. FlakeHub does both ahead of time. Your CI pushes pre-evaluated store paths and pre-built closures to FlakeHub Cache, and a single fh apply fetches and activates them, with no local evaluation and nothing to rebuild.

Get FlakeHub Cache (opens in a new tab)Read the deployment docs (opens in a new tab)Contact us
fh apply docs: Deploy with one command

Deploy with one command

fh apply fetches a flake output's pre-built closure from FlakeHub and activates it on the target. One command deploys NixOS, Home Manager, or nix-darwin, with no flake to clone and no expression to evaluate first.
fh apply docs (opens in a new tab)
Pre-resolved store paths: No evaluation on the target

No evaluation on the target

Evaluating a configuration can exhaust memory on constrained devices before a build even starts. FlakeHub evaluates once in CI and stores the resulting paths, so the deploy target never has to.
Pre-resolved store paths
FlakeHub Cache: Nothing left to build

Nothing left to build

FlakeHub Cache holds the pre-built closure for every output your CI pushes. Deploys download exactly what they need and activate it, instead of rebuilding what's already been built.
FlakeHub Cache (opens in a new tab)

NixOS, Home Manager, and nix-darwin

One deployment workflow across system configs, per-user Home Manager environments, and macOS with nix-darwin. The same fh apply covers Linux servers and developer laptops alike.
Closures explained: Built on core Nix primitives

Built on core Nix primitives

Nothing here is a bolt-on. Deployments ride on the derivations, closures, and deterministic evaluation at the heart of Nix, so every machine gets a bit-for-bit identical result.
Closures explained (opens in a new tab)
What reproducibility means: Reproducible from CI to production

Reproducible from CI to production

The closure your CI builds and verifies is the exact closure that lands in production. No drift between what you tested and what you shipped.
What reproducibility means (opens in a new tab)
Docs: Pinned and versioned with SemVer

Pinned and versioned with SemVer

Deploy a specific release or a SemVer range instead of a moving branch, so rollouts and rollbacks target an exact, immutable version of your configuration.
Docs (opens in a new tab)
Docs: Private and access controlled

Private and access controlled

Your configurations and their cached closures are private by default. Only authenticated members of your organization can deploy from them, with no static credentials to leak.
Docs (opens in a new tab)
Trust Center: SOC 2 Type II audited

SOC 2 Type II audited

Built and operated on audited, compliant infrastructure. Satisfies the compliance questions your security team will ask before you ship.
Trust Center (opens in a new tab)

Guides and resources

  • fh: the CLI for FlakeHub

    fh: the CLI for FlakeHub

    The official FlakeHub CLI behind fh apply: deploy configs, add flake inputs, and fetch outputs straight from FlakeHub Cache.

  • Supercharging Nix deployments with FlakeHub Cache

    Supercharging Nix deployments with FlakeHub Cache

    A walkthrough of deploying a Home Manager config on macOS and Linux with fh apply, bypassing local builds and evaluation entirely.

  • Seamless Nix deployments with FlakeHub webinar

    Seamless Nix deployments with FlakeHub webinar (opens in a new tab)

    A live look at deploying NixOS, Home Manager, and nix-darwin with FlakeHub Cache, private flakes, SemVer, and pre-resolved store paths.

  • Up and running with FlakeHub Cache webinar

    Up and running with FlakeHub Cache webinar (opens in a new tab)

    Set up FlakeHub Cache and get the most out of a shared binary cache across developer machines, CI, and your deploy targets.

  • Improved evaluation times with pre-resolved store paths

    Improved evaluation times with pre-resolved store paths

    How FlakeHub skips Nix's evaluation tax so deploys land fast, even on resource-constrained devices.

  • Caching: a Nix concept

    Caching: a Nix concept (opens in a new tab)

    The Zero to Nix guide to how Nix binary caching works and why it makes builds and deploys dramatically faster.

  • Binary caching

    Binary caching

    Share cached Nix artifacts across every machine so nothing gets rebuilt more than once.

  • Nix for CI/CD

    Nix for CI/CD

    Faster, more reproducible pipelines: one-line install, shared caching, and reproducible builds across every runner.

Explore more solutions