NixOps and the Nix website

I want to find information about NixOps on the NixOS website at

Some time ago, I was able to easily find information about specific Nix-related software (Nix, NixOS, NixOps, etc.) on the site, as these different software products were clearly listed. However, the current website seems to follow more this modern approach where the intention is to take you by the hand, show you all the great things you can do, and finally lead you to the places you want to visit according to the web site designers.

This approach can make it quite hard to find what you want if you are looking for information on a specific product. In my particular case, I was unable to easily find the NixOps part of the website. In the end, I employed Google and found the NixOps GitHub page, which was not too informative, and the NixOps manual in a version about which I don’t know how up to date it is. Clearly a huge step back from how things were with the old site.

By clicking through the site, the only relevant-looking thing I found was the guide on “Deploying NixOS using Terraform”. Sadly, I have no idea what Terraform is and how it is related to NixOps.

As a result of all that, I have the following questions:

  • Is NixOps somehow replaced by Terraform?
  • If yes, does Terraform work with Hetzner?
  • How can I find the NixOps part of the website by navigating through the site?
  • Will there be any effort to make finding information about concrete software products like NixOps easier again?

The old links such as NixOps User's Guide are still there, but they aren’t discoverable. The newest documentation can be referenced from the readme on GitHub - NixOS/nixops: NixOps is a tool for deploying to NixOS machines in a network or cloud. which points to NixOps User's Guide

There’s some overlap, but IIRC nixops covers more scenarios. Should be more similar to terraform+consul+nomad+vault as it handles provisioning, service discovery (not as sure about this one), deployment, and secrets management.

It has support through a provider Terraform Registry

Appears to have been removed for the time being, but nixops documentation can be found at GitHub - NixOS/nixops: NixOps is a tool for deploying to NixOS machines in a network or cloud.

That’s a question for the marketing team.

1 Like

Thank you for this information.

Sadly, the NixOps manual seems to be quite terse. In fact, it seems to contain only a bunch of examples, a manual page, and a reference about configuration options. I had hoped that there would be some documentation that actually describes in a newcomer-friendly way how NixOps works and how to use it, basically like the NixOS manual does it with NixOS, but apparently no such documentation exist.

Another thing is that the most recent version of the manual is lacking all the provider-specific documentation. What was the reason for removing it?

I guess, given this situation, getting into NixOps won’t be very smooth. Therefore, I’d like to get some information about how helpful NixOps would be in my case, in order to decide whether using it would be worth all the hassle of gathering information by asking questions on Discourse and trying to guess the NixOps concepts from the information in the manual. I want to maintain a single physical server at Hetzner. What does NixOps give me in such a situation over just manually installing and maintaining NixOS?


In my opinion, very little for a single server. You don’t really see the benefits until you have multiple machines that configuration files from one pull from configuration options of the other instances (for example scraping Prometheus exporters from a monitoring server based on configs of all the other servers in that deployment). Don’t get me wrong, I love nixops and have a number of personal deployments I maintain, but if you have a single server you’re maintaining and asking why not just use configuration.nix on that server, you probably won’t get much value out of using nixops.


I only have 1 server, but still find NixOps handy because I can deploy out of my local git repo for configurations. The server and my desktop can share modules, and I don’t need to worry about syncing my git repo to the remote machine.

This is an excerpt from my nixops network:

