Updates, die sich selbst vorschlagen: Abhängigkeiten mit Renovate

Beim Patchen denkt man an das Betriebssystem. Unter jeder Anwendung liegt aber eine zweite Schicht, die genauso altert: Base-Images, Chart-Versionen, Bibliotheken, Action-Versionen. Ohne Werkzeug bedeutet das Aktualisieren dieser Schicht Handarbeit an vielen verstreuten Stellen. Renovate macht daraus einen Prozess.

Dieser Beitrag zeigt die Wahl der Betriebsart, die Installation mit Prüfschritt nach jedem Abschnitt, die Validierung der Konfiguration und die Steuerung der erzeugten Pull Requests.

Wann Renovate das richtige Werkzeug ist

Renovate lohnt sich, sobald Versionen an mehreren Stellen im Repository stehen und niemand mehr sicher sagen kann, welche davon veraltet sind. Es kann Lockfiles allerdings nicht rückwärts interpretieren, sondern patcht die Package-Datei und überlässt deren Aktualisierung dem jeweiligen Paketmanager, der deshalb in der Laufumgebung verfügbar sein muss.

Ein zweiter Punkt gehört vor die Installation: Self-gehostete Instanzen setzen laut Dokumentation ein Vertrauensverhältnis zu den Entwicklern der überwachten Repositories voraus, weil der Bot bei manchen Ökosystemen fremden Code aus dem Repository ausführt. Das bestimmt mit, in welchem Netzsegment die Instanz stehen darf.

Die Betriebsarten im Vergleich

Renovate wird als npm-Paket, als Container-Image, als GitHub Action, über das GitLab-Projekt Renovate Runner, als Mend Renovate Self-Hosted sowie als gehostete Mend-App ausgeliefert.

Die Details stehen in der Dokumentation zu den Betriebsarten. Ich halte die CI-Variante für die tragfähigste, wenn ohnehin eine Pipeline existiert, weil sie Secret-Verwaltung, Protokollierung und Zeitsteuerung von einem bereits betriebenen System erbt.

Schritt 1: Laufumgebung prüfen und installieren

Die package.json von Renovate setzt engines.node auf ^24.11.0, die Release-Notes zu 43.0.0 nennen Node 24 als Mindestanforderung.

node --version

Prüfung: Die Ausgabe muss im Bereich v24.11.0 bis unterhalb von v25 liegen, den ^24.11.0 abdeckt. Beim Container-Weg kommt eine zweite Prüfung dazu, denn die Renovate-Images laufen nicht als Windows- oder macOS-Container. docker version --format '{{.Server.Os}}' muss linux ausgeben.

Für die npm-Variante installieren Sie das Paket global, dazu die Paketmanager für die Lockfile-Aktualisierung.

npm install -g renovate yarn pnpm

Prüfung:

renovate --version && yarn --version && pnpm --version

Alle drei Befehle müssen eine Version ausgeben. Fehlt ein Paketmanager, schlägt später die Lockfile-Aktualisierung fehl, nicht schon die Installation. Bei der Container-Variante läuft Renovate direkt aus dem Image.

docker run --rm -v "/path/to/your/config.js:/usr/src/app/config.js" renovate/renovate

Schritt 2: Zugangsdaten setzen

RENOVATE_TOKEN authentifiziert gegen die Plattform, RENOVATE_PLATFORM benennt ihre Art, RENOVATE_ENDPOINT zeigt auf selbst betriebene Instanzen.

export RENOVATE_PLATFORM=gitlab
export RENOVATE_ENDPOINT=https://gitlab.lab.rz.jabi-it.de/api/v4/
export RENOVATE_TOKEN=<plattform-token>
export RENOVATE_GITHUB_COM_TOKEN=<token-fuer-github-com>

RENOVATE_GITHUB_COM_TOKEN ist keine Nebensache, auch wenn Ihre Plattform GitLab heißt. GitHub begrenzt unauthentifizierte API-Anfragen stark, und ohne eigenen Token läuft der Bot beim Abholen der Changelogs schnell in das Rate-Limit. Der GitLab-Token braucht für echte Läufe den Scope api, für Trockenläufe genügt read_api.

Prüfung: Im Log eines Trockenlaufs mit LOG_LEVEL=debug darf keine Rate-Limit-Warnung gegen api.github.com erscheinen, und die Repository-Liste muss erkennbar aufgebaut werden.

Schritt 3: Konfiguration anlegen und validieren

Aktivieren Sie Renovate auf einem Repository, legt der Bot zunächst einen Onboarding-Pull-Request mit dem Titel „Configure Renovate“ an. Bis dieser PR gemergt ist, ändert Renovate nichts weiter am Repository.

