GitHub oder GitLab: 3.000 gegen 10.000 CI-Minuten sind nicht alles

Für ein kleines privates Projekt mit geringer CI-Last ist GitHub meist der günstigere Einstieg. GitLab Premium lohnt sich eher für Teams, die neben bereitgestellten Runnern auch größere Repositories oder erweiterte Regeln für Reviews und Freigaben benötigen. Die Tarifübersicht von GitHub nennt für Team 3.000 Actions-Minuten pro Monat und 4 US-Dollar pro Nutzer und Monat; GitHub Free enthält 2.000 Minuten. Standard-Runner für öffentliche Repositories sind kostenlos.

Die GitLab-Preisliste nennt für Premium auf GitLab.com 10.000 Compute-Minuten und 29 US-Dollar pro Nutzer und Monat bei jährlicher Abrechnung. Der Tarif erlaubt dort bis zu 500 GiB für Git-Repository und Large File Storage pro Projekt. GitLab Free enthält 400 Compute-Minuten; die Grenze von fünf Nutzern betrifft private Gruppen auf GitLab.com. Mehr eingeschlossene Minuten machen den Premium-Tarif allein noch nicht zur günstigeren Wahl.

Warum Jobdauer und Kontingent nicht dasselbe sind

Für den Preis zählt, auf welchem Runner ein Job läuft. Laut GitHubs Abrechnungsregeln für Actions kostet eine zusätzliche Minute auf einem regulären Linux-Runner mit zwei Kernen 0,006 US-Dollar. Jobs auf eigenen Runnern verbrauchen keine kostenpflichtigen Actions-Minuten. Für private Repositories wird die Nutzung dem Eigentümer des Repositories zugerechnet; ohne gültige Zahlungsmethode stoppt GitHub die Nutzung, sobald das enthaltene Kontingent erschöpft ist.

Bei GitLab hängt der Verbrauch zusätzlich vom Runner-Typ ab. Die Regeln für Compute-Minuten multiplizieren die Laufzeit jedes Jobs mit einem Kostenfaktor: Der kleine Linux-Runner auf GitLab.com hat Faktor eins, der mittlere Faktor zwei. Parallel laufende Jobs werden einzeln gezählt. Für die folgenden hypothetischen Rechnungen gelten ein regulärer Linux-Runner bei GitHub und ein kleiner Linux-Runner bei GitLab; die Beispiele setzen deren Rechenleistung nicht gleich.

Profil eins: kleines privates Projekt

Angenommen, vier Personen starten im Monat 100 Pipelines, deren Jobs zusammen jeweils zwölf Minuten laufen. Das ergibt 1.200 Jobminuten. GitHub Free deckt diese Last mit seinem enthaltenen Kontingent ab. Bei GitLab Free fehlen für Jobs auf bereitgestellten Runnern 800 Compute-Minuten, obwohl die private Gruppe innerhalb der Nutzergrenze bleibt.

Für diesen einen Monat würde bei GitLab ein zugekaufter Block von 1.000 Minuten zum ausgewiesenen Preis von 10 US-Dollar reichen. Das ist deutlich weniger als ein Wechsel aller vier Personen zu Premium: Zum Listenpreis wären dafür rechnerisch 116 US-Dollar pro Monat bei jährlicher Abrechnung fällig. Benötigt das Team stattdessen die Review- und Repository-Regeln von GitHub Team, kosten vier Sitze rechnerisch 16 US-Dollar im Monat. Für einfache private Reviews und die angenommene CI-Last ist GitHub Free die naheliegende Wahl; GitLab Free mit Zusatzminuten bleibt eine mögliche Alternative, wenn das Team dessen Arbeitsabläufe bevorzugt.

Profil zwei: CI-intensive Produktentwicklung

Angenommen, zehn Entwickler erzeugen monatlich 800 Pipelines mit jeweils zehn Minuten addierter Joblaufzeit. Das sind 8.000 Jobminuten. Bei GitHub Team liegen 5.000 Minuten über dem enthaltenen Kontingent. Laufen alle zusätzlichen Jobs auf dem genannten Linux-Runner, kosten sie rechnerisch 30 US-Dollar; die zehn Team-Sitze kosten weitere 40 US-Dollar. Der Vergleichswert beträgt 70 US-Dollar im Monat, bevor etwaige zusätzliche Speicher- oder andere Nutzungskosten hinzukommen.

Bei GitLab Premium passen die 8.000 Jobminuten nur mit Faktor eins vollständig in das enthaltene Kontingent. Zehn Sitze ergeben zum Listenpreis 290 US-Dollar pro Monat bei jährlicher Abrechnung. Auf dem mittleren Linux-Runner würden dieselben Jobs 16.000 Compute-Minuten verbrauchen. Dann fehlten 6.000 Minuten; zum ausgewiesenen Preis der Zusatzpakete entspräche das weiteren 60 US-Dollar. Eine Minute auf den beiden Plattformen ist deshalb weder ein identischer Rechner noch stets eine identische Abrechnungseinheit.

Die Lizenzdifferenz bleibt in diesem Beispiel selbst bei Überschreitung des GitHub-Kontingents groß. Das ist keine Aussage über jede Produktentwicklung: Längere Jobs, andere Betriebssysteme, größere Runner und Anforderungen an Reviews verändern die Rechnung. Das Team muss insbesondere unterscheiden, ob es mehr CI-Laufzeit kaufen möchte oder Funktionen benötigt, die bereits einen höheren Tarif rechtfertigen.

Profil drei: reguliertes Team mit eigener Infrastruktur

Angenommen, 20 Personen erzeugen monatlich 1.200 Pipelines mit je zehn Minuten Joblaufzeit. Das wären 12.000 Jobminuten auf bereitgestellten Runnern. Führt das Team sämtliche Jobs auf eigenen Runnern aus, entfällt die betrachtete Cloud-Runner-Rechnung bei beiden Plattformen. Dafür trägt es die Kosten für Rechnerkapazität, Wartung, Updates und die Trennung von Jobs mit unterschiedlichen Zugriffsrechten selbst.

Ein eigener Runner bedeutet noch nicht, dass auch Repository und Plattform auf eigener Infrastruktur liegen. Soll der Quellcode innerhalb einer selbst betriebenen Plattform bleiben, kommen GitLab Self-Managed und GitHub Enterprise Server als andere Betriebsmodelle in Betracht. GitLab Premium würde für 20 Sitze zum ausgewiesenen Listenpreis rechnerisch 580 US-Dollar pro Monat bei jährlicher Abrechnung kosten, zuzüglich des eigenen Betriebs. Für GitHub Enterprise Server hängen die Gesamtkosten ebenfalls von Lizenz und Infrastruktur ab; aus den Cloud-Kontingenten lässt sich dafür kein belastbarer Preis ableiten.

Bei regulierten Abläufen ist außerdem entscheidend, wo Code, Artefakte und Protokolle liegen und wer Änderungen oder Deployments freigeben darf. Ein selbst betriebener Runner beantwortet diese Fragen nur für die Ausführung der Jobs. Die Wahl zwischen gehosteter und selbst betriebener Repository-Plattform muss daher getrennt von der Wahl des Runners getroffen werden.

Reviews und Speicher verändern den Wert eines Tarifs

GitHub Team bietet unter anderem mehrere Reviewer für Pull Requests, Code Owners und Regeln für geschützte Branches. GitLab Premium führt unter anderem Merge Trains, Push Rules und erweiterte Regeln für Merge Requests auf. Ein Team, das solche Regeln für verbindliche Freigaben nutzt, kauft mit dem Tarif mehr als Runner-Zeit. Für ein Projekt mit einfachen Reviews bringen dieselben Funktionen möglicherweise keinen entsprechenden Nutzen.

Auch die Speicherangaben messen Verschiedenes. Die bei GitHub Team enthaltenen 2 GB bilden ein gemeinsames Kontingent für Actions-Artefakte und GitHub Packages; Cache-Speicher wird getrennt behandelt. Die 500 GiB bei GitLab Premium beziehen sich auf Git-Repositories und Large File Storage pro Projekt auf GitLab.com. Ein großes Repository kann somit für GitLab sprechen, während viele aufbewahrte Build-Artefakte eine andere Kostenfrage aufwerfen. Aus den beiden Zahlen lässt sich kein allgemeiner Speichersieger ableiten.

Für die Entscheidung liefern die Profile unterschiedliche Antworten: Das kleine Projekt kommt bei GitHub ohne Lizenzkosten aus, und die angenommene intensive CI-Last bleibt auf GitHub Team trotz Zusatzminuten günstiger als auf GitLab Premium. Beim Team mit eigener Infrastruktur bestimmen dagegen Betriebsmodell und Freigabeanforderungen den Aufwand. Der passende Tarif ergibt sich aus der tatsächlichen Joblast und den benötigten Funktionen, nicht aus der größeren Minutenzahl allein.

Lesen Sie auch:

• GitHub Copilot oder JetBrains AI: Die IDE entscheidet weniger als das Nutzungslimit
• Dropbox oder Google Drive: Wiederherstellung und Zusammenarbeit schlagen Speicherpreise
• Buffer oder Later: Jeder zusätzliche Kanal verändert den Preis