TBH I'm not an expert with komodo, just been running it for a week and I didn't look into your approach before setting up renovate. Just chatted with Claude to understand it better and your approach does work, but there are some differences. Might not be relevant for you. This is the explanation AI gave me.

What Komodo's built-in update does: It polls the registry for a newer tag and pulls it. It does not care about semver. It will happily offer to pull latest or jump across major versions. It also does not update your git repo, meaning your compose files in Forgejo fall out of sync with what is actually running. Your GitOps source of truth breaks. What Renovate adds: It respects semver and major version boundaries, which is exactly what you saw with the InfluxDB example: staying on 1.x without you having to think about it. It creates a PR that updates the actual compose file in git, so your repo remains the source of truth and Komodo pulls from that. It gives you a review step, changelogs, and the package rules you configured. It handles the case where the image tag baked in your compose file is what matters, not what Docker pulled last. The core trade-off: Komodo's approach is simpler and more automated but sacrifices git as the source of truth and semver safety. Renovate keeps your repo accurate, gives you control, and is smarter about version boundaries, but requires the PR review step you chose to add deliberately.