# network.nix
  network = {
    description = "Rodney's Setup";
    enableRollback = true;

  # my server
  linode-syd = {
    deployment.targetEnv = "none";
    deployment.targetHost = "";
    deployment.keys = import ./keys.nix;
    imports = [ ./hosts/ ];

  # another laptop in the house that's occasionally switched on
  aurora = {
    deployment.targetEnv = "none";
    deployment.targetHost = "";
    deployment.keys = import ./keys.nix;
    imports = [ ./hosts/aurora.nix ];

# hosts/
{ config, pkgs, ... }:
  networking = {
    hostName = "syd";
    domain = "";
    hosts = {
      "" = [ "" "rodney" ];

  time.timeZone = "Australia/Brisbane";

  imports = [
    # Include the results of the hardware scan
    # (originally from /etc/nixos/hardware.nix)

    # Basic config for

    # shell and standard emacs config

    # servers

    # IRC bouncer

I found that it was easiest to install NixOS manually, with a minimal configuration.nix, then hit it with NixOps, using the nixops ssh backend.

If you were wondering how to use the nixops ssh backend, it’s enabled with deployment.targetEnv = "none";. I found getting started with nixops to be a pretty rough ride. There was a good video by @peti which helped me a lot. But for the new version of nixops, it might be out of date.

1 Like

I do the same with plain NixOS. I have a git repo with a folder hosts and in there are the configuration/hardware-configuration files of my server and my desktop machines. I just create softlinks to these in /etc/nixos/. Then I have a folder cfg/ where I have both default configs imported by every host and some custom configs which are only imported by individual hosts.
Of course I have to sync the repos but this doesn’t feel like a problem to me. And I’m not bound to needing the Nixops deploy machine to deploy new changes on the server. Of course provisioning, secret management & co. are not really covered properly.

1 Like

Do you need NixOS running on your local machine for this approach? If not, how much of Nix do you need on your local machine? I’m using Ubuntu on my laptop (and will continue doing so for some time at least). I’m not using Nix on the laptop at the moment and have only little disk space left; so installing half a Linux distribution via Nix would not be possible for me.

One reason for me to use NixOps would be to have the whole machine configuration described by a Nix expression. I understand that with NixOS at least the partitioning of hard disks is not part of the configuration expression. However, when first installing a plain NixOS and only then switching to NixOps, I still have to manually partition my hard disks; so the advantage of having all configuration automatically realized would be lost.

Or is it generally the case with NixOps that you can’t configure your partitioning scheme in detail? I saw somewhere that by default NixOps does already quite a bit regarding partitioning and RAID, which I didn’t like, as I want to make decisions about such things myself. Not sure how much NixOps even lets me configure these things and how hard it is to switch off everything that has been switched on by default.

No, but you need nix to use nixops. Nixops builds the system closure for each system locally and then transfers it to the target system and activates it there. So effectively you will have at least one full NixOS system on your disk, even if it’s just in files.

Partitioning with Nixops is complicated. Basically, nixops does not do partitioning and just expects a finished nixos system it can take over.
The complicated part is:
Some providers (e.g. the Hetzner provider for dedicated servers) can initialize a server from scratch by rebooting into their rescue system and repartition the disk, followed by installing NixOS and finally activating the correct configuration.
For my hetzner cloud servers I’m using a shell script to automatically convert their default Debian image into a NixOS installation and then just let NixOps take over the NixOS install.

1 Like

The nixops model is to build the system configuration locally, then transfer it to the deployment target. There is some kind of hetzner plugin for nixops, which probably allows defining disk/partition configuration, but there seems to be no documentation, apart from the python source code. If you don’t have enough disk space (or bandwidth), and/or need documentation, then nixops is not the deployment tool for you.

Given this, for Hetzner, if you need a fully declarative configuration from provisioning to deployment then I think the best way would be to use cloud-init to define your partitions and install a debian system for bootstrap. The cloud config yaml can write /etc/nixos/configuration.nix and run a script (nixos-infect perhaps) to fully deploy your system.

1 Like

Hmm, so I would need to use an external disk locally for holding a copy of the entire server OS installation (because there is no chance that my laptop’s disk could hold it) and still couldn’t automate the partitioning well. I guess, NixOps isn’t really useful for me then.

I don’t like the approach of transforming a Debian installation into a NixOS installation. Hetzner has rescue systems, from which you can install NixOS from scratch. That seems like a simpler approach to me (and also a cleaner one, although I understand that that transformation approach will most likely also give you a clean system).

Just a small addition regarding the discoverability / location of the manpage:
Over the past years I occasionally needed to take a look at the NixOps documentation and at some point I began to access the documentation directly, by manually typing “NixOps User's Guide”.
Thankfully this still works after the relaunch and the same applies to the other manuals in case I want to look at them online:
Introduction - Nix Reference Manual
NixOS 23.11 manual | Nix & NixOS
Nixpkgs 23.11 manual | Nix & NixOS


The transformation approach is actually not that bad in practice. I have used NIXOS_LUSTRATE before, and the end result was clean (apart from partition labels, which could be corrected with configuration.nix).

In your situation (provision hetzner machine, deploy nixos, not enough space on laptop for nixops, need fully declarative setup), I think the transformation approach is better than installation from rescue, because then you can use cloud-init to define partitions and the installation script.

Something to consider though: provisioning (which includes disk partitioning and formatting) is a step that many people choose not to automate (myself included). Because if you have just one server, doing this setup manually just once is quicker than devising an automation.

1 Like

I think NixOps is not the right tool to just manage a few nixos machines.
I did, and I went through lot’s of frustration. NixOps is optimized for advanced features like managing google cloud and AWS resources. The tool is therefore in many ways more complex than it needs to be to manage normal nixos machines. It is for example very stateful, which is unnecessary for your use case.

It also has some crucial design issues, like depending on your NIX_PATH, which has never been solved.
If you manage multiple machines with different nixos versions, you bascially need to wrap NixOps for each individual machine to use the correct nixpkgs version. It is not just complicated but also makes it highly fragile. If you forget to laod the correct shell.nix, you risk breaking your deployment. NixOps won’t warn you.

For a single machine it might be enough to just use:

nixos-rebuild --target-host ...

If you have a few more machines to manage, you might want to take a look at morph or krops.
And if you want to go the bleeding edge route: deploy-rs


Correct. Stated another way, any tool which provisions resources will want local state. So nixos-rebuild, morph, krops, deploy-rs, etc are stateless because they only do deployment and not provisioning.

FYI, the NixOps documentation has moved/is moving here.

1 Like