@dch So it kind of depends on what you want, exactly. One common property among Nix-based deployment tools is that they all implement some variant of "declare your network structure as Nix code" (which comes with possibilities like parameterization), but the exact way it does so varies from tool to tool.

NixOps and morph, for example, are primarily designed around having discrete identifiable servers that have their own jobs. You certainly *can* generate lots of the same machine - after all, you're just generating a data structure using a full-fledged programming language - but it's not the core usecase that they are tailored to.

Then there are tools like Disnix that, to my knowledge, are more tailored to the usecase of "100 of these, 250 of that one", and fleet-style orchestration. I have not used Disnix myself however.

Many other tools also exist - because Nix itself is 90% of a deployment system, there are quite a few projects that implement the remaining 10% in different ways for different network designs! But the system configuration component is the same for all of them (just the NixOS stuff), the only difference lies in the network orchestration features.

Probably the closest thing to the concrete case you're asking about, that I know of, would be my tinc setup: https://git.cryto.net/joepie91/morph-rc/src/branch/master/configuration/default.nix#L118

If you follow the references from there, you'll find a centralized 'metadata file' that specifies all of the tinc nodes and their assigned IPs and such, and each individual server configuration uses `tincConfiguration` with that metadata as an argument to set up a local instance that's fully-configured to connect to other nodes.

In this setup, each node is aware of every other node at all times - because the node specification is just an input to the build, changing it will trigger a rebuild of all participating nodes, with the new node specification being deployed to all affected systems just like any other package/config change.

I don't know if there are OOTB tools for integrating this with an autodiscovery mechanism, but it would certainly be possible to eg. build an autodiscovery layer that just generates a node file and triggers a network re-evaluation whenever the nodes change!

What it boils down to, is that node interconnectivity can be made a part of the 'system configuration' just like anything else, and Nix (and your Nix-based deployment tooling) will manage it accordingly. But most Nix-y deployment tools do not come with an autodiscovery layer OOTB.

Does that answer your question sufficiently?