Eine Organisation mit vierzig eigenständigen Repositories bekommt jeden Monat Dutzende neuer npm-, pip- oder Docker-Base-Image-Versionen angeboten, und in jedem einzelnen Repository liegt die Entscheidung, ob und wann jemand sie einspielt. Von Hand lässt sich das nicht mehr verlässlich pflegen: Wer prüft, ob React in Repository 23 noch auf Version 17 hängt, während Repository 24 längst auf Version 19 läuft? Ein automatisierter Bot, der jedes Repository regelmäßig nach veralteten Abhängigkeiten durchsucht und selbst einen Pull Request anlegt, verschiebt diese Arbeit von einer manuellen Routine zu einer Regel, die einmal eingerichtet wird und danach für alle Repositories gleich gilt.
Renovate ist genau so ein Bot: ein quelloffenes Projekt, das die Firma Mend entwickelt und pflegt, und das sich von GitHubs eigenem Dependabot vor allem durch die Feinheit seiner Regeln unterscheidet. Wo Dependabot pro Repository eine Konfigurationsdatei mit überschaubaren Optionen erwartet, liest Renovate eine gemeinsame Regel aus einem einzigen zentralen Repository und wendet sie auf jedes andere Repository der Organisation an. Updates lassen sich dabei nach Paket, nach Registry oder nach Versionstyp gruppieren, und wer will, lässt risikoarme Patch-Updates automatisch mergen, sobald die eigene Testkette sie bestätigt.
Systemvoraussetzungen
Bevor Renovate in einer Organisation läuft, müssen wenige Bausteine feststehen: welche Variante von Renovate zum Einsatz kommt, wo die Konfiguration liegt und welche Rechte der Bot auf GitHub braucht. Die folgende Tabelle nennt den Stand vom 26. August 2026.
| Komponente | Version oder Anforderung | Zweck |
|---|---|---|
Renovate CLI (npm-Paket renovate) | Version 44.46.1, veröffentlicht am 26. August 2026, benötigt Node.js ^24.11.0 | Kernprogramm für Scan und Pull-Request-Erstellung, läuft per npx oder als Docker-Container |
| Docker-Image | renovate/renovate (Docker Hub) oder ghcr.io/renovatebot/renovate, Standard- oder -full-Variante | Selbst gehostete Ausführung ohne eigene Node.js-Installation |
| Mend Renovate GitHub App | Community Edition kostenlos, 1 gleichzeitiger Auftrag je Organisation, Prüfung etwa alle 4 Stunden | Gehostete Alternative ohne eigene Infrastruktur, unbegrenzt viele öffentliche und private Repositories |
| Konfigurationsdatei je Repository | renovate.json, renovate.json5 oder .github/renovate.json5 | Legt Erweiterungen (extends), Gruppierungsregeln und Zeitplan fest |
| Geteiltes Preset-Repository | Eigenes Repository mit einer Datei default.json, referenziert über extends: ["github>organisation/renovate-config"] | Bringt dieselbe Regel in jedes Repository der Organisation, ohne Mehrfachpflege |
| Repository-Berechtigung | Schreibzugriff für Branches und Pull Requests, bei Organisations-Repositories zusätzlich die App-Freigabe der Organisation | Voraussetzung, damit Renovate Branches anlegen und pushen kann |
Systemarchitektur
Renovate arbeitet nach einem festen Zyklus, der sich für ein einzelnes Repository und für eine ganze Organisation gleich abspult. Der Bot liegt entweder als gehostete GitHub App von Mend vor, oder er läuft selbst gehostet als Docker-Container oder npm-Paket auf eigener Infrastruktur. In beiden Fällen liest er zuerst die Konfiguration eines Repositories, meist eine Datei namens renovate.json, und löst darin jeden Verweis im Feld extends auf. Ein solcher Verweis kann auf eine geteilte Konfiguration in einem anderen Repository zeigen, ein sogenanntes Preset. Ein Preset ist nichts anderes als eine JSON-Datei mit denselben Optionen, die sonst in der lokalen renovate.json stünden, nur dass viele Repositories dieselbe Datei gemeinsam nutzen.
flowchart TD
A[Renovate laeuft nach Zeitplan oder per Cron] --> B[Liest renovate.json und loest extends auf]
B --> C[Laedt geteiltes Preset aus dem zentralen Repository]
C --> D[Scannt jedes Repository der Organisation]
D --> E[Erkennt veraltete npm- pip- und Docker-Abhaengigkeiten]
E --> F[Gruppiert Updates nach packageRules]
F --> G[Erstellt einen Pull Request je Gruppe]
G --> H[CI-Pipeline testet den Pull Request]
H -->|Tests bestehen und automerge greift| I[Renovate merged den Pull Request selbst]
H -->|Tests schlagen fehl| J[Renovate setzt Assignees und Reviewer]
J --> K[Pull Request bleibt offen]
K --> L[Dependency Dashboard zeigt den offenen Fall]
I --> M[Repository ist aktuell bis zum naechsten Lauf]
Nach dem Scan entscheidet packageRules, das zentrale Regelwerk für Gruppierung und Zeitplan, wie die gefundenen Updates auf Pull Requests verteilt werden. Alle Patch-Updates eines Docker-Basisimages landen so in einem einzigen Pull Request statt in fünf einzelnen. Jeder Pull Request durchläuft anschließend dieselbe Testkette wie jede andere Änderung am Repository, die CI (kurz für Continuous Integration, die automatisierte Ausführung von Tests bei jeder Änderung). Erst wenn diese Tests bestehen, prüft Renovate, ob für genau diese Art von Update automerge eingeschaltet ist. Ist das der Fall, merged Renovate den Pull Request selbst. Scheitert die Testkette, bleibt der Pull Request offen, und Renovate trägt die hinterlegten Assignees oder Reviewer ein, damit ein Mensch den Fall übernimmt.
Schritt-für-Schritt-Umsetzung
Renovate für die Organisation aktivieren
Der schnellste Einstieg ist die Mend Renovate App aus dem GitHub Marketplace. Sie ist für öffentliche und private Repositories in der Community Edition kostenlos, läuft mit einem gleichzeitigen Auftrag je Organisation und prüft jedes Repository etwa alle vier Stunden auf neue Updates. Für ein einzelnes Team oder eine mittlere Organisation reicht das meistens aus, weil ein gebündelter Lauf ohnehin selten öfter als einmal am Tag sinnvoll ist.
Wer mehr Kontrolle braucht, etwa weil viele Repositories gleichzeitig geprüft werden sollen oder weil keine Daten an einen externen Dienst gehen dürfen, hostet Renovate selbst. Das quelloffene Kernprogramm liegt als npm-Paket renovate oder als Docker-Image (renovate/renovate beziehungsweise ghcr.io/renovatebot/renovate) vor und läuft auf jeder eigenen Infrastruktur mit einem Cron-ähnlichen Taktgeber. Damit entfallen die Auftragslimits der gehosteten Variante vollständig. Im Gegenzug übernimmt die Organisation selbst die Wartung: Renovate aktuell halten, die Ausführung überwachen, und, sofern Abhängigkeiten von github.com geladen werden, einen persönlichen Zugriffstoken als RENOVATE_GITHUB_COM_TOKEN hinterlegen, damit die eigene Abfragequote nicht das strengere, unauthentifizierte Limit von GitHub trifft.
Geteilte Preset-Konfiguration anlegen
Eine geteilte Konfiguration braucht ein eigenes Repository, zum Beispiel organisation/renovate-config, mit einer Datei namens default.json im Wurzelverzeichnis. Der Dateiname renovate.json ist für ein Preset-Repository inzwischen veraltet, weil er mit der lokalen Konfigurationsdatei eines gewöhnlichen Repositories verwechselt werden kann.
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["config:recommended", ":dependencyDashboard"],
"packageRules": [
{
"matchDatasources": ["docker"],
"groupName": "Docker-Basisimages",
"schedule": ["* 22-23,0-4 * * *", "* * * * 0,6"]
}
]
}Jedes einzelne Repository verweist danach nur noch auf diese eine Datei, statt eigene Regeln zu pflegen.
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": ["github>organisation/renovate-config"]
}Der Verweis github>organisation/renovate-config lädt automatisch die Datei default.json aus dem Standardzweig dieses Repositories. Ein Doppelpunkt hinter dem Repository-Namen lädt stattdessen eine andere Datei (github>organisation/renovate-config:docker lädt docker.json), und eine Raute mit Versionsnummer pinnt einen bestimmten Git-Tag (github>organisation/renovate-config#2.0.0), damit eine Änderung an der geteilten Konfiguration nicht ungeprüft in jedem Repository gleichzeitig wirkt.
Updates nach Paketgruppen und Zeitplan bündeln
packageRules ist eine Liste von Regeln, die Renovate der Reihe nach auf jede gefundene Abhängigkeit anwendet. Jede Regel braucht mindestens ein Matching-Feld wie matchPackageNames oder matchDatasources, und passende Regeln werden zusammengeführt. Um zum Beispiel alle Pakete aus der eslint-Familie in einem einzigen Pull Request zu bündeln, reicht ein Namensmuster:
{
"packageRules": [
{
"matchPackageNames": ["eslint**"],
"groupName": "eslint-Pakete"
}
]
}Das Muster eslint** trifft jedes Paket, dessen Name mit eslint beginnt, und groupName fasst alle Treffer zu einem gemeinsamen Branch und Pull Request zusammen, statt für jedes Paket einen eigenen anzulegen. Für Docker-Basisimages funktioniert dieselbe Gruppierung über matchDatasources: ["docker"] statt eines Namensmusters, und ein zusätzlicher Zeitplan über schedule legt fest, wann Renovate für diese Gruppe neue Branches anlegen darf.
Patch-Updates automatisch mergen lassen
Ein sicherer Automerge betrifft nur die Update-Art, bei der laut Semantic Versioning keine brechenden Änderungen zu erwarten sind: ein Patch-Update. Die Option matchUpdateTypes grenzt eine Regel auf genau diese Art ein, und matchCurrentVersion: "!/^0/" schließt zusätzlich Pakete mit einer Versionsnummer unter 1.0 aus, weil deren Autoren laut SemVer-Spezifikation auch bei einem Patch jederzeit etwas ändern dürfen.
{
"packageRules": [
{
"matchUpdateTypes": ["patch"],
"matchCurrentVersion": "!/^0/",
"automerge": true
}
]
}automerge: true setzt den Merge nicht sofort um. Renovate wartet auf einen bestandenen Status-Check für den betroffenen Branch, bevor es den Pull Request selbst zusammenführt, und verwendet dafür standardmäßig die native Automerge-Funktion der jeweiligen Plattform. Ein Repository ohne jede Testpipeline liefert diesen Status-Check nie, und Renovate merged dann grundsätzlich nichts, es sei denn, die Konfiguration erlaubt das ausdrücklich über ignoreTests: true.
Häufige Fehlerquellen
- Pflicht-Review blockiert das eigene Automerge. Ist im Branch-Schutz eine Freigabe durch einen Menschen vorgeschrieben, kann Renovate seinen eigenen Pull Request nicht selbst freigeben, und automerge greift nie, obwohl die Konfiguration korrekt ist. Abhilfe schafft die GitHub-Einstellung „Allow specified actors to bypass required pull requests“ für den Renovate-Account, oder eine Hilfs-App wie renovate-approve, die automerge-fähige Pull Requests automatisch freigibt.
- Fehlende Tests verhindern jedes Automerge. Renovate merged erst, wenn es einen bestandenen Status-Check für den Branch sieht. Ein Repository ohne CI-Pipeline liefert diesen Check nie, und die Pull Requests bleiben trotz
automerge: trueliegen. Wer wirklich ohne Tests automergen will, muss das ausdrücklich mitignoreTests: trueerlauben, was ohne echte Testabdeckung riskant bleibt. - Ein beweglicher Verweis auf die geteilte Konfiguration. Referenziert die lokale
renovate.jsondas Preset ohne Versionsangabe, übernimmt jedes Repository jede Änderung am zentralen Preset sofort und ungeprüft. Ein fester Git-Tag hinter der Raute imextends-Verweis verhindert, dass ein Fehler im zentralen Preset alle Repositories gleichzeitig betrifft. - Gruppierte Major-Updates erzeugen eine wiederkehrende Pull Request. Fasst eine Gruppe Pakete mit unterschiedlichen Zielversionen zusammen, kann Renovate den geschlossenen Pull Request nicht mehr sicher ignorieren, weil der Titel keine eindeutige Version mehr trägt, und legt ihn beim nächsten Lauf erneut an. Getrennte Gruppen für Major-Updates oder
"recreateWhen": "never"beheben das. - Rate-Limit-Fehler bei selbst gehosteten Instanzen. Läuft Renovate selbst gehostet gegen eine andere Plattform als github.com, lädt aber trotzdem Abhängigkeiten oder Release Notes von GitHub, greift ohne eigenen Token das strenge, unauthentifizierte Limit von GitHub. Die Umgebungsvariable
RENOVATE_GITHUB_COM_TOKENmit einem Nur-Lese-Token behebt das zuverlässig. - Genehmigungspflicht für alle Updates verstopft das Dashboard. Wer
dependencyDashboardApprovalpauschal für alle Updates aktiviert, muss das Dashboard-Issue regelmäßig selbst prüfen, sonst bleiben Updates unsichtbar liegen. Renovates eigene Dokumentation empfiehlt, die Genehmigungspflicht auf Major-Updates oder einzelne Pakete zu begrenzen, statt sie global zu setzen.
Häufig gestellte Fragen
Ist die gehostete Renovate-App von Mend für private Repositories kostenlos?
Die gehostete Renovate-App von Mend ist in der Community Edition für eine unbegrenzte Zahl öffentlicher und privater Repositories kostenlos. Diese kostenlose Stufe erlaubt einen gleichzeitigen Auftrag je Organisation und prüft jedes Repository ungefähr alle vier Stunden auf neue Updates. Die kostenpflichtige Enterprise Edition hebt dieses Limit auf sechzehn gleichzeitige Aufträge je Organisation an, prüft stündlich und bringt zusätzlichen Support von Mend.
Was passiert, wenn ein Renovate-Pull-Request die CI nicht besteht?
Ein Renovate-Pull-Request, der die CI nicht besteht, wird nicht automatisch gemerged, selbst wenn automerge für diese Art von Update aktiviert ist. Renovate trägt stattdessen die konfigurierten Assignees oder Reviewer ein, damit jemand den Fehler manuell prüft, und lässt den Pull Request offen stehen. Ist das Dependency Dashboard aktiviert, taucht das offene Update dort weiterhin auf, bis es gemerged, geschlossen oder durch eine neue Version ersetzt wird.
Wie bringt eine Organisation dieselbe Renovate-Konfiguration in viele Repositories, ohne jede Datei einzeln zu pflegen?
Dieselbe Renovate-Konfiguration kommt über ein geteiltes Preset in viele Repositories: ein einzelnes Repository mit einer default.json, auf die jedes andere Repository im Feld extends verweist. Ein Verweis wie github>organisation/renovate-config lädt diese Datei automatisch aus dem Standardzweig, und eine Änderung an dieser einen Datei wirkt danach in jedem Repository, das sie referenziert. Wer eine Änderung nicht ungeprüft überall wirksam haben will, pinnt den Verweis stattdessen auf einen festen Git-Tag.
Worin unterscheidet sich Renovate von GitHub Dependabot?
Renovate unterscheidet sich von GitHub Dependabot vor allem in der Feinheit der Gruppierungs- und Zeitplanregeln. Dependabot bündelt Updates über die groups-Einstellung nach Namensmuster, Update-Typ oder Abhängigkeitsart und lässt sich seit 2025 zusätzlich per Cron-Ausdruck takten, bleibt dabei aber auf eine Konfigurationsdatei je Repository beschränkt. Renovate erreicht eine ähnliche Feinsteuerung über packageRules, unterstützt zusätzlich geteilte Presets über viele Repositories hinweg und deckt mit eigenen Managern auch Ökosysteme ab, die Dependabot nicht abdeckt. Wer nur ein einzelnes GitHub-Repository ohne Zusatzkonfiguration pflegt, kommt mit dem eingebauten Dependabot oft schneller ans Ziel.