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.
-
No spam.
-
Posts are to be related to self-hosting.
-
Don't duplicate the full text of your blog or readme if you're providing a link.
-
Submission headline should match the article title.
-
No trolling.
-
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. Tags [CBH] or [AIP] are required, see the links in Rule 8 for details.
-
AI-related discussions and AI-involved promotional posts have additional requirements for tagging, as noted in Rule 7 and the AI & Promotional Post Expanded Rules post, and find example disclosures here.
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
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:/dataAnd then later on in the compose file you'll have
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:/dataWhen 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.