GitLab vs. GitHub: Was sollte unser kleines Team nutzen?

In der Woche, in der du einen sechsten Entwickler einstellst, überschreitet die private Top-Level-Gruppe mit deinem Code auf GitLab.com Free die Grenze von fünf Nutzern. Laut der Dokumentation von GitLab zum Nutzerlimit im kostenlosen Plan ist die Gruppe dann nur noch lesbar. Bei GitHub Free für Organisationen kommt die neue Person problemlos rein, da Collaborators unlimitiert sind. Du stößt aber auf eine andere Grenze, sobald du zum ersten Mal main absichern willst: Private Repos in GitHub Free können weder geschützte Branches noch Code Owners nutzen.

Als Nächstes würdest du die kostenpflichtigen Pläne vergleichen: GitHub Team, gelistet mit 4 $ pro Nutzer/Monat for the first 12 months, und GitLab Premium mit 29 $ pro Nutzer/Monat bei jährlicher Abrechnung. Es gibt auch eine Option ganz ohne Lizenzgebühr: GitLab Community Edition. CE läuft auf Servern, die du kontrollierst, einer für GitLab und einer für den Runner, der deine CI-Jobs ausführt. Die Tabelle unten gibt ihr deshalb eine eigene Spalte.

So schneiden die Tarife bei einem privaten Repo ab

Jede Zeile unten geht von einem privaten Team-Repo aus. Die Angaben zu den Plänen stammen von der jeweiligen Preisseite oder Dokumentation des Anbieters.

Pläne und Preise laut github.com/pricing und about.gitlab.com/pricing am 28. September 2026; beide waren unverändert, als wir sie am 21. Oktober erneut geprüft haben. Die Seite von GitHub sagt nicht, was Team nach den ersten 12 Monaten kostet. Die Zeile zum Speicher ist kein direkter Vergleich: Das Kontingent von GitHub umfasst Packages und Actions-Artefakte, das von GitLab den Speicher für Git-Repository und LFS in jedem Projekt.

Wenn in deinem Team jemand freigeben soll, bevor ein Deployment die Produktion erreicht, lies die Deploy-Zeile vor der Preiszeile. Bei GitHub Free, Pro und Team funktionieren verpflichtende Reviewer für Deployment-Umgebungen nur in öffentlichen Repos. Wer privaten Code hat, findet diese Hürde also eine Stufe über dem verpflichtenden Merge-Review. GitLab packt beides in Premium, wo geschützte Umgebungen festlegen, wer deployen darf und wer freigeben muss. Ist dein Code öffentlich, schließen sich die meisten dieser Lücken bei GitHub: Geschützte Branches und Deployment-Reviewer funktionieren in öffentlichen Repos ohne kostenpflichtigen Plan.

Was zu deinem Team passt

Unserer Meinung nach ist GitHub am schwersten zu verlassen, wenn deine Pipelines stark auf Actions setzen, denn ein Umzug bedeutet, die übernommenen Marketplace-Workflows an GitLab CI anzupassen.

Was GitLab CE weglässt und was es behält

In CE kann einer deiner Leads einen Merge Request mergen, den niemand geprüft hat, und GitLab hält ihn nicht auf. Freigaben in der kostenlosen Stufe, also dem Funktionsumfang von CE, „sind optional und verhindern kein Mergen ohne Freigabe“. Alles in der Liste What needs Premium unten ist in der Dokumentation von GitLab als Premium gekennzeichnet.

Ob vorher ein Review stattfindet, liegt trotzdem bei deinen Maintainers. Wenn ein Kundenvertrag oder eine Compliance-Prüfung verlangt, dass keine Änderung ohne zweite Freigabe live geht, kann CE das nicht erzwingen, die Freigaberegeln von Premium dagegen schon.

Dafür musst du nicht migrieren. Laut der Umstellungsdokumentation von GitLab installierst du das Paket der Enterprise Edition (EE) über CE und fügst dann eine Lizenz hinzu. Bis dahin bietet EE kostenlos dieselben Free-Funktionen. Die Premium-Funktionen werden aktiv, sobald du eine kostenpflichtige Lizenz aktivierst.

Was der Selbstbetrieb erfordert

Ein CE-Admin im GitLab Forum, der eine Instanz mit etwa 40 registrierten Nutzern betreibt, von denen etwa fünf aktiv sind, erledigt die Routine jeden Montag:

Dein Plan braucht etwas mehr:

• GitLab-Updates nach einem festen Zeitplan einspielen, zu einer ruhigen Uhrzeit. Nach einem Kaltstart dauerte es bei unserer Testinstanz etwa 2 Minuten, bis die Anmeldeseite reagierte
• Backups an einem anderen Ort als dem Server speichern und ab und zu eine Kopie wiederherstellen, um zu prüfen, ob alles funktioniert. Das Backup von GitLab lässt gitlab.rb und gitlab-secrets.json aus, und laut der Backup-Dokumentation musst du beide selbst kopieren
• Auch GitLab Runner auf seinem eigenen Server aktualisieren
• Eine zweite Person benennen, die all das übernehmen kann, wenn die erste nicht da ist

