RE: https://social.lol/@phillip/117061432689860232
The postmortem of the hack on my Forgejo instance is here! I had fun investigating and writing it, so I hope y’all enjoy reading about it :)
Aug 10, 2026, 6:50 PM@phillip thanks for sharing this! @nyanbinary
@phillip Nice write-up! If I could suggest something, since you already run Komodo, you could set up GitOps and automate updates using Renovate (see https://nickcunningh.am/blog/how-to-automate-version-updates-for-your-self-hosted-docker-containers-with-gitea-renovate-and-komodo)
I followed that guide and a couple others from FoxxMD, I don't spend much time thinking about upgrading containers now
@axel Thank you!
This looks interesting, though I'm curious to know what the advantage of this setup is over Komodo's built-in update system?
@phillip Well, I find Komodo's Automatic Updates too inflexible.
As you outlined in your article, it requires a rolling tag (like :latest) which brings its share of issues. What if a breaking change is introduced? What if someone published a malicious version?
Whereas GitOps+renovate allows for fine-grained updates and the use of versioned and pinned images (e.g. image:x.y.z@sha:256fff…).
For example, my renovate config does:
@axel Ah, that makes sense! I auto-update a couple less important containers. For most of them though, Komodo just notifies me of available updates, so I have a chance to check release notes in my RSS feed, then manually apply the updates.
The ability to delay auto-updates by a few days is awesome, and the extra control is pretty sweet. I’ll take a closer look at this setup. Thanks for sharing!
@phillip What you describe (checking releases notes in your RSS feed then manually applying updates) is what I was doing before, but I was growing tired of all the manual work and often did not update images for weeks. This is what ultimately drove me to Komodo and the GitOps workflow.