view the rest of the comments
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!
That's what I do. I always thought I was doing it "wrong" but it just made sense to me. I can also just up/down/etc... compose files to individually pull new images, test things, disable a service, and apply config updates without affecting another container at all.
I even keep my docker config files in a seperate directory so I can backup the docker composes in a second over the network.
I started by using a single mariaDB instance with multiple databases, but now I see the same benefits from moving to one database container per compose file that needs it to make it even more flexible so I don't need to start up mariadb and redis before all of my containers.
File permission problems? Down the compose that needs it, fix it, re-up it without losing any uptime for other services and never having to use docker commands kludged together.