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.
I’m happy to report I’m diving deep into using disnix for my personal server setup. And I’m very happy with the in progress results.
I’m especially happy with the fact that it’s very easy to test changes using virtual machines.
Right now, I’m setting up vaultwarden + postgres + haproxy + keycloak (to restrict access to vaultwarden’s /admin path), also I’m setting up a similar stack with ttrss + php-fpm + postgres + haproxy + keycloak.
I’ll report back when I’m done with the setup.
Eh so I’m hitting a roadblock. I’ve been fighting for months (on and off of course) to get disnix working with nixops 2 on the latest nixpkgs version. I learned a lot by doing that by after all this time I’m still not done.
Also, I didn’t get any response from disnix’s maintainer in all this time (no hard feelings, no grudge against them, I fully respect their time). And I learned recently that also nixops 2 is not really maintained anymore.
So, it’s not looking good, to say the least 
One more thing, from an implementation perspective, if we embrace disnix, we can’t re-use any of the nixpkgs modules the community created. They all would need to be ported to disnix. I don’t see that happening.
All that to say I was very happy because it does work, but there are too many downsides to be worth it for my use case.
I since switched to colmena for deploying but I’ll definitely consider coming back when the situation looks better.
How did you attempt to contact? Sander once told me he doesn’t actively monitor github notifications usually and direct email is the best way to contact him.
@kvtb Thank you the insight. I totally understand how one can get a burnout feeling working on this for too long.
On a side note, this paragraph resonated with me:
Building prototypes and integrate the ideas into Nixpkgs rather than starting an independent project/tool that attracts a sub community.
I also refocused what I was working in to integrate better with nixpkgs.
@aanderse ah that would also explain it then, I only contacted through issues/PRs.
This is exactly the reason why I opened Add support for NixOS containers by nessdoor · Pull Request #10 · svanderburg/dysnomia · GitHub as a draft PR on the Dysnomia repo.
Another way to bring modules in could be by using the system derivation manager of Dysnomia, which is undocumented but definitely there, but I haven’t had time to investigate further, as I tore down the entire thing and now I only have a single server built off a flake.
That’s awesome. I remember seeing that PR but didn’t understand its usefulness until now. I got plenty on my plate before being able to get back to this, though.
I do miss how disnix was activating dependencies in order and automatically rolling back if an activation failed. At least I don’t have that when using colmena.