Selfhosted

I have a shell script that handles all the quircks. I run it every few weeks. It does a btrfs snapshot so I can go back in case something is wrong, and after it updates Docker and Podman to the latest label.

For services not containized I have some automation to fetch the last version from internet (for example some home assistant addons that are just js files).

For the updates that are more difficult to script (or just not worth because they are very infrequent) I have a script that compares the running version with what published on their website and warns me I have a manual update.

Since most of the projecs I host have a gitub page it is relatively simple to write reusable code to do this stuff.

In general I don't trust automatic updates, there are seldom issues but they can be annoying to fix. So I just prefer to updates by hand whenever I have a few minutes free and I know I have direct access to the server in case the connection drops.

I'd definitely go with Renovate + ArgoCD, or any other GitOps-based tooling.

Unattended upgrades 11 months out of the year.

Very attended apt upgrades 2 weeks out of the year.

Snapshots and for i in $hosts;do ssh -tt "sudo apt update -y && sudo apt upgrade -y";done

For docker/k8s: argocd, helm, etc.

Ansible. Basically if I need to upgrade something for the first time, I write or extend an Ansible script an run those periodically.

I use dockhand right now, but I used to just use compose pull

Proxmox helper scripts - at least the ones i use - come with a tag updateable. Those tagged have a command update that runs everything necessary on containers, VMs whatever.

Makes life simple, mostly.

The only manual interaction I’ve had was upgrading some VMs Debian from 12 to 13.

I just run watchtower in docker. It will watch all your other docker images and update them to latest version automatically if you want.

It works fine but with time, I stopped thinking i need to be on latest version all the time. It really isnt very important.

Just a few of my services are open on the internet, mainly caddy and wireguard.

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.

Renovate couple with FluxCD if you're in k8s land, or noco-cd if you're on docker. GitOps is the way.

1. Avoid anything with bad supply chains that fail iso27002
2. Yum via cron
3. Huh. That's all of it.