What self-hosting advice do you wish you knew earlier?

2 weeks ago 2

That's a great example. As you continue your docker journey, you'll likely encounter more than one service that requires a DB backend.

So, for instance, you get Immich running (with both the Immich service AND the required DB service) and now you've got a postgreSQL container to handle your Immich DB that talks to your Immich container. Yay.

What if you spool up another service with another docker compose file that requires a postgreSQL DB? In theory, you can just use the one postgreSQL instance you spooled up for Immich and point both services to it to save memory or whatever.

(Here's where I would like to hear from the rabble on best practices)

My inclination, especially if you're newer with dealing with containers and SQL is scary for you, is to NOT try and configure your new service to use your existing postgreSQL container, but to just follow whatever the default docker compose file has and use that.

But now I have a whole extra container running! Oh no! Yea, so what? They're not using a lot of resources (in general) so what's the harm?

Point is 99% of the time you can trust the docker compose for each service as the whole point of them is to keep things contained for just that one service. You can do next level ninja stuff once you're more experienced, but for now, you can largely trust the docker compose files that are provided by folks who have more experience and all you have to worry about is just running it and using the thing you wanted!

I am VERY guilty of overthinking things and falling down rabbit holes, but I'm getting better at asking myself "Ok yea, it'd be cool to dig into all the supporting infrastructure and know that crap, but do I really need to? Isn't using the thing I want the spool up more exciting?"

Read Entire Article