I used to be very enthusiastic about docker compose, but I've been playing around with nix + process-compose lately and its pretty great. I can have k3s and tilt in there only when it's necessary--which it's usually not.
"Deploying" one is as simple as `nixos-rebuild switch --flake .#hostName`
There are a ton of other open-source process supervisors you can use to manage long-lived processes in a portable way, too, notably Foreman[8] and various clones written in languages other than JS, and GNU Shepherd[9]. In the course of writing this post, I discovered one called dinit[10] which looks sort of similar to s6 and the GNU Shepherd in that it supports both pure usermode operation as well as functioning as an OS's init system. Anyway, all of 'em are in Nixpkgs, so you can pick them up and use them without any packaging work, too.
Service orchestration and containers are basically orthogonal concerns. Before Docker was born, there were already plenty of portable tools for standalone "process supervision", "service management", whatever you wanna call it. So it is after Docker, as well.
If I needed this for one of my dev environments I would take a look at process-compose to decide if it's acceptable to me. If it isn't, then after surveying the contemporary landscape of usermode service managers, I'd then write a devenv module that generates configs for it, and use that.
> Should I run Nix in Docker, Docker from Nix, or is there a nix-only solution for this?
I'd do this in a "Nix-only" way if possible, but if it's convenient for you to run a service via Docker (or Podman or any other container runtime), you can still do that.
If you can safely assume that all of your devs have it available, you can ship the client (`docker` or `podman` CLI or whatever) as part of your Nix environment, then have your process manager launch it via that command line interface. I'd avoid running Nix from within Docker for the purposes of development environments.
--
3: https://devenv.sh/supported-process-managers/process-compose...
4: https://f1bonacc1.github.io/process-compose/
5: https://sandervanderburg.blogspot.com/2020/02/a-declarative-...
6: https://github.com/svanderburg/nix-processmgmt
7: https://skarnet.org/software/s6/
8: https://github.com/ddollar/foreman
You'd have to ensure that their ports and data directories don't collide, but I don't think you'll have a problem having "process-compose up" start multiple separate mysql, postgres, or webserver instances.
I just dedicate a terminal pane to it so I can arrow around and see the logs and health status of my databases (plus things like Prometheus and Grafana, I like to be able to nuke the cluster and have everything flatline, rather than having telemetry itself die when k8s goes away).
Both mysql and postgres are included in https://github.com/juspay/services-flake which you might find interesting.
Its especially nice for use with agents because the process-compose commands can be used to understand what's running, what's pending, what's failing, etc. Of course there's always `ps aux | grep` but that's full of noise from the rest of your system and it doesn't provide and structure for understanding: "foo is not running because the readiness check for bar is failing".
Containers have their place, but I don't think it's everywhere.