Yep. What nix adds is a declarative and reproducible way to build customized OS images to boot into.
An alternative is to “infect” a VM running in whatever cloud and convert it into a NixOS VM in-place: https://github.com/nix-community/nixos-anywhere
In fact, it is a common practice to use the latter to install NixOS on new machines. You start off by booting into a live USB with SSH enabled, then use nixos-anywhere to install NixOS and partition disks via disko. Here is an example I used recently to provision a new gaming desktop:
nix run github:nix-community/nixos-anywhere -- \
--flake .#myhost \
--target-host user@192.168.0.100 \
--generate-hardware-config nixos-generate-config ./hosts/myhost/hardware-configuration.nix
$ nixos-rebuild build-image --flake .#myhost --image-variant amazon
$ aws-cli image upload < result/images/image.ami
$ aws-cli create vm --image={image}Same with the CI platforms, instead of `setup-*` steps in GHA it could have just take flake in. Yes, I know I can build OCI image with nix, again, not the issue.
My private CI runs on top of nix, all workers on the same host share /nix/store. My pipelines focused on running actual things rather than getting a worker ready to run things. If I didn't want output to be parsed by CI, I could have just reduced my pipeline to `nix flake check`.
I share the exact same pipeline and worker image across multiple projects in multiple languages, all because everything is hidden behind devenv's tasks. When I switched project different rust and node versions, I didn't have to touch my CI at all. When I added a bunch of native deps that usually needed to be installed separately on GHA - again, didn't have to touch anything beyond my nix env once.