this post was submitted on 03 Jun 2025
65 points (98.5% liked)

Selfhosted

60451 readers
1080 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:

Detailed Rules Post

  1. Be civil.

  2. No spam.

  3. Posts are to be related to self-hosting.

  4. Don't duplicate the full text of your blog or readme if you're providing a link.

  5. Submission headline should match the article title.

  6. No trolling.

  7. Promotion posts require active participation, with an account that is at least 30 days old. F/LOSS without a paywall has exceptions, with requirements. See the rules link for details.

Resources:

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

Questions? DM the mods!

founded 3 years ago
MODERATORS
 

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
[–] ptz@dubvee.org 21 points 1 year ago

All of mine use bind mounts so I can just tar-gz the whole deploy folder for backups and migrations. For volumes that connect to remote shares (SMB, NFS, etc) I use named volumes and let Docker take care of their lifecycle.

If named docker volumes would let me specify the local filesystem location, I'd use them. As-is, I rarely do.