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.
-
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.
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
Thanks for this - the one advantage I'm noticing is that to update the services I'm running, I have to rebuild the container. I can't really just update from the UI if an update is available. I can do it, it is just somewhat of a nuisance.
How often are there issues with dependencies? Is that a problem with a lot of software these days?
But rebuilding your container is pretty trivial from the command line all said and done. I have something like this alias'd in my .bashrc to smooth it along:
Docker compose pull; docker compose down; docker compose up -d
I regularly check on my systems and go through my docker dirs and run my alias to update everything fairly simply. Add in periodic schedule image cleanups and it has been humming along for a couple years for the most part (aside from one odd software issues and hardware failures).
I started using docker 3-4 years ago specifically because I kept having issues with dependencies of one app breaking others, but I also tend to run a lot of services per VM. Honestly, the overhead of container management is infinitely preferable to the overhead that comes with managing OS level stuff. But I'm also not a Linux expert, so take that for what you will.
Is there a specific reason you're taking the services down before bringing them back up? Just
docker compose pull && docker compose up -drecreates all services that had a new image pulled, but leaves the others running.Probably just a hold over from when I was first learning. Had issues with a couple services not actually updating without it, so I just do it to be absolutely sure. Also, I only ever run one app per compose, so that forces a "reboot" of the whole stack when I update.
I know rebuilding containers is trivial, but updating a service in the UI is more trivial than that. I'm just trying to make my life as trivial as possible 😁. It seems like containers may be worth the little bit of extra effort.
I mean, for anything where you're willing to trust the container provider not to push breaking changes, you can just run Watchtower and have it automatically update. That's how most of my stuff runs.
If you're not using some sort of automatic updates, you're not too seriously trying to make your life as trivial as possible. 😂 Just use fixed major version tags where possible in order to avoid surprise breakage.