Selfhosted

Everything I run, I deploy and manage with ansible.

When I'm building out the role/playbook for a new service, I make sure to build in any special upgrade tasks it might have and tag them. When it's time to run infrastructure-wide updates, I can run my single upgrade playbook and pull in the upgrade tasks for everything everywhere - new packages, container images, git releases, and all the service restart steps to load them.

It's more work at the beginning to set the role/playbook up properly, but it makes maintaining everything so much nicer (which I think is vital to keep it all fun and manageable).

Renovate + GitOps. Check out https://github.com/onedr0p/cluster-template

If you don't like Kubernetes, you can get a similar setup with doco-CD. Only limitation is that dococd can't update itself, but you can use SOPS and Renovate all the same for the other services.

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.

Podman automatically updates my containers for me.

FluxCD and renovate working together.

All of my self-hosted systems are on a TrueNAS system and using the built-in app system (basically docker). It notifies me when they're needing updates, and has a single click update process for everything. I just login weekly to see if the button is yellow, then check on it like 15 minutes later to see if anything failed to update. Yeah they're all on the same hardware, which is probably bad, but nothing there is strictly necessary, it's all just media stuff and for fun.

The one service that is separate is Pangolin on a DigitalOcean droplet. I just handle that manually when it says there's an update. Still effectively just docker, but no easy button.

I could automate these more, but I would spend more time setting it up than I would save since it only takes me a couple minutes maybe once a week.

I do it manually. update the container version and docker pull and run

I have reduced the number of containers to ones i actually use, so it is manageable.

i use v2 instead of v2.1.0 docker container tags if the provider don't make too many bleeding edge changes between updates

• use APT repositories when possible -> then unattended-upgrades
• For OCI images that do not provide tagged releases (looking at you searxng...), podman auto-update
• for everything else, subscribe to releases RSS feed, read release notes when they come out, check for breaking changes and possibly interesting stuff, update version in ansible playbook, deploy ansible playbook

I run NixOS. Go to the flake file and update channel version.

I don't use docker, etc, so for me, if it's in the normal Arch repos or AUR then I don't need to think about it until there's a .pacnew file to look at

Then, it's just the odd git pull on literally 2 devices.

All organised by ansible...

(well except the .pacnew, but I think it's nice to keep in touch with the packages)

Kubernetes + helm charts

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 that package managers have caused the exact problem that they are supposed to solve.

# nix flake update
# nixos-rebuild switch

One of the reasons I switched to YunoHost (the other being backups).

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.

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 🤷

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.

cd appname && dockup && cd ..

Dockup being an alias for docker compose pull && docker compose up -d

Repeat for the few services I have.

Fine, I'll be the low bar.

Proxmox, I just use the GUI to update

I use community-scripts almost exclusively. Community-scripts cron lxc updater does the heavy lifting. pct enter [lxc]

update

does a bunch of work too.

For Docker, I use a couple lxcs with Dockge on it, the "update" button takes me most of the rest of the way.

Finally, I have a couple remote machines [diet-pi]. I haven't figured out updating over tailscale yet, so I just go round semi frequently for the apt update && apt upgrade -y

VMs get the apt update && apt upgrade -y too. I keep a bare bones mint VM as a virtual laptop, as I don't have one. I'll do what I need to do and if I had to install software I'll just nuke the VM and go again from the bare bones template.

Since all my services are dockerized I just pull new images sporadically. But I think I should invest some time into finding automatic update reminders, especially when I have to hear about critical security updates from some random person on mastodon.

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

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

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

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).

Arcane docker server checks for updates, notifies me when they're available

for security relevant stuff I just get notifications of new github releases

Personally I just wrote a bash script that does all of my regular updates and I run it manually whenever

Proxmox community scripts has some nice update tools

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.

https://en.wikipedia.org/wiki/Puppet_(software)

A dedicated Forgejo instance f.example.com.

For a small set of trusted "base" images (e.g. docker.io/alpine and docker.io/debian): A Forgejo Action on separate small runner, scheduled on cron to sync images to f.example.com/dockerio/ using skopeo copy.

Then all other runners have their docker/podman configuration changed to use that internal forgejo container registry instead of docker.io.

Other images are built from source in the Forgejo Actions CI. Not everything needs to be (or even should) be fully automated right off. You can keep some workflows manual while starting out and then increase automation as you tighten up your setup and get more confident in it. Follow the usual best practices around security and keep permissions scoped, giving them out only as needed.

Git repos are mirrored as Forgejo repo mirrors, forked if relevant, then built with Forgejo Actions and published to f.example.com/whatever/. Rarely but sometimes is it worth spending time on reusing existing Github Workflows from upstreams. More often I find it easier to just reuse my own workflows.

This way, runners can be kept fully offline and built by only accessing internal resources:

• apt/apk repo mirror or proxy
• synced base container images
• synced git sources

Same idea for npm or pypi packages etc.

Set up renovate^1^ and iterate on its configuration to reduce insanity. Look in forgejo and codeberg infra repos for examples of how to automate rebasing of forked repo onto mirrors.

I would previously achieve the same thing by wiring together more targeted services and that's still viable but Forgejo makes it easy if you want it all in one box. Just add TLS.

^1^: Or anyone have anything better that's straightforward to integrate? I'm not a huge fan of all the npm modules it pulls in or its github-centric perspective. Giving the same treatment to renovate itself here was a little bit more effort and digging than I think should really be necessary.