So viel kosten die Plätze für ein Jahr zum Listenpreis, noch bevor du Server einrechnest:

Das sind 29 $ bzw. 4 $ pro Nutzer und Monat, mal 12. Unser Guide zu den Kosten pro Nutzer bei GitLab und GitHub im Vergleich zu einem GitLab-CE-Server rechnet die ganze Rechnung durch, Server inklusive. Beim US-Medianlohn 2025 für Softwareentwickler, QA-Analysten und Tester von 64,44 $ pro Stunde laut Bureau of Labor Statistics kosten 10 Premium-Plätze im Jahr ungefähr so viel wie 54 Stunden Arbeitszeit eines Entwicklers, 10 GitHub-Team-Plätze etwa so viel wie 7 Stunden.

Um diese Stunden für dein eigenes Team gegen die Gebühren pro Platz abzuwägen, nimm die Kosten für ein Jahr Premium-Plätze, zieh die Kosten der beiden Server ab und teile das Ergebnis durch deine eigenen Stundenkosten. So viele Stunden Wartung pro Jahr könntest du investieren, bevor CE teurer wird als Premium. Das wägt nur die Kosten ab, denn CE erzwingt Freigaben nicht so wie Premium. Ist GitHub Team deine andere Option, rechne dasselbe mit dem Platzpreis von 4 $. Bei diesem Preis dauert es deutlich länger, bis die Gebühren pro Platz die Kosten für zwei Server und deren Wartung erreichen.

Beim GitLab VPS von DreamHost betreut DreamHost Hardware, Netzwerk und Konnektivität rund um die Uhr, und laut Produktseite kümmerst du dich selbst um Software-Updates und Konfiguration. Auch die Backups sind deine Sache, wie die Liste oben zeigt.

Wie viel Server GitLab braucht

Die Anforderungsseite von GitLab nennt 8 vCPU und 16 GB Arbeitsspeicher als Basis für eine Installation auf einem einzelnen Knoten. Die GitLab-VPS-Pläne von DreamHost umfassen Stack 16 (4 vCPU, 16 GB) und Stack 32 (8 vCPU, 32 GB). Stack 32 ist der erste Plan, der diese Basis erfüllt. Stack 16 erreicht die 16 GB, hat aber nur die Hälfte der 8 vCPU und liegt damit unter der Basis; die kleineren Pläne liegen noch weiter darunter. Der Leitfaden von GitLab für wenig Arbeitsspeicher geht für bis zu fünf Entwickler deutlich tiefer. Keine der beiden Seiten nennt ein Team von 10 oder 20 Personen.

Diese Werte gelten für GitLab selbst. CI-Jobs gehören woanders hin: Laut der Installationsseite für Runner von GitLab solltest du GitLab Runner auf einer anderen Maschine installieren als der, die deine GitLab-Instanz hostet. Eine Größe für diese Maschine veröffentlicht GitLab nicht. Laut der Seite zu den Runner-Anforderungen hängt sie davon ab, wie viel CPU und Arbeitsspeicher deine Jobs nutzen, wie viele gleichzeitig laufen und wie viele Leute parallel arbeiten. Nach unserer eigenen Schätzung passt Stack 8 mit 2 vCPU und 8 GB, genauso viel wie der Standard-Runner von GitLab.com.

Anforderungsseiten von GitLab gelesen am 28. September 2026, Runner-Seiten am 20. Oktober 2026. Die Angaben zu den Stacks stammen von der GitLab-VPS-Seite von DreamHost.

Die Dokumentation von GitLab sagt nicht, ab wann 4 vCPU für ein Team deiner Größe nicht mehr reichen, und wir haben es auch nicht gemessen. Deshalb lässt der Test unten GitLab auf Stack 16 laufen und beobachtet es, während Pipelines laufen. Wenn sich während des Tests Jobs stauen, prüfe die Concurrency-Einstellung des Runners und die CPU-Auslastung auf beiden Servern, bevor du einem Plan die Schuld gibst. Ein GitLab-Server, dessen CPU bei laufenden Pipelines nahezu voll ausgelastet ist, zeigt dir, dass du die Lücke gefunden hast, und Stack 32 erfüllt beide Basiswerte der Anforderungsseite. Der Speicherplatz wächst mit deinen Repositories, Container-Images und CI-Artefakten. Prüfe also am Ende der Testphase den belegten Speicher und rechne ihn hoch.

Was GitLab CE auf unserer Test-VM verbraucht hat

