this post was submitted on 03 Jun 2025
60 points (98.4% liked)

Selfhosted

46677 readers
361 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
ruud@lemmy.world
Loki@lemmy.world
CannaVet@lemmy.world
HybridSarcasm@lemmy.world
devve@lemmy.world
HybridSarcasm@lemmy.hybridsarcasm.xyz
60
Why all docker compose files use the managed docker volumes instead of directly mounting a custom directory? (lemmy.pe1uca.dev)
submitted 3 days ago by pe1uca@lemmy.pe1uca.dev to c/selfhosted@lemmy.world
15 comments fedilink hide all child comments
 

All docker files look something like this

services:
  service_name:
    image: author/project:latest
    container_name: service_name
    volumes:
      - service_data:/app/data/

volumes:
  service_data:

Yes, this makes the data to persist, but it creates a directory with a random name inside /var/lib/docker/volumes/
This makes it really hard to actually have ownership of the data of the service (for example to create backups, or to migrate to another host)

Why is it standard practice to use this instead of having a directory mounted inside at the same level you have your docker-compose.yml?
Like this - ./service_data:/app/data

you are viewing a single comment's thread
view the rest of the comments
[–] rumba@lemmy.zip 6 points 2 days ago

I think the primary reason is that it was designed to be a larger install than what most of you are using.

If you're doing a giant k8s, with a bunch of pods that come and go dynamically, portability, consistency, and management are key. And for the most part you're not handling long-term persistent data the same way as you do when you're just installing containers on your home lab or development environment.

But since most people don't have this constraints, blind mounts make a hell of a lot more sense if you were only running one server in one location.