This was a good read. I'm currently designing the deployment tool for GNU Guix (a package manager and distro based on Nix) so I find stories like this very valuable. The author didn't seem crazy about the NixOps state file, which is something I'm trying to think hard about for Guix. They claim that the state file isn't easily shareable across machines. Couldn't they just version control it and clone the repo on every workstation that does deploys or are there complications?
There is Upcast[1], which is a different tool by Zalora and does this - it simply adds a file you can check into the repository for developers to use. It has some beta-ish limitations but the idea is what you described, basically.
The remaining build step, then, is copying the new closure of the environment to the machine on deploy, which can take some time depending on your network. Instead I think what you'd probably do is use Hydra (a CI server) to actually build the packages/closure of your network on every commit to your repository, and then add that server to your actual deployment server's binary caches - that way when you deploy things after CI allows it, the needed assets will already be on the remote (faster) binary cache, within your network.
