[Feature Request]: Switch official documentation and default compose example to Bind Mounts instead of Named Volumes

[djschny]

🚀 Feature Summary

Switch official documentation and default compose example to Bind Mounts instead of Named Volumes

📝 Detailed Description

The current default docker-compose.yml configuration in the official documentation utilizes Docker Named Volumes (zerotier: and postgres-data:) rather than relative Bind Mounts.

The Problem

Named volumes completely abstract and hide the container data away from the local host project directory (burying them deep inside /var/lib/docker/volumes/ or within internal system roots). When users need to perform basic server operations—such as backing up their data locally, modifying host files, or migrating the stack to a completely different host server—the layout becomes highly confusing and opaque because the raw data files are missing from the visible local filesystem.

While named volumes sidestep immediate Linux permission/UID conflicts for first-time builders, they create a major roadblock for long-term server management.

Suggested Solution

Update the official installation documentation and default docker-compose.yml example to map container data directly to the host filesystem using relative bind mounts instead:

postgres:
...
volumes:
- ./postgres-data:/var/lib/postgresql/data

zerotier:
...
volumes:
- ./zerotier-data:/var/lib/zerotier-one

(And completely remove the global 'volumes:' abstraction block at the bottom of the layout).

This simple adjustment gives users full visibility and direct file system control over their configurations, databases, and network identities right next to their compose file.

🎯 Use Case

No response

💡 Willing to Contribute

Yes