Back in the day it was nice, apt get update && apt get upgrade and you were done.

But today every tool/service has it’s own way to being installed and updated:

  • docker:latest
  • docker:v1.2.3
  • custom script
  • git checkout v1.2.3
  • same but with custom migration commands afterwards
  • custom commands change from release to release
  • expect to do update as a specific user
  • update nginx config
  • update own default config and service has dependencies on the config changes
  • expect new versions of tools
  • etc.

I selfhost around 20 services like PieFed, Mastodon, PeerTube, Paperless-ngx, Immich, open-webui, Grafana, etc. And all of them have some dependencies which need to be updated too.

And nowadays you can’t really keep running on an older version especially when it’s internet facing.

So anyway, what are your strategies how to keep sanity while keeping all your self hosted services up to date?

  • totoro@slrpnk.netEnglish
    0·
    12 days ago

    Wow, that sounds like a nightmare. Here’s my workflow:

    nix flake update
nixos-rebuild switch

    That gives me an atomic, rollbackable update of every service running on the machine.

  • irmadlad@lemmy.worldEnglish
    0·
    12 days ago

    I keep it simple, although reading down through the thread, there are some really nice and ingenious ways people accomplish about the same thing, which is totally awesome. I use a WatchTower fork and run it with --run-once --cleanup. I do this when I feel comfortable that all the early adopters have done all the beta testing for me. Thanks early adopters. So, about 1 a month or so, I update 70 Docker containers. As far as OS updates, I usually hit those when they deploy. I’m running Ubuntu Jammy, so not a lot of breaking changes in updates. I don’t have public facing services, and I am the only user on my network, so I don’t really have to worry too much about that aspect.

  • ryan_@piefed.socialEnglish
    0·
    12 days ago

    It’s just a hobby so i know I have room for improvement, but the bigger my environment gets the more difficult it is to keep everything completely up to date, like you said. Given that, my main priorities are:

    • have as few internet facing services as possible
    • use a reverse proxy
    • separate external and internal servers with a dmz
    • use fail2ban or crowsec on servers that have ports forwarded
    • firewall geoblocking
    • BACKUPS, local and remote

    Now that being said, I’ve started to use ansible playbooks for deploying OS updates. I have a playbook that uses default options when doing an apt upgrade and it also works for the docker engine user prompt.

    About 75% of my services are native installs in LXCs and I try to always install by including the app repo so that apt can update it and the other 25% are in docker. I used to use watchtower but that’s no longer maintained, so I do container updates manually as needed.

    It’s not perfect, but it’s just for fun so 🤷

  • pHr34kY@lemmy.worldEnglish
    0·
    12 days ago

    I wonder if anyone ever wrote an update aggregator that would find all package managers, containers and git repos and whatnot and just do all of them.

    Some are a right pain to update, such as Nextcloud. Installing a monthly update should not feel like an enterprise prod deployment.

    It’s kinda ironic is that package managers have caused the exact problem that they are supposed to solve.

    • Jeena@piefed.jeena.netOPEnglish
      0·
      12 days ago

      I am developing a script which will do that specifically for my services.

      Right now at the first stage it only checks GitHub, Codeberg, etc. To check if there is a new version compared to what each service is running right now.

      https://git.jeena.net/jeena/service-update-alerts

      I am extending it now with a auto update part, but it’s difficult because sometimes I can’t just call a static script because some other migration things need to run. So I have a classifier which takes the release notes and let’s a local LLM to judge if it’s OK to run the automation or if I need to do it manually. But for that I am collecting old release notes as examples from each service. This takes forever to do so I only have it done for PieFed, PeerTube, Immich and open-webui, and I didn’t push those changes to the public repo yet.

  • ccryx [he/him]@discuss.tchncs.deEnglish
    0·
    12 days ago

    All my services run in podman containers managed by systemd (using quadlets). They usually point to the :latest tag and I’ve configured the units to pull on start when there is a new version in my repository. Since I’m using opensuse microos, my server (and thus all services) restart regularly.

    For the units that are configured differently, I update the versions in their respective ansible playbooks and redeploy (though I guess I could optimize this a bit, I’ve only scratched the surface of ansible).

    • BlackEco@lemmy.blackeco.comEnglish
      0·
      12 days ago

      I guess auto merge isn’t enabled, since there’s no way to check if an update doesn’t break your deployment beforehand, am I right?

        • BlackEco@lemmy.blackeco.comEnglish
          0·
          12 days ago

          Yes, but usually when you use automerge you should have set up a CI to make sure new versions don’t break your software or deployment. How are you supposed to do that in a self-hosting environment?

          • tofu@lemmy.nocturnal.gardenEnglish
            0·
            12 days ago

            Ideally, you have at least two systems, test updates in the dev system and only then allow it in prod. So no auto merge in prod in this case or somehow have it check if dev worked.

            Seeing which services are usually fine to update without intervening and tuning your renovate config to it should be sufficient for homelab imho.

            Given that most people are running :latest and just yolo the updates with watchtower or not automated at all, some granular control with renovate is already a big improvement.

  • Sanctus@anarchist.nexusEnglish
    0·
    12 days ago

    Damn I’m lucky I just run small game servers cause the old way still works for me, aside from piehole that needs to be updated but it squeels at me when it needs it so I dont have to remember.

  • Eldaroth@lemmy.worldEnglish
    0·
    11 days ago

    I run most of my services in containers with Podman Quadlets. One of them is Forgejo on which I have repos for all my quadlet (systemd) files and use renovate to update the image tags. Renovate creates PRs and can also show you release notes for the image it wants you to update to.

    I currently check the PRs manually as well as pulling the latest git commits on my server. But this could also be further automated to one’s liking.

  • Decronym@lemmy.decronym.xyzBEnglish
    0·
    12 days ago

    Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:

    Fewer Letters More Letters
    Git Popular version control system, primarily for code
    HTTP Hypertext Transfer Protocol, the Web
    LXC Linux Containers
    nginx Popular HTTP server

    3 acronyms in this thread; the most compressed thread commented on today has 3 acronyms.

    [Thread #233 for this comm, first seen 12th Apr 2026, 05:50] [FAQ] [Full list] [Contact] [Source code]

  • corsicanguppy@lemmy.caEnglish
    0·
    11 days ago
    1. Avoid anything with bad supply chains that fail iso27002
    2. Yum via cron
    3. Huh. That’s all of it.
  • quick_snail@feddit.nlEnglish
    0·
    11 days ago

    Unattended upgrades 11 months out of the year.

    Very attended apt upgrades 2 weeks out of the year.