Selfhosted
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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
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.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
Is there any advantage to bind mounting that way? I've only ever done it by specifying the path directly in the container, usually
./data:dataor some such. Never had a problem with it.with the way I do it, you can also use NFS as a backend
https://docs.docker.com/reference/compose-file/volumes/
Well, I know you can define volumes for other filesystem drivers, but with bind mounts, you don't need to define the bind mount as you do, you can just specify the path directly in the container volumes and it will bind mount it. I was just wondering if there was any actual benefit to defining the volume manually over the simple way.
In my case I need to use a named volume for docker swarm, also I can reuse a named volume in other services. If your not using swarm then just a bind mount should be fine
OK, yah, that's good point about swarms. I've generally not used any swarmed filesystem stuff where I needed persistence, just shared databases, so it hasn't come up.