this post was submitted on 14 Jun 2026
36 points (100.0% liked)
Selfhosted
59854 readers
775 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:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam.
-
Posts here are to be centered around self-hosting. Please ensure it is clear in your post how it relates to self-hosting.
-
Don't duplicate the full text of your blog or git here. Just post the link for folks to click.
-
Submission headline should match the article title.
-
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!
founded 3 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I use a single centralized database running directly on the host (postgres) and make it accessible to the docker clusters.
Pros: It's all in one place to backup all important data for every service, I find this a much easier and more reliable way to backup all services, and I'm confident if you tried it you would too. The application data becomes a first-class citizen instead of hiding inside some nameless docker volume. Significantly less database overhead. Consistent database version and tools.
Cons: Lots. You need to manage and backup the database. You need to manage the database users and passwords too. Making the DB accessible to the docker clusters is nontrivial and can be fragile. You can no longer use the default "official" docker compose files, since they will almost never support an actual database service without several modifications, they're always built for spinning up their own docker container database. So you're going to be doing a bunch of work setting up users and passwords and performing extensive surgery on the docker-compose before you even start up the application, which adds a lot of friction, with lots of opportunity for error. All things considered, it's actually quite painful. Technically if one application abuses your database hard enough and exhausts its memory to crash it or something it would affect other applications too, but that's true of any services running on shared hardware abusing anything on that hardware, so it's not a realistically concerning con.
I consider it worthwhile, but I might be wrong. Also I hate docker in general. I understand why people use it. It's the same reason I use it. But I still hate it. I think system installations are so much easier to manage in the long run, but initially more work, and you need to invest that work at a time when you're not even sure if you really want to run this application or if it's going to be compatible with the rest of your environment. So docker is the easy solution. But then you're basically trapped in dockerland. It's not that bad, I just hate it in principle. I wish there were a better way.
Same, exactly what I do. For the part about backups, there are tools that make it really easy. I'm using databasus for instance. Once I had set up a couple applications, adding a new db, user, and backup config took just a few minutes every time really. In the end figuring out how to backup every docker stack's individual DB sounds more complicated to me.
Edit: plus my first service hosted in this lab was my own matrix instance so I needed a solid DB, then it was already there so might as well use it.