Disnix, Dydisnix, Disnixos, etc

Is there much interest to continue maturing some of ecosystem Sander van der Berg creates? It seems very promising in creating self-hosted infrastructure and can subsume many other tools. It seems like the next logical progression for Nix. Thoughts?

Ive done some basic tests, and I suspect I’d hear tools were more integrated into NixOS and NixOps, they would be tested/adopted quickly.

I like the idea of distributing the whole service (there is a lot of “post-install”-processing in most servers: that’s BAD).
It’s probably that disnix has a somewhat unconventional naming convention, or the documentation is too scattered.
You could start a business by calling it Enterprise Nixos, with application containers.
(I’m planning to use dysnomia for installing all the databases, just to be able to install running applications, but maybe I should learn more disnix).

In principle disnix is what I want in the long term but I personally don’t have a use case for it at the moment with only one or two servers per network I manage.

But I’d welcome changes in the direction that disnix persues, esp. if small servers become even cheaper.

Huge interest over here! Hoping to apply his existing work to multi-vendor cloud solutions- for… ya know… purposes.

I agree with mwilsoncoding.

I’m not sure dysnomia is a right generic solution to “manage state” problem. For example, it provides postgresql-database module,

but that module doesn’t use logical replication to move state (only snapshot/restore). And even for snsapshots it’s opinionated

and uses XZ compression (but I’d like zstd because my DB is of terabyte scale).

Should backups and logs be also managed via dysnomia? Those are mutable stuff, but dysnomia won’t be

effective here.

Also, it is not clear from README on how to actually move a “container” to another host (which is second

useful feature after accounting)

I think those are implementation details or things that should have alternative backend implementations.

The core structure of the tool is fine, but it might be that many (probably all of its components) are not enterprise ready (i.e. do not meet the expectations a company would have). I think it’s fine to start with a program that is not perfect everywhere, as long as it is documented what parts are good and which parts are essentially placeholders.

The postgres module you describe certainly sounds more like a placeholder.

Just a random report: I had a situation where I wanted to iteratively deploy a service to a NixOS machine and did not want to constantly modify the machine’s system configuration. This made me think of either declarative Docker containers or Disnix. I already packaged everything with Nix and did not want to deal with pushing containers around as well as support for managing from OSX.

Decided to try Disnix. Activated Disnix on the host and after a few syntax fixes quickly deployed my program as a “process” module (which uses a systemd service managed by the host’s Disnix service) and quickly iterated several versions of the program. It was generally helpful and easy.