Nixverse: File-based Nix Flake Framework

Nixverse is a file-based nix flake framework for multi-node configurations, cascading secrets management, parallel deployments, etc.

Since it’s supposed to own all your nix configurations, it’s in a unique position to offer a lot of features:

  • Define nodes under nixosConfigurations/darwinConfigurations from files.
  • Define nestable groups for nodes.
  • Allow nodes to reference each other’s configuration.
  • Allow each node to select its own nixpkgs channel.
  • Deploy multiple nodes in parallel.
  • Install NixOS and nix-darwin with a single command.
  • Define cascading secrets for groups and nodes.
  • Import configurations and secrets from a private repo.
  • Define custom lib functions, packages and modules.
  • Define home manager configurations from files.
  • And more.

A very simple example:

Create flake.nix with the following content:

{
  inputs = {
    nixpkgs-unstable.url = "github:NixOS/nixpkgs/nixpkgs-unstable";
    nixverse = {
      url = "github:hgl/nixverse";
      inputs.nixpkgs.follows = "nixpkgs-unstable";
    };
  };

  outputs = { self, nixverse, ... }: nixverse.load self {
    # Add your own flake outputs
  };
}

And then by creating these two files, a nixosConfigurations.hgl flake output is automatically defined:

# nodes/hgl/node.nix
{
  os = "nixos";
  channel = "unstable";
}
# nodes/hgl/configuration.nix
{
  boot.loader.systemd-boot.enable = true;
  services.openssh.enable = true;
  # Add your own NixOS configuration
}

Finally let’s activate it:

$ nixos-rebuild switch --flake <path/to/flake>#hgl

Congratulations! You just created and activated a node with Nixverse.

Learn more about Nixverse by reading its reference.

5 Likes

I have been dogfooding it for a while. Removed a lot of boilerplate and repetitiveness from my own nix configurations.

Hope it can be useful to others too.

1 Like

Where is system configured? Like “x86_64-linux”

Your hardware-configuration.nix should have this value. Nixverse doesn’t own this value.

Uhh, why does the repo have a go.mod in it?? Does this run go code at eval time?? I don’t really get what cmd/parallel.go is for…

Hey, it would be nice if you could add some sort of real-world example so users would not need to go through 764line documentation

Sidenote:
I see that this project is also capable of deployments, I would love it if someone could write some deep-dive (or even shallow-dive) on all the nixos machine deployment options since it is starting to feel overwhelming. In fact, for one of my projects, I could not get some tool to work properly and thus I ended up writing a justfile for that :sweat_smile:

2 Likes

Easiest is nixos-rebuild with --target-host

It’s a small tool I wrote in go that runs multiple commands in parallel, it’s used to deploy multiple nodes in parallel.

1 Like

I will publish my own nix configuration soon. It contains a Mac, a nixos desktop, one router, and one web server.

For deployment tools, a quick rundown of the tools I know:

  • deploy-rs: can’t do parallel deployments.
  • colmena: can do parallel deployments, but mostly just a deployment tool.
  • nixos-rebuild: can’t do parallel deployments.

Nixverse simply calls nixos-rebuild under the hood, and feature wise is a different beast. For example, groups in nixverse is much more than just a way of tagging multiple nodes, it can define configurations that can be overriden by descendants, it can define secrets that can be overriden by descendants, etc.

3 Likes

How does it compare to nixos-unified?
https://nixos-unified.org/index.html

Not really familiar with nixos-unified, but from a quick read of its manual (thus take my opinions with a grain of salt:

  1. No group support, and thus no support like allowing nodes inherit configurations from a group.
  2. Can’t easily use configuration from other nodes.
  3. Home manager support seems to be more about providing a flake output than being directly usable in a node.
  4. Can’t do parallel deployment.

I won’t list more. You can compare its doc with nixverse’s listed features.

I would introduce my solution:

inherit configurations from a group.
I use POP to solve the inherited configurations problem.

Based on the hive, I rewrite the implementation so it can be running without the std framework.

I will not get involved in user configuration and some customization, the user only needs to write the purest module configuration and the straightforward attreset that would be enough.

The big difference between tao3k/hive and nixverse is that it has not yet developed a specific CLI support.

Asking to experience users because I’m a noob, and my dotfiles flake got already complex enough to understand it. So I’m looking for ways to make it simpler and work better, but there are many alternatives and I’m currently in a paralysis.
Currently I’m using flake-parts, but I feel I need something giving better structure

These things are by their nature highly opinionated, however I can understand your position - as I was once in exactly the same position as you :slightly_smiling_face:

I personally opted to use Snowfall Lib -

Jake Hamilton created this, and you can see his own config on GitHub to get a feel for how a repo using snowfall lib is organized -

One other suggestion I’d make, is when you want to get a feel for how these opinionated frameworks work in practice, do a search on GitHub for

“lang:nix snowfall”

Obviously replace snowfall with the frameworks you’re interested in.

Good luck, whichever path you end up choosing! :+1:

Thank you very much!
Snowfall was indeed also in my list, but thanks for the tips on it.
Something I like about nix-unified (in theory, I didn’t tested it in practice) is they claim to provide you a flake app you can execute in any host to “bootstrat” your personal flake.
Not sure how that works in practice, but I think not Nixverse nor Snowfall support that.
Maybe is something trivial to implement? I don’t know, I’m just trying to cleanup the mess my current flake is :smile:

As long as you have a nixosConfigurations.<name> output, and your flake is in a github repo for example, you can bootstrap it by running

nixos-rebuild switch --flake "github:owner/repo#<name>"

It’s on nixverse’s todo list to turn your flake into a flake app, so you can call nixverse cli to deploy in parallel for example.

nix run github:owner/repo node deploy node1 node2 group1
1 Like

At least now, I don’t yet need to deploy to several systems in paralell.
Does that rebuild also clone the repo? Or just adjust the system to follow whatever that flake says?
It will be ideal if you have the option of also “install” the flake source, and not only apply it

You always need to use git to explicitly clone a repo, i don’t think nix can do that.

Once you have nix installed it can do anything. You can create a script that uses git to clone itself

Sure, but you probably don’t want to do that, because everything in a derivation is:

  1. public to every user on your computer.
  2. read only.

You can clone it properly in an activation script, but then you need to know the absolute path to clone it to, and also some guard against cloning it repeatedly. This feels a bit messy.

But If you have a better solution, I’d be happy to learn.