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).
Granted, if you local machine is low on RAM, or isn't Linux, then you will be in trouble.
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!
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
Also it’s very famous and loved in embedded software circles.
Like you would with Yocto, I just build my systems on a proper host then remotely deploy them.
author does not activate new config on host machine, but deploys new host machines as needed.
he evals on build/dev/ci machine only.