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!
view the rest of the comments
Not sure why Renovate is necessary when Komodo has built-in functionality to update Docker images/containers. I wish there was an option to check less often (like once a day), maximum time is hourly.
Also, if you're using Komodo and have one big repo of compose files, consider just saving your entire config toml to a repo instead. You end up with something akin to Terraform or Cloudformation for your Docker hosts
I haven't used Komodo, but would it commit to the updated docker files to git? Or just use the "latest" tag and follow that? In the latter case you can't easily roll back, nor do you have a reproducible setup.
I guess I don't get that granular. It will respect the current docker compose image path. So. if you have the
latesttag, that's what it will use. Komodo is a big topic: https://komo.doThat seems like a really big downside to me. The whole point of locking down your dependencies and using something like renovate is that you can know exactly what version was used of everything at any given point in time.
If you work in a team in software, being able to exactly reproduce any prior version is both very useful and consider basically required in modern development. NixOS can be used to that that to the entire system for a Linux distro (it is an interesting project but there are parts of it I dislike, I hope someone takes those ideas and make it better). Circling back to the original topic: I don't see why deploying images should be any different.
I do want to give Komodo a try though, hadn't heard about it. Need to check if it supports podman though.
I use it in a homelab, I don't need to apply prod/team/high-availability solutions to my Audiobookshelf or Mealie servers. If an upgrade goes wrong, I'll restore from backup. Honestly, in the handful of years I've been doing this, only one upgrade of an Immich container caused me trouble and I just needed to change something in the compose file and that was it.
I get using these strategies if you're hosting something important or just want to play with new shiny stuff but, in my humble opinion, any extra effort or innovating in a homelab should be spent on backups. It's all fun and games until your data goes poof!
You can do that too with docker tags for the specific major or minor version you want to use.