automating dependency updates with renovate

I have a public Kubernetes repo (actually has a lot of stars) that I have sort of forgotten about. Versions of images there are always outdated :(

I was updating them manually ever so often. I would check Docker Hub, see if there’s a new version, update the tag, commit, push. It’s not hard, but it’s tedious, and I’d go weeks (or months) without checking. That’s not great when you’re running things like MySQL and Postgres that get security patches regularly.

So I set up Renovate.

Renovate is a bot that scans your repo for dependency references — Docker images, Helm charts, npm packages, whatever — and opens pull requests when new versions are available. It’s like Dependabot but more configurable and it supports way more ecosystems.

I’m using the hosted version through the Mend Developer Portal. You install the Renovate GitHub App on your repos and it runs on their infrastructure. No self-hosting required.

The setup is straightforward. Install the Renovate GitHub App from the Mend Developer Portal, point it at your repo, and it creates an onboarding PR with a default renovate.json config.

Here’s what my config looks like:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended",
    "docker:enableMajor"
  ],
  "kubernetes": {
    "fileMatch": [
      "\\.ya?ml$"
    ]
  }
}

That’s it. Three things happening here:

1. config:recommended — Renovate’s sensible defaults. Handles scheduling, automerge rules, and grouping.

2. docker:enableMajor — by default Renovate won’t open PRs for major version bumps on Docker images. I want to know about those, so I enable them.

3. kubernetes.fileMatch — tells Renovate to scan .yml and .yaml files for Kubernetes manifests with container image references.

Before Renovate can track your images, you need actual version tags. If you’re running image: someimage:latest, Renovate has nothing to work with. It can’t tell you there’s a new version if you’re already pointing at “whatever’s newest.”

I went through all my manifests and pinned every :latest tag to a specific version. Tedious, but you only do it once. After that, Renovate handles it.

Renovate scanned the repo, found 53 dependencies across all my manifests, and immediately opened 13 pull requests. Everything from minor patch bumps to major version upgrades:

• AdGuard Home → v0.107.73

• Nextcloud → v33.0.2

• MySQL → v9.6.0

• Postgres → v18.3

• MariaDB → v12.2.2

• Pi-hole → v2026.04.0

• Ghost → v6.27.0

• Uptime Kuma → v2.2.1

And a bunch more. Each PR updates a single image tag in the deployment YAML. Clean diffs, easy to review.

I merged all 13. Some were major version bumps (MySQL 8 → 9, Postgres 17 → 18, MariaDB 11 → 12) which normally I’d be cautious about, but this is for homelabbers. Worst case I roll back.

After the initial wave of PRs, Renovate creates an issue called “Dependency Dashboard” (issue #26 in my repo). This stays open permanently — it’s a living tracker that updates every run, showing all detected dependencies and any pending PRs. It’s a nice way to see the state of everything at a glance.

A few things I ran into:

Config file location. renovate.json must be at the repo root. Not in a subdirectory, not next to your manifests. Root. If Renovate finds zero dependencies, check this first.

LinuxServer image tags. LinuxServer images on lscr.io publish some messy tags — commit hashes like 438eee94-ls46, nightly builds, develop tags. Renovate’s built-in maxMajorIncrement filter caught these on my repo and didn’t create bad PRs, but it’s worth knowing about. If you do run into issues, you can add an allowedVersions regex to your package rules that only matches clean X.Y.Z tags.

Branch protection. If you have branch protection enabled, Renovate can create PRs but you might need admin privileges to merge them. Just something to be aware of.

Absolutely. Took maybe 30 minutes to set up, and now I don’t have to think about it. Renovate runs on a schedule, opens PRs when something changes, and I merge when I’m ready. For a homelab with 20+ services, that’s a lot of manual checking I no longer have to do.

The Dependency Dashboard issue gives me a snapshot of everything, and the individual PRs make it easy to see exactly what changed. If an update breaks something, the git history makes it obvious which image bump caused it.

If you’re running Kubernetes manifests with pinned image tags — even just a handful — it’s worth the 30 minutes.

Cheers,

Joe