Deploy software easily and securely using nix-deploy

nix-deploy is a small utility for easily and securely deploying software from one nix store into another nix store. With nix-deploy you can copy a program and its run-time dependencies to another computer; you can also copy an entire operating system configuration and activate it.

This utility will do the following things for you:

  • Generate a pair of signing keys on the remote computer if none exist
  • Exchange the signing keys with the local computer
  • Deploy the closure using nix-copy-closure
  • If the closure is a system configuration, activate it on the remote computer using switch-to-configuration

This post assumes familiarity with Nix, the Nix store, and nix-copy-closure. A refresher on these topics is in Appendix A.


We developed nix-deploy because:

  1. nix-copy-closure doesn’t exchange signing keys for the user; signing keys are important because the signature of a deployed closure verifies the closure’s integrity (i.e. that it is tamper or corruption free)
  2. We needed the system configuration deploy functionality of NixOps, without the overhead of NixOps

The solution to key exchange

nix-copy-closure works perfectly well if:

  • A cryptographic signature of the closure is not required
  • A cryptographic signature of the closure is required and the signing keys are already exchanged

However, nix-copy-closure is cumbersome if a cryptographic signature is required but signing keys do not exist or have not yet been exchanged.

nix-deploy path solves this problem by assuming that signing is desired, generating signing keys and exchanging them as needed, before running nix-copy-closure on the user’s behalf.

For example we can easily and securely deploy the hello-2.10.drv build product to remote-host:

… we can run the hello executable on remote-host:

The solution to NixOps-free deployment

NixOps does three things:

  1. instantiate and manage resources that will host and run a system configuration defined in the deployment specification for NixOps
  2. build the system configuration and software defined in the deployment specification for NixOps
  3. deploy the system configuration to the instantiated resources and activate it

A “system configuration” is a bootable NixOS system configuration; Appendix B provides more detail.

nix-deploy system subsumes NixOps by extracting the deployment and activation parts. Since we can securely deploy any nix store path to a remote computer, nothing prevents us from deploying a build product for a complete system configuration.

nix-deploy simply copies the closure to the target computer, and then executes the switch-to-configuration script found within the build product of the system configuration it deployed.

The switch-to-configuration script switches the target computer’s system to the system configuration of which the script is a product. This is the exact same mechanism used by nixos-rebuild switch.

Finally, we can test the activation of a system configuration via the --dry-activate option:


A key design goal of Nix is to make building software as pure and reproducible as possible. Purity is useful because we can trust that when we ask for the closure of a build product we get everything required to run that product. Reproducibility is useful because we can trust that we can (a) detect if we are missing some dependency in the graph at evaluation-time instead of run-time and (b) retrieve a cached binary build product satisfying that dependency (or else build it). This means we can reliably build and securely deploy binary artifacts across systems without use of containers or virtual machines, provided that the source and target computers are compatible.

Nix provides all of the fundamentals to accomplish this and nix-deploy adds some convenience around them.

You can find nix-deploy on Hackage and Github.

Appendix A

There are a couple of important things to know when deploying software with Nix.

First, Nix comes with a utility named nix-copy-closure; it is useful for copying the closure of a path in a nix store to another nix store.

A path in the nix store can be:

  • A derivation instantiated with nix-instantiate
    • $ nix-instantiate '<nixpkgs>' --attr hello → /nix/store/*-hello-2.10.drv
  • A build product from the evaluation of a derivation
    • $ nix-store --realise /nix/store/*-hello-2.10.drv → /nix/store/*-hello-2.10

Second, a closure of a path in the nix store is the graph of that path’s dependencies. You obtain the closure for a path in the nix store using the nix-store utility.

For example, if we want to obtain the closure for a path in the nix store that is a derivation, we can:

Obtaining the closure for a build product is just as straightforward:

Therefore we have two types of deployment in Nix: source deployment, which corresponds with copying the closure of a nix store path that is a derivation; and, binary deployment, which corresponds to copying the closure of a nix store path that is a build product.

nix-copy-closure deploys both types; assuming the target computer has Nix installed and SSH credentials configured. Note that nix-copy-closure only copies what is missing of the closure on the target computer.

We can perform a source deployment of the hello package and its closure to a computer addressed at remote-host and a user parnell configured with working SSH credentials:

… and we can perform a binary deployment of the hello package and its closure to the same remote computer:

Thus, we can deploy anything that is a derivation or a build product of a derivation in the nix store to another computer without ever thinking about the dependencies!

This means that we can deploy a build recipe and its closure (all of its build-time dependencies) to another computer, build it on that computer, and deploy the build product and its closure (all of its run-time dependencies) back to the original computer.

This is the idiomatic mechanism for using Nix to deploy anything built with Nix, using Nix.

Appendix B

A system configuration is a bootable NixOS-based computer operating system with a kernel, filesystem specification, init system (both default init scripts and user-specific init scripts), and user-land software.

With NixOS we can easily construct a minimal system configuration for an EC2 machine and deploy that system configuration to an EC2 instance.

… which we can instantiate:

… and build:

We can see that the build product of /nix/store/bfzijb8xsppldrj814hkvj7swij6xjd9-nixos-system-nixos-17.09.2182.drv is a NixOS Linux system configuration with a kernel, init ramdisk image, and a systemd init system:

We’ve built an entire Linux system configuration from a declarative specification. Furthermore the product of that build is a nix store path which means we can ask for its closure:

… thus, we can deploy nixos-system-unnamed-17.09.2182 and all of its runtime dependencies!


Thanks to Joel Stanley (@intractable) and Gabriel Gonzalez (@GabrielG439) for reading drafts and providing feedback.