Tomorrow, the implementation should be ready 
Cool idea. Do you have some plan on how to provide the minimal set of nix configuration files? Will it always require manual symbolic linking, or is there some way to programmatically determine which nix files have been evaluated?
I have adopted a style of modules similar to NixOS where all the modules are imported, but only some are enabled. This would seem to be at odds with this minimal configuration file idea. I like the NixOS style because you don’t have to think about which systems need to have a module imported, but probably this is wasteful and insecure. What if, instead of giving each system their configuration files, you served them a completely built NixOS system closure? Then the problem of the minimal configuration being seen by the client is automatically handled by Nix.
It might be the opposite of what you intend by goal of keeping it simple, but if you adopt something like agenix or sops-nix, then you can deliver your secrets as part of the nix store.
It currently need a shared nix file in imports to schedule the upgrade, nothing more.
I prefer not to push configurations because it doesn’t work for people like me behind a DSL line, but as a first step toward supporting more use case, you can build configurations locally and so if you are a binary cache for the client, they could reuse the result of your build.
As for secret management, I plan to just copy files without nix for now, but I suppose any kind of secret management could be used.
It’s still all new for me, I discovered deploy-rs and other a few days ago. This is my first time managing remote NixOS systems 
this will certainly require a few iterations to improve to a correct level.