Die Frage, die kleine Teams zu früh stellen
Vier Entwickler. Eine Rails-App, ein React-Adminbereich, ein gemeinsames Paket mit TypeScript-Typen und ein Slack-Thread, der seit neun Tagen über die Repository-Struktur streitet.
Seit Dienstag ist nichts ausgeliefert worden.
Das Problem ist der Thread. Nicht die Repository-Struktur.
Teams zwischen drei und acht Personen stellen diese Frage ständig, meist nachdem sie irgendwo gelesen haben, wie Google es macht, und seither leise befürchten, alles falsch aufgesetzt zu haben.
Die kurze Antwort: Wenn Sie ein einziges Deployment-Artefakt aus einer Sprache ausliefern, haben Sie bereits ein Monorepo. Auf eine Tooling-Entscheidung wartet niemand.
Die Frage wird später relevant. Dieser Artikel handelt davon, wo dieses Später liegt, was sich dort ändert und welches der vier gängigen Werkzeuge seinen Einrichtungsaufwand rechtfertigt.
Was ein Monorepo tatsächlich ist
Ein Monorepo ist ein versioniertes Repository, das mehrere eigenständige Projekte enthält, die unabhängig gebaut und ausgeliefert werden. Eine Historie, ein Abhängigkeitsgraph, viele Pakete.
Ein Multirepo verteilt dieselben Projekte auf getrennte Repositories. Jedes bekommt eine eigene Historie, eine eigene CI-Konfiguration, einen eigenen Releasezyklus.
Kurz zur Sprache: Im Englischen heißt das Gegenmodell meist Polyrepo, im deutschsprachigen Raum sagt praktisch jedes Team Multirepo. Gemeint ist dasselbe.
Keine der beiden Varianten sagt etwas darüber aus, wie Ihre Software läuft. Ein Monorepo kann zwölf getrennt deployte Services enthalten. Ein Multirepo kann einen Monolithen enthalten, der ohne jeden Grund auf drei Repositories zerschnitten wurde.
Repository-Struktur und Deployment-Architektur sind zwei verschiedene Entscheidungen. Sie zu vermischen ist der Ursprung der meisten schlechten Ratschläge zu diesem Thema.
Und ein Repository mit genau einer Anwendung darin ist kein Monorepo. Das ist ein Repository.
Der Auslöser ist geteilter Code zwischen zwei Deployments
Die Linie ist einfach: Sie brauchen Monorepo-Tooling, sobald zwei oder mehr unabhängig deployte Dinge Code teilen, der sich häufig ändert.
Alles davor erledigen Git und eine package.json. Alles danach verwandelt sich in Versionsversatz-Fehler, und die sind die teure Sorte.
Der Klassiker. Eine Web-App und ein Mobile-Backend teilen sich eine Authentifizierungsbibliothek. Jemand ergänzt ein Claim im Token-Format, veröffentlicht 2.3.0, aktualisiert die Web-App und vergisst das Backend.
Vier Tage später bricht die Produktion. Der verursachende Commit sieht für sich genommen vollkommen harmlos aus.
In einem Monorepo stirbt dieser Fehler vor dem Merge, weil die Änderung und beide Verwender in einem Commit und einem Testlauf liegen. In einem Multirepo fangen Sie ihn mit Contract-Tests, einer Release-Checkliste und Disziplin ab, die freitags um 18 Uhr jemand überspringt.
Das ist das ganze Argument. Alles Weitere ist Tooling.
Wie sieht diese Linie in der Praxis aus? Zwei Deployments und ein geteiltes Paket sind der Moment, sich das Thema anzusehen. Ein Deployment und fünf interne Ordner sind es nicht.
Was Google beweist und was nicht
Googles Monorepo ist die Referenz, nach der alle greifen, und es ist das denkbar schlechteste Modell für ein Team von sechs Leuten.
Die im Fachjournal Communications of the ACM veröffentlichte Momentaufnahme vom Januar 2015 beschrieb rund 2 Milliarden Zeilen Code in 9 Millionen Quelldateien, 86 TB Daten und etwa 40.000 Commits an einem typischen Arbeitstag, davon 24.000 von automatisierten Systemen.
Damit das funktioniert, hat Google eine eigene Versionsverwaltung gebaut, ein eigenes Build-Werkzeug, ein eigenes virtuelles Dateisystem und eine automatisierte Refactoring-Pipeline, die eine API in einem Zug über den gesamten Baum umschreibt.
Sie haben vier Entwickler und einen GitHub-Team-Tarif.
Die Lehre aus Google lautet nicht “nehmt ein Monorepo”. Sie lautet: Ein Monorepo ab einer gewissen Größe braucht ein Build-System, das den Abhängigkeitsgraphen versteht und nur neu baut, was sich geändert hat.
Google hat sich eines geschrieben. Alle anderen kaufen von der Stange. Genau deshalb ist die Werkzeugfrage wichtiger als die Strukturfrage.
Nx, Turborepo, Lerna und Bazel: wofür das jeweils gut ist
| Nx | Turborepo | Lerna | Bazel | |
|---|---|---|---|---|
| Gemacht für | JS/TS-Workspaces, tiefe Framework-Plugins | JS/TS-Taskausführung und Caching | Versionierung und npm-Publishing | Beliebige Sprachen, sehr große Repos |
| Einrichtungsaufwand | Mittel. Generatoren und Plugins nehmen viel ab | Gering. Eine Konfigurationsdatei, fertig | Gering, aufbauend auf Nx | Hoch. Wochen, nicht Tage |
| Caching | Lokal plus remote über Nx Cloud | Lokal plus remote, bei Vercel oder selbst gehostet | Von Nx geerbt | Lokal plus remote, hermetische Builds |
| Aktuelle Linie, Sept. 2026 | 23.x | 2.11.x | 10.x | 9.x, 8.x liefert weiter Releases |
| Passend für ein Team unter 10? | Wenn Sie den vollen Werkzeugkasten wollen | Meistens ja | Nur wenn Sie Pakete auf npm veröffentlichen | Praktisch nie |
Turborepo ist die Standardwahl für JavaScript- und TypeScript-Projekte dieser Größe. Sie schreiben eine turbo.json, die beschreibt, welcher Task von welchem abhängt, und bekommen einen inhaltsadressierten Cache, der bereits erledigte Arbeit überspringt.
Ein Entwickler lernt das an einem Nachmittag.
Nx ist die größere Maschine. Generatoren, Framework-bewusste Plugins, ein expliziter Projektgraph, Modulgrenzen, die den Build brechen, wenn die Admin-App aus den Billing-Internals importiert.
Teams, die Struktur mögen, lieben es. Teams, die in Ruhe gelassen werden wollen, finden es bevormundend. Beide Reaktionen sind richtig, und deshalb hat “Nx oder Turborepo” keine allgemeingültige Antwort.
Die beiden überschneiden sich stärker, als das Marketing vermuten lässt. Beide bauen einen Taskgraphen, beide cachen lokal und remote, und beide überspringen Arbeit, die sich nicht geändert hat. Ein Wechsel zwischen beiden ist ein Konfigurationsproblem, kein Architekturproblem.
Bazel spielt in einer anderen Liga. Es ist der quelloffene Nachfahre von Googles internem Build-Werkzeug und im Umgang mit polyglotten Repositories mit Zehntausenden Targets wirklich exzellent.
Es frisst aber auch einen Monat Ihres Quartals. Im September 2026 ist die 9er-Linie aktuell, während die 8er-Linie weiterhin Releases bekommt, zuletzt im August. Das sagt Ihnen einiges darüber, wie vorsichtig große Bazel-Anwender migrieren.
Wenn niemand im Team Bazel je produktiv betrieben hat, fangen Sie jetzt nicht damit an.
Zu Lerna gehört die ehrliche Version
Lerna steht in den meisten Vergleichsartikeln gleichberechtigt neben Nx und Turborepo, als würden die drei konkurrieren. Das tun sie nicht, und die Vorgeschichte gehört dazu.
Im April 2022 machte ein Pull Request den unmaintained-Status von Lerna prominent in der eigenen README sichtbar. Wenige Wochen später übernahm Nrwl, das Unternehmen hinter Nx, die Verantwortung für das Projekt, statt es sterben zu lassen.
Die npm-Releasehistorie erzählt die Geschichte am klarsten: 4 Releases 2020, genau eines 2021, dann 30 im Jahr 2022 nach der Übernahme. Danach 24 in 2023, 11 in 2024, 8 in 2025 und eine Handvoll bisher in 2026, zuletzt 10.0.1 im August.
Lerna lebt also und wird gepflegt. Es bringt allerdings keinen eigenen Task-Runner mehr mit.
Die eigene Dokumentation von Lerna schreibt es offen: Lerna nutzt Nx, um Pakete und ihre Abhängigkeiten im Workspace zu erkennen, und überlässt Nx das Ausführen von Skripten, das Caching und die Verteilung.
Die echte Wahl lautet damit Nx oder Turborepo. Lerna ist die Versionierungs- und Publishing-Schicht, die Sie obendrauf setzen, wenn Sie Pakete auf npm veröffentlichen. Nehmen Sie es für diese Aufgabe, oder lassen Sie es weg.
Wann das Multirepo weiterhin die richtige Wahl ist
Das Monorepo-Argument ist stark genug, dass es überverkauft wird. Getrennte Repositories gewinnen in mehreren ganz normalen Situationen:
- Harte Eigentumsgrenzen, die Sie wirklich durchsetzen müssen. Verschiedene Teams, verschiedene Rufbereitschaften, verschiedene Freigaberegeln. Eine CODEOWNERS-Datei im Monorepo ist eine Konvention. Ein eigenes Repository ist eine Wand.
- Trennung aus Vertrags- oder Regulierungsgründen. Wenn im Kundenvertrag steht, dass der Code in einem Repository liegt, auf das genau drei namentlich benannte Personen Zugriff haben, ist die Diskussion beendet.
- Wirklich unabhängige Releasezyklen ohne geteilten Code. Eine Marketing-Website und ein Abrechnungsdienst haben einander nichts zu sagen. Sie in ein Repository zu zwingen erzeugt CI-Lärm und bringt nichts.
- Alles, was Sie quelloffen stellen. Ein öffentliches Paket nachträglich aus einem privaten Monorepo herauszulösen ist ein unangenehmer Nachmittag. Fangen Sie getrennt an.
Nichts davon hat mit Größe zu tun. Es geht um Grenzen, und Grenzen sind zuerst eine organisatorische und erst danach eine technische Tatsache.
Die Kosten, die im dritten Monat auftauchen
Davor warnt Sie kein Einrichtungs-Tutorial.
Die CI-Minuten steigen, bevor sie sinken. Eine naiv gebaute Monorepo-Pipeline führt bei jedem Push alle Tests aus, und aus zehn Minuten Build werden vierzig. Genau dagegen verkaufen Nx und Turborepo ihre Affected-Graph-Erkennung, aber Sie müssen sie bewusst konfigurieren.
Der Code-Review wird lauter. Jeder Pull Request berührt ein Repository, das alle beobachten, und die Benachrichtigungsmüdigkeit kommt schnell. Pfadbasierte Reviewer-Zuweisung ist ab etwa acht Personen keine Option mehr, sondern Pflicht.
Git-Operationen werden irgendwann langsam. In Ihrer Größenordnung nicht. Ab einigen hunderttausend Dateien brauchen Sie Partial Clone und Sparse Checkout, und das liegt weit hinter dem Punkt, an dem Sie es gemerkt hätten.
Am härtesten trifft kleine Teams aber etwas anderes: Ein Monorepo macht es lächerlich einfach, Dinge zu koppeln, die getrennt bleiben sollten. Wenn der Import über eine Paketgrenze hinweg eine Zeile kostet, wird es jemand tun, und ein halbes Jahr später teilen sich die “unabhängigen” Services vierzehn interne Module.
Erzwungene Modulgrenzen gibt es aus genau diesem Grund. Dasselbe Muster haben wir aus Datensicht in unserem Artikel zur Multi-Mandanten-SaaS-Architektur für den deutschen Markt beschrieben, wo das günstigste Isolationsmuster genau das ist, das leckt, sobald eine einzige Query ihren Mandantenbezug vergisst.
Was wir konkret tun würden
Vier Fragen, in dieser Reihenfolge:
- Wie viele getrennt deployte Artefakte haben Sie? Eines heißt: Sie sind hier fertig. Zwei oder mehr, weiterlesen.
- Teilen sich diese Artefakte Code, der sich öfter als monatlich ändert? Falls nein, kosten getrennte Repositories Sie nichts. Falls ja, rechnet sich ein Monorepo innerhalb eines Quartals.
- Liegt alles in einem Sprachökosystem? Bei JavaScript und TypeScript nehmen Sie Turborepo, oder Nx, wenn Sie die Struktur wollen. Geteilte Typen zwischen Frontend und Backend sind einfach, solange beide im selben Repository liegen, wie wir in TypeScript überall beschrieben haben. Gemischte Ökosysteme in einem kleinen Team lassen Sie getrennt, bis der Schmerz real ist.
- Hat hier schon einmal jemand Bazel produktiv betrieben? Falls nein, lautet die Antwort nein.
Starten Sie mit Turborepo, wenn Sie auf JS oder TS unterwegs sind. Wechseln Sie zu Nx, sobald Sie Generatoren und erzwungene Modulgrenzen vermissen. Das ist ein echtes und umkehrbares Upgrade, kein Neubau.
Zu Bazel greifen Sie, wenn Sie ein polyglottes Repository haben, das groß genug ist, dass ohnehin ein Build-Engineer auf der Gehaltsliste steht.
Und falls Sie ein Viererteam sind, das noch in diesem Slack-Thread streitet: Nehmen Sie ein Repository, legen Sie beide Projekte hinein, und liefern Sie wieder aus. Ein neun Monate altes Repository strukturieren Sie an einem Wochenende um. Die neun Tage bekommen Sie nicht zurück.
Dieselbe Logik gilt für die meisten Infrastrukturentscheidungen in dieser Größe. Wir haben sie am Deployment durchgespielt, als wir Coolify, Kamal und Cloud Run gegeneinander gestellt haben. Langweilig und umkehrbar schlägt optimal und teuer, jedes Mal.
Streiten Sie über Repository-Strukturen, statt auszuliefern? Sprechen wir darüber. Wir schauen uns an, was Sie tatsächlich deployen und was tatsächlich Code teilt, und sagen Ihnen ehrlich, ob sich das Tooling bei Ihnen schon lohnt.