That's because it's a pretty silly way to look at things in a world of docker compose.

Classic. Tools become too abstracted? Add a layer of abstraction to manage them.

Feel like there must be an xkcd comic on this, but it doesn't leap to mind yet.

Software becomes so complex that it becomes vulnerable. Add more code, i.e., more complexity, to "fix" the problems.

WAF

I mean, asking them to plop their cli docker setup into a yaml file isn't exactly a difficult task. I think it's probably more correct to consider docker-compose an integral part of docker rather than a superfluous abstraction layer.

This one comes to mind immediately: https://xkcd.com/927/

I would propose this one: https://xkcd.com/2347/

Surely it should be this one?

https://xkcd.com/1988/

Or maybe this one:

https://xkcd.com/1579/

Or possibly the last panel of this one:

https://xkcd.com/1718/

Or this one…

https://xkcd.com/1764/

…Or this one:

https://xkcd.com/2021/

Well, a couple things occurred to me when I realized it was at least 2 instances.

First, I'd have to get them talking to each other. I am not an expert at Docker, and I just do the most basic stuff with it.

And second, I think they'll need to be reachable from the web, so I'd want to host them somewhere out in the cloud, and not on my home network. NearlyFreeSpeech doesn't offer Docker hosting yet (that I know of) so that means paying more for somewhere else for it...

And at that point I decided I didn't care enough about the benefits to deal with all the downsides, and just signed up on a Lemmy instance. It was actually the second instance, because the first one had stability issues. I then realized I didn't like how that instance was being run, and signed up on third, which I've been happy with and it's been relatively stable. At least, when it had problems, so did most other big Lemmy instances.