this post was submitted on 01 Oct 2025
64 points (95.7% liked)

Selfhosted

51931 readers
1295 users here now

A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.

Rules:

  1. Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.

  2. No spam posting.

  3. Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.

  4. Don't duplicate the full text of your blog or github here. Just post the link for folks to click.

  5. Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).

  6. No trolling.

Resources:

Any issues on the community? Report it using the report flag.

Questions? DM the mods!

founded 2 years ago
MODERATORS
 

How do y'all manage all these Docker compose apps?

First I installed Jellyfin natively on Debian, which was nice because everything just worked with the normal package manager and systemd.

Then, Navidrome wasn't in the repos, but it's a simple Go binary and provides a systemd unit file, so that was not so bad just downloading a new binary every now and then.

Then... Immich came... and forced me to use Docker compose... :|

Now I'm looking at Frigate... and it also requires Docker compose... :|

Looking through the docs, looks like Jellyfin, Navidrome, Immich, and Frigate all require/support Docker compose...

At this point, I'm wondering if I should switch everything to Docker compose so I can keep everything straight.

But, how do folks manage this mess? Is there an analogue to apt update, apt upgrade, systemctl restart, journalctl for all these Docker compose apps? Or do I have to individually manage each app? I guess I could write a bash script... but... is this what other people do?

you are viewing a single comment's thread
view the rest of the comments
[–] suicidaleggroll@lemmy.world 1 points 7 hours ago* (last edited 7 hours ago)

There are two ways to maintain a persistent data store for Docker containers: bind mounts and docker-managed volumes.

A Docker managed volume looks like:

datavolume:/data

And then later on in the compose file you'll have

volumes:
  datavolume:

When you start this container, Docker will create this volume for you in /var/lib/docker/volumes/ and will manage access and permissions. They're a little easier in that Docker handles permissions for you, but they're also kind of a PITA because now your compose file and your data are split apart in different locations and you have to spend time tracking down where the hell Docker decided to put the volumes for your service, especially when it comes to backups/migration.

A bind mount looks like:

./datavolume:/data

When you start this container, if it doesn't already exist, "datavolume" will be created in the same location as your compose file, and the data will be stored there. This is a little more manual since some containers don't set up permissions properly and, once the volume is created, you may have to shut down the container and then chown the volume so it can use it, but once up and running it makes things much more convenient, since now all of the data needed by that service is in a directory right next to the compose file (or wherever you decide to put it, since bind mounts let you put the directory anywhere you like).

Also with Docker-managed volumes, you have to be VERY careful running your docker prune commands, since if you run "docker prune --volumes" and you have any stopped containers, Docker will wipe out all of the persistent data for them. That's not an issue with bind mounts.