Die Seiten von GitLab zur Dimensionierung nennen eine Basis für den echten Einsatz und eine Untergrenze für wenig Arbeitsspeicher, aber keinen Messwert dafür, was eine leere Installation tatsächlich verbraucht. Also haben wir das offizielle Image von GitLab CE 19.5.0 auf einer Test-VM mit 2 vCPU und 8 GB laufen lassen, etwa so groß wie der Runner-Server oben, und den Arbeitsspeicher 10 Minuten nach dem Einpendeln abgelesen. Danach haben wir drei Pipelines aus einem kleinen Node.js-Projekt ausgeführt, mit GitLab Runner auf derselben VM.

Bei den CPU-Werten entsprechen 100 % einer vCPU, Job und GitLab brauchten zusammen also mehr als die zwei der VM. Diese Durchläufe hatten keine Nutzer und nur ein kleines Projekt, daher lässt sich daraus keine Teamgröße ableiten. Sie zeigen aber, dass GitLab im Leerlauf etwa 4.285 MiB mit Standardeinstellungen und etwa 2.657 MiB mit den Einstellungen für wenig Arbeitsspeicher braucht, also rund ein Viertel der 16 GB von Stack 16 oder weniger. Damit sind die 4 vCPU der Wert, den du im Blick behalten solltest. Beobachte während der Testphase also die CPU auf beiden Servern, während deine eigenen Pipelines laufen.

So testest du CE einen Sprint lang

Spiegle deinen Code auf den Testserver und lass das Original, wo es ist. Falls der Test nicht klappt, musst du nichts zurückziehen.

1. Ein echtes Repository kopieren

   Wähle ein Repo mit funktionierender Pipeline und seiner echten Historie, damit der Test deine tatsächliche Größe und deine echten Build-Zeiten abbildet. Der GitHub-Importer von GitLab überträgt Repo, Issues und Pull Requests.

2. Die Merge-Regel festlegen

   Schütze main, indem du „Allowed to merge“ auf „Maintainers“ und „Allowed to push and merge“ auf „No one“ setzt. Prüfe dann, ob deine Leads mit Freigaben zurechtkommen, die GitLab nicht erzwingt.

3. Eine normale CI-Woche laufen lassen

   Registriere einen Runner auf einem zweiten Server, einem Stack 8, und führe deine üblichen Pipelines aus. Wenn es GitHub-Actions-Workflows sind, schreib sie zuerst für GitLab CI um und rechne diese Stunden in den Test ein. Notiere, wie lange Jobs warten, während andere die Web-App nutzen.

4. Wiederherstellung und Update testen

   Stelle ein Backup sowie deine Kopien von gitlab.rb und gitlab-secrets.json auf einem freien Wegwerf-Server wieder her und spiele dann ein GitLab-Update ein. Notiere, wie lange beides gedauert hat und was du von Hand korrigieren musstest. Auf unserer Test-VM haben wir kein Update gemessen, deshalb liefert dieser Schritt deinen Wert für den Wartungsaufwand.

Lege vor dem Sprint deine Messlatte fest: wie lange ein Build warten darf und wie viele Stunden Wartung pro Monat du akzeptierst.

Wie wir GitLab CE getestet haben

Die GitLab-Werte auf dieser Seite hat DreamHost am 20. Oktober 2026 auf einer Test-VM (arm64) gemessen, nicht auf einem DreamHost-Server. Es ist derselbe Durchlauf wie in unserem Leitfaden zu den Kosten pro Nutzer bei GitLab und GitHub, der den vollständigen Aufbau und die Leerlaufwerte ausführlicher zeigt. Unsere Pläne nutzen x86-Prozessoren vom Typ AMD EPYC, auf einem echten Server musst du also mit kleinen Abweichungen rechnen. Kurz gesagt: das offizielle Image von CE 19.5.0 auf einer Maschine mit 2 vCPU und 8 GB Arbeitsspeicher (7.922 MiB laut Linux), einmal mit Standardeinstellungen und einmal mit den speicherreduzierten Einstellungen von GitLab. Für die Pipelines lief GitLab Runner auf derselben Maschine und führte die Test- und Build-Jobs des Open-Source-Projekts Express dreimal aus, während wir alle 3 Sekunden Arbeitsspeicher und CPU ausgelesen haben.

Was wir nicht getestet haben: die Last eines echten Teams, ein großes Repository, mehrere Pipelines gleichzeitig, einen Runner auf einem zweiten Server, die 4 vCPU von Stack 16 oder die 8 von Stack 32 und die Ausfallzeit bei einem Update. Jede Einstellung lief einmal. Fakten zu den Plänen und Preise stammen von den Seiten von GitHub und GitLab, jeweils mit dem in den Quellen genannten Datum.

FAQ zu GitLab oder GitHub