upvote
Isolation from the main system, other services, and other dependencies.

Easy to migrate to new system.

Easy to upgrade and downgrade. When a new version causes an issue just restart it with an older version.

One directory to backup and restore that contains all the services and their settings.

reply
A single binary accomplishes most of those things just fine. Only thing it doesn't get you is isolation, but you can isolate things if you want even then (for example, FreeBSD jails are dead easy to set up).
reply
ok, so you're just using a container with a different name? You can put the single binary in a container and call it a jail if it makes you feel better.
reply
I don't use Docker but I love reading the compose file when a project has it. It is the quickest way for me to get a high level idea of this project's architecture. It's the best documentation :)
reply
This. Docker compose is so great that you don’t even need to use it, for it to be useful. It can describe so well the dependencies your system needs (alongside proper documentation).
reply
I’ve been a die hard native package or static binary proponent for a long time. I still hold that there are real advantages.

As podman has improved and compose stacks have improved, I’ve conceded that containers simplify deployment and updates and isolation, and at this point I find for me the benefits more than outweigh the hassles.

Instead of crafting a set of ansible plays that do all the manual native installation steps, I have a relatively lightweight ansible rig that reads containers and relationships desired from a manifest in inventory, then builds or modifies compose files, then just deploys. Much less futzing. And I’m more likely to keep things up to date regularly as a result

Or, increasingly, dispatch codex to handle it for me

In this way I update home assistant across multiple instances now like magic. I don’t even dread it a little anymore

reply
It’s the unified interface for me. Updates, logs, service management, network routing, config and storage mapping are all uniform and I don’t have to wrangle many slightly different implementations of each. Isolation from installed packages is a nice bonus.
reply
for long-running services, I've never taken the time to learn something reliable like systemd. with Compose, I can see everything I need to know in one yml file and the commands to go with it. I also don't have to really understand any dependencies or their own configuration and can cleanly remove everything associated with that service with a few commands.
reply
Its a single config that lets you run multiple services (and can keep them running), upgrades are just editing an image tag.

Don't have to look at cli docs to figure out how to run it.

Doesn't have access to my file system, logs are easy.

reply
Some isolation is nice. I say some because I’m told it’s security is not to be trusted, but I still like that even a non nefarious binary has ootb boundaries on what state will persist.
reply
Docker isolation is likely good enough if you keep your kernel up to date and aren't allowing 3rd parties to run code. If you are running a CI service or something you need micro VMs. But to host your nextcloud server, docker is good enough, it's unlikely someone will both exploit nextcloud and the kernel if you are keeping them up to date.
reply
I too prefer the Docker compose route. If you give me a single binary, I'll go out of my way to run it inside a compose stack.

I manage my home server with a script that presumes the service is running on a compose stack. So I can run stuff like `stack freshrss restart`. I don't want to touch my scripts, I just add the compose file to some expected path and the script finds it based on naming conventions.

reply