Cachix Deploy Public Beta

Announcements
#1

Hi Nixers,

I’m happy to announce public beta of Cachix Deploy after months of development!

Read more about why I’ve built this infrastructure tool: Cachix Deploy Public Beta - Cachix Blog

Domen

17 Likes
#2

This is awesome! I’ve been thinking about similar approach for a long time now but haven’t had the time to implement it.

1 Like
#3

What is the main problem that cachix deploy tries to solve? I have read your great list of use cases but somehow I still fail to place cachix deploy in the vast nix-tooling space😃.

If I already use home-manager with nix flakes and cachix as binary cache, does cachix deploy offer any additional advantages?

1 Like
#4

Do you have a bunch of machine in a datacenter or in the cloud that are mostly the server for one application and the base machine that support them ? If yes you can use this to deploy your latest version on it :smiley:

2 Likes
#5

If you’re just running nixos-rebuild switch locally on a single personal machine, Cachix Deploy won’t do much for you.

However, if you’re doing NixOps or deploy-rs (etc.) deployments to a number of machines, then Cachix Deploy could be really helpful. We were using deploy-rs via the following process:

  • Build our nixosConfigurations and darwinConfigurations in CI. Then, once CI had passed and the configs were cached:
  • For NixOS: fire up a nix develop shell and deploy --skip-checks to push the deployments for each machine from my local machine.
  • For macOS, SSH into each individual machine, git pull the local checkout of our repo and darwin-rebuild switch.

deploy-rs worked pretty well for the NixOS configuration, but it still required an extra manual step after CI passed. However, the macOS deployment scenario was a PITA and was clearly not scalable beyond a few machines. In neither case did we have a proper CD (continuous deployment) system for our system builds. We probably could have implemented a deploy-rs CD setup for the NixOS machines with some bespoke scripts, but I never did so, mainly for security reasons, as I was uncomfortable creating a long-lived, shared SSH key for CD use, especially one with root access as is required for deploy-rs.

We’ve just switched to Cachix Deploy, and now the way it works is:

  • Build our nixosConfigurations and darwinConfigurations in CI.
  • Once CI has passed and the configs are cached, CI creates a GitHub deployment.
  • The GitHub deployment fires off a CD step that runs the Cachix Deploy deployment command.
  • In response to the deployment, our NixOS and macOS machines automatically pull their new configurations.

The advantages for us are pretty obvious:

  • Proper continuous deployment: creating a unique Cachix Deploy key for each new machine and getting it deployed to that machine is a one-off manual step, but after that, nobody needs to intervene anymore to make a deployment.
  • I’m more comfortable with the security of this approach: each machine has a unique token, and it pulls its configuration rather than a CICD server pushing the configs. There’s no need to expose the local root account via SSH, and there are no firewall rules to worry about.
  • Because Cachix Deploy uses a pull mechanism, this works for deploying to end-user machines as well, which often don’t have a well-known IP address.
  • Machines that are offline at the time of deployment (e.g., a developer laptop that’s sleeping) will automatically check for a new deployment upon coming online again, so they don’t need to be online when the CD runs.

There are still some important features missing from Cachix Deploy (e.g., automatic rollbacks), but those are on Domen’s roadmap. Even in its current beta state, it’s saving me a ton of time, and I’m really glad we’ve made the switch.

6 Likes
#6

Great answer. Much appreciated :+1:.

#7

I personally value to have my laptop versioned in a github repository and deployed via CD to preserve all the history.

As I add more features like comparing two deployments, tracking closure size, etc, this will be more valuable.

But my workflow has always been:

  • change configuration.nix
  • nixos-rebuild switch and wait
  • forget to commit

And now it’s:

3 Likes
Hosted by Flying Circus.