Which actually makes a lot of sense, to hand over the orchestration / composing to systemd, since it’s not client <> server API calls (like with docker) anymore but actual userland processes.
Yep. It works even better on a declarative distro like NixOS because you can define and extend your systemd services (including containers) from a single config.
Taking this further (self-plug), you can automatically map your Compose config into a NixOS config that runs your Compose project on systemd!
It totally does! On the con side, I find systemd unit files a lot less ergonomic to work with than compose files that can easily be git-tracked and colocated.
What makes a systemd service less ergonomic? I guess it needs a deployment step to place it into the right places where systemd looks for them, but is there anything else?
Taking this further (self-plug), you can automatically map your Compose config into a NixOS config that runs your Compose project on systemd!
https://github.com/aksiksi/compose2nix