Die Konfiguration darf unter anderem in renovate.json, .github/renovate.json5 oder .renovaterc.json liegen, der Weg über package.json ist veraltet. Als Ausgangspunkt genügt config:recommended, die Empfehlung der Dokumentation für die meisten Anwender. Wer strenger fahren will, nimmt config:best-practices mit docker:pinDigests, :pinDevDependencies und :maintainLockFilesWeekly. Die Dokumentation bezeichnet es als Preset für fortgeschrittene Nutzer, die wöchentliche Lockfile-Wartung erzeugt eigene Pull Requests.

Bevor der Bot startet, gehört die Konfiguration durch den Validator, den jede Renovate-Distribution mitbringt. Er bricht mit einem Exit-Code ungleich null ab, sobald Warnungen oder Fehler auftreten, und eignet sich damit direkt als CI-Job. --strict lässt ihn zusätzlich fehlschlagen, wenn die Konfiguration migriert werden müsste.

npx --yes --package renovate -- renovate-config-validator --strict ; echo "Exit-Code: $?"

Prüfung: Der Exit-Code muss 0 sein. Die weiteren Aufrufformen stehen in der Dokumentation zur Konfigurationsvalidierung.

Ich halte diesen Job für den wichtigsten Einzelbaustein der Strecke, weil ein Tippfehler sonst erst im Bot-Lauf auffällt und dort still bleibt.

Schritt 4: Trockenlauf

Das CLI-Flag --dry-run kennt die Werte extract, lookup und full und protokolliert Meldungen, statt Branches oder Pull Requests anzulegen.

LOG_LEVEL=debug npx --yes --package renovate -- renovate --dry-run=extract meine-gruppe/mein-repo

Prüfung: Im Debug-Log muss die Liste der erkannten Manager und der ihnen zugeordneten Dateien auftauchen. Fehlt ein Manager, greift entweder sein Dateimuster nicht oder er ist nicht aktiviert. Der argocd-Manager etwa erkennt ohne gesetzte managerFilePatterns überhaupt keine Datei, weil sich ArgoCD-Dateinamen nicht automatisch bestimmen lassen. Den Einstieg in ArgoCD zeigt der Beitrag ArgoCD deployen und die erste App ausrollen.

Ist die Extraktion plausibel, wiederholen Sie den Lauf mit --dry-run=full. Erst danach lassen Sie Renovate ohne Flag laufen.

Schritt 5: Die Menge der Pull Requests steuern

Ein unkonfiguriertes Renovate erzeugt für jede Abhängigkeit einen eigenen Pull Request. Vier Optionen greifen dagegen.

schedule legt Zeitfenster fest. Die Cron-Syntax hat fünf Teile, Renovate unterstützt keine Minutengranularität, die Auflösung beträgt mindestens eine Stunde. Zeitpläne laufen per Default in UTC, eine andere Zone setzen Sie über timezone. Die Regeln stehen in der Dokumentation zum Scheduling.

prConcurrentLimit begrenzt die gleichzeitig offenen Pull Requests, Default ist 10. prHourlyLimit begrenzt die pro Stunde neu erstellten, Default ist 2. Bei beiden bedeutet 0 kein Limit. prHourlyLimit bremst ausschließlich die PR-Erstellung, denn Renovate kann bestehende Branches weiter rebasen und damit CI-Läufe auslösen. Wer die Rate der CI-Läufe strikt kontrollieren will, nimmt laut Dokumentation commitHourlyLimit, dessen Default 0 lautet und das damit ohne Konfiguration nicht bremst. groupName in packageRules fasst mehrere Updates zu einem kombinierten Pull Request zusammen.

{
  "extends": ["config:recommended"],
  "timezone": "Europe/Berlin",
  "schedule": ["* 0-4,22-23 * * 1-5", "* * * * 0,6"],
  "prConcurrentLimit": 10,
  "prHourlyLimit": 2,
  "commitHourlyLimit": 4,
  "packageRules": [
    { "matchUpdateTypes": ["minor", "patch"], "groupName": "nicht-major" }
  ]
}

Prüfung: Nach dem nächsten Lauf die Zahl offener Renovate-Pull-Requests gegen prConcurrentLimit abgleichen. Liegt sie darüber, greift Ihre Konfiguration nicht.

Für den Überblick sorgt das Dependency Dashboard, ein Repository-Issue mit dem Status aller Updates. Die Option dependencyDashboard hat den Default false, aktiv wird das Dashboard erst über das Preset :dependencyDashboard, das config:recommended einbindet.

Schritt 6: Automerge

Renovate merged nicht, bevor es grüne Status-Checks für den Branch sieht und der Branch zum Ziel-Branch aktuell ist. Wer keine Tests hat und trotzdem automergen will, braucht "ignoreTests": true, wovon die Dokumentation zum Automerge ausdrücklich abrät.

{
  "packageRules": [
    {
      "matchUpdateTypes": ["minor", "patch"],
      "matchCurrentVersion": "!/^0/",
      "automerge": true
    }
  ]
}

Der Ausschluss von 0.x ist kein Schmuck. Bei Nullerversionen sagt die Versionsnummer nichts Verlässliches über die Verträglichkeit einer Minor-Anhebung aus.

Prüfung: Am offenen Pull Request müssen alle Status-Checks grün und der Branch zum Ziel-Branch aktuell sein. Auf GitLab muss zusätzlich der Pipeline-Schedule aktiv sein, der den Renovate Runner auslöst.

Die drei folgenreichsten Stolpersteine

1. Renovate legt keine Update-PRs an

Symptom: Der Bot läuft ohne Fehler, es liegt aber nur ein offener Pull Request „Configure Renovate“ vor.

Ursache: Renovate ändert bis zum Merge des Onboarding-PR nichts weiter am Repository. Das ist Absicht.

Prüfung:

git fetch origin && git log origin/main --oneline -- renovate.json

Der Merge-Commit der Onboarding-Datei muss auf dem Default-Branch liegen.

Lösung: Onboarding-PR prüfen und mergen. Anpassungen nehmen Sie vorher im Branch renovate/configure vor. Wer kein Onboarding will, schließt den PR und committet die Konfiguration von Hand.

2. Nach dem Upgrade auf Version 43 startet der Bot nicht mehr

Symptom: Renovate 43 startet nicht, oder Gradle-Wrapper-Updates bleiben aus.

Ursache: Die package.json setzt engines.node auf ^24.11.0, die Release-Notes zu 43.0.0 nennen Node 24 als Mindestanforderung. Zusätzlich ist die Ausführung des Gradle Wrapper per Default abgeschaltet und postUpgradeTasks laufen nicht mehr im Shell-Modus. Die vollständige Liste steht in den Release-Notes zu 43.0.0.

Prüfung:

node --version && npx --yes --package renovate -- renovate --version

Lösung: Node in den Bereich bringen, den ^24.11.0 abdeckt. Gradle-Wrapper-Updates über allowedUnsafeExecutions mit dem Wert gradleWrapper freigeben. Shell-Semantik für postUpgradeTasks bei Bedarf über allowShellExecutorForPostUpgradeCommands=true reaktivieren.

3. Lockfile-Aktualisierung schlägt fehl

Symptom: Renovate wurde per npm installiert, das Anheben der Version klappt, die Lockfile-Aktualisierung bricht ab.

Ursache: Renovate bringt npm, pnpm und yarn nicht mit. Es patcht die Package-Datei und überlässt den Rest dem Paketmanager. Fehlt der, schlägt der Schritt fehl.

Prüfung:

renovate --version && yarn --version && pnpm --version

Lösung: Benötigte Paketmanager global installieren, etwa npm install -g yarn pnpm. Alternativ das -full-Image nutzen, das die meisten unterstützten Paketmanager mitbringt, dafür aber mehrere Gigabyte wiegt.

Die vollständige Fallsammlung

Diese drei Fälle decken den Einstieg ab. Im laufenden Betrieb kommen weitere hinzu: ein ausbleibendes Automerge, Token-Scopes, die im Trockenlauf genügen und im echten Lauf nicht mehr, Manager, die nach enabledManagers stumm ausfallen, oder die Breaking Changes der Versionen 42 und 43. Die vollständige Sammlung der Stolpersteine mit allen neunzehn Fällen steht im Beitrag Renovate im Betrieb: die Stolpersteine im Detail.

Grenzen

Renovate ist ein Vorschlagsmechanismus, kein Testsystem. Der Bot stellt fest, dass eine neuere Version existiert. Ob sie in Ihrer Anwendung funktioniert, beantwortet ausschließlich Ihre CI. Die Dokumentation empfiehlt nachdrücklich, in jedem Projekt mit regelmäßigen Abhängigkeits-Updates Tests zu haben.

Zweitens ist Renovate selbst eine Abhängigkeit, die Pflege braucht. Die Maintainer unterstützen ausschließlich die jeweils neueste Version, ältere bekommen nur in Ausnahmefällen Fixes. Der Stand vom 20. Juli 2026 ist 43.272.6. Eine eingefrorene Renovate-Version ist keine Stabilitätsmaßnahme, sondern ein Wartungsrückstand mit Ansage.

Drittens deckt Renovate nur ab, was ein Manager erkennt. argocd greift ohne explizite Dateimuster gar nicht, und helm-values zieht ausschließlich aus der docker-Datasource, aktualisiert also nur Image-Referenzen und nicht die Chart-Version. Ein Trockenlauf mit --dry-run=extract ist deshalb keine Formalie, sondern die einzige belastbare Antwort darauf, was der Bot in Ihrem Repository sieht. Das Betriebssystem-Patchen löst Renovate ohnehin nicht mit, dazu der Beitrag Patch-Management mit Ansible.

Sie wollen Ihre Abhängigkeiten aktuell halten, ohne dass es zur Daueraufgabe wird? Ich baue automatisierte Update-Strecken, in denen jede Änderung erst getestet und dann übernommen wird. Mehr unter IT-Automatisierung, das Erstgespräch ist unverbindlich.