(I'm the post author)

As others said, I've moved away from doing nix builds on servers and into a less wasteful (if you're running multiple servers) approach of building once, deploying the bits into a cache, and making the servers fetch them from a cache. I've been slowly working on my own tool to make this workflow easier (nixless-agent, you can find an early version on GitHub).

Do you have a post on your setup? I'm relatively new to NixOS server management and I've been leaning on NixOps for the coordination bits. I'd love to see what you're doing as it sounds more elegant, efficient, and supported.

I don't have one yet, but I will definitely make one once I make a public release of nixless-agent. At the moment I use a combination of nixos-anywhere (for initial provisioning), colmena (mostly for quick testing/dev setups, because it lets me push things directly to a machine), and nixless-agent (still experimental and going through lots of testing). Ideally my final setup will be just a mix of nixos-anywhere and nixless-agent.

You need not perform your nix evaluation on the same device you are targeting. You can nix copy a system closure to your target and activate it, and there are a number of tools in the nix ecosystem to make this easier.

Granted, if you local machine is low on RAM, or isn't Linux, then you will be in trouble.

If you have a different machine with more ram and compute, you can use 'nixos-rebuild --target-host=<server> switch'. That does all the nix building on the local machine, and then just copies binaries and activates the built configuration on the remote machine.

I don't run nixos on my PC

you don't need to have nixos to have nixos-rebuild installed. Just nix

Not similar to nix, but you can look into Yocto. You can use it to generate an OS. It is, much more involved than using nix, but suitable for low memory environments.

The problem with nix is that compiling a system uses lots of memory, but when deployed there's little overhead.

Like you would with Yocto, I just build my systems on a proper host then remotely deploy them.

Yocto is also used by Lenovo to build their software appliances like XClarity Administrator.

Also it’s very famous and loved in embedded software circles.

Well, "loved" is not the word I would use. It's an improvement over the chaos before, where everyone used some other bespoke tool to build their BSPs. Yocto at least is some kind of standard now, but not a particularly good one (granted, it's a really difficult problem to solve). I don't know anyone actually enjoying working with Yocto.

Yocto is also hated for its unnessesary complexity in embedded software circles.

I haven't tried it personnally but Guix is similar with config in guile scheme. Have a look at the documentation [1][2].

Caveat: it is a gnu project so no proprietary stuff like firmwares and drivers included out of the box (but there is a community guix nonfree project available [3]). I believe that isn't a problem for virtual machine servers anyway.

[1] guix cookbook: https://guix.gnu.org/cookbook/en/html_node/index.html#Top

[3] guix manual: https://guix.gnu.org/manual/en/html_node/index.html#Top

[3] https://github.com/guix-users/guix-nonfree

The widely used nonfree guided channel is https://gitlab.com/nonguix/nonguix, not the one you linked.

Thanks for the clarification. Can't seem to be able to edit my comment.

author does not use nix on his nixos and removed it, so no ram issue.

author does not activate new config on host machine, but deploys new host machines as needed.

he evals on build/dev/ci machine only.

It won't necessarily do that if you deploy to your server from a remote machine over ssh

guix?

Doesn't it use nixos underneath?

guix does not use nixos underneath, it's a completely independent implementation (of the same underlying concepts)

guix is built on top of the nix daemon

It does have the nix daemon in-tree: https://git.savannah.gnu.org/cgit/guix.git/tree/nix

Not anymore, I think.

It’s a forked and tweaked version of the nix daemon. There have been some efforts to build a pure guile replacement, but afaik it’s not yet the default.

The best thing about NixOS is that it's extremely easy to replace systems. On my infrastructure, I have a centralized server where I store all my nix artifacts in /nix/store.

Then on boot for my other systems, they boot into a minimalist nixos image (via netboot) that (1) lookups up the hostname assigned to the system, (2) uses `nix copy` to move the closure of the current system from the main host where I store my builds to the local one, (3) switches into the system (explained below), and (4) then uses nixos's kexec support to switch into the proper kernel booting into the new system.

How to switch into a system: every nixos closure has a top level `bin/switch-to-configuration` script that nixos-rebuild suse. Just run `/nix/store/my-hash/bin/switch-to-configuration switch` and your system will silently be replaced by the new NixOS configuration. Very easy!