GitLab vs GitHub: welke moet ons kleine team gebruiken?

In de week dat je een zesde developer aanneemt, gaat de privégroep op topniveau met je code op GitLab.com Free over de vijf gebruikers heen. Volgens de documentatie van GitLab over de gebruikerslimiet van Free wordt de groep dan alleen-lezen. Op GitHub Free voor organisaties komt de nieuwe collega zonder problemen binnen, want het aantal medewerkers is onbeperkt, maar je loopt tegen een andere limiet aan zodra je main wilt afschermen. De privérepo's van GitHub Free kunnen geen beveiligde branches of code owners gebruiken.

De betaalde abonnementen die je daarna vergelijkt, zijn GitHub Team, vermeld voor $4 per gebruiker per maand for the first 12 months, en GitLab Premium, voor $29 per gebruiker per maand bij jaarlijkse betaling. Er is ook een optie zonder licentiekosten: GitLab Community Edition. CE draait op servers die jij beheert, één voor GitLab en één voor de runner die je CI-jobs uitvoert, en krijgt in de tabel hieronder een eigen kolom.

Zo verhouden de abonnementen zich bij een privérepo

Elke rij hieronder gaat uit van een privérepo van een team. De gegevens over de abonnementen komen van de eigen prijspagina of documentatie van elke leverancier.

Abonnementen en prijzen zoals vermeld op github.com/pricing en about.gitlab.com/pricing op 28 september 2026, en ongewijzigd toen we beide op 21 oktober opnieuw bekeken. De pagina van GitHub vermeldt niet wat Team kost na de eerste 12 maanden. De opslagrij is geen appels-met-appels-vergelijking. De opslagruimte van GitHub geldt voor packages en Actions-artefacten, die van GitLab voor Git-repository- en LFS-opslag per project.

Wil je team dat iemand akkoord geeft voordat een deploy productie bereikt, lees dan de deployrij vóór de prijsrij. Op GitHub Free, Pro en Team werken verplichte reviewers voor deployomgevingen alleen op openbare repo's, waardoor die controle voor iedereen met privécode een niveau hoger ligt dan een verplichte mergereview. GitLab zet beide in Premium, waar beveiligde omgevingen bepalen wie mag deployen en wie moet goedkeuren. Is je code openbaar, dan vallen de meeste van deze verschillen op GitHub weg: beveiligde branches en deployreviewers werken allebei op openbare repo's zonder betaald abonnement.

Welke past bij jullie team

Wij vinden dat GitHub het lastigst te verlaten is als je pipelines sterk op Actions leunen, want overstappen betekent dat je de Marketplace-workflows die je gebruikt moet ombouwen naar GitLab CI.

Wat GitLab CE weglaat en wat het behoudt

In CE kan een van je leads een merge request mergen dat niemand heeft gereviewd, en GitLab houdt dat niet tegen. Goedkeuringen in de gratis versie, de functieset waarop CE draait, „zijn optioneel en voorkomen niet dat er zonder goedkeuring wordt gemerged”. Alles in de lijst What needs Premium hieronder heeft in de documentatie van GitLab het label Premium.

Of er eerst een review plaatsvindt, blijft aan je Maintainers. Staat er in een klantcontract of een compliancecontrole dat geen enkele wijziging live mag zonder tweede goedkeuring, dan kan CE dat niet afdwingen, en de goedkeuringsregels van Premium wel.

Je hoeft niet te migreren om ze te krijgen. Volgens de conversiedocumentatie van GitLab installeer je het Enterprise Edition-pakket (EE) over CE heen en voeg je daarna een licentie toe. Tot je dat doet, draait EE dezelfde Free-functies zonder kosten. De functies van Premium worden actief zodra je een betaalde licentie activeert.

Wat zelf beheren vraagt

Eén CE-beheerder op het GitLab Forum, met een instance van zo'n 40 geregistreerde gebruikers waarvan er ongeveer vijf actief zijn, doet elke maandag deze vaste routine:

Je plan vraagt iets meer:

• GitLab-updates uitvoeren volgens een vast schema, op een rustig moment. Na een koude start duurde het bij onze testinstance ongeveer 2 minuten voordat de aanmeldpagina reageerde
• Back-ups maken naar een andere plek dan de server, en af en toe een kopie terugzetten om te bewijzen dat het werkt. De back-up van GitLab slaat gitlab.rb en gitlab-secrets.json over, en volgens de back-updocumentatie moet je die twee zelf kopiëren
• Ook GitLab Runner op zijn eigen server bijwerken
• Een tweede persoon aanwijzen die alles kan overnemen als de eerste afwezig is

Dit kost een jaar aan gebruikerslicenties tegen catalogusprijs, nog vóórdat je iets voor servers rekent:

Dat is $29 en $4 per gebruiker per maand, maal 12. Onze gids over de kosten per gebruiker van GitLab en GitHub naast één GitLab CE-server berekent de volledige rekening, inclusief servers. Bij het mediane Amerikaanse uurloon in 2025 voor softwaredevelopers, QA-analisten en testers van $64,44, volgens het Bureau of Labor Statistics, kosten 10 Premium-licenties per jaar ongeveer evenveel als 54 uur werk van een developer, en 10 GitHub Team-licenties ongeveer 7 uur.

Om die uren voor je eigen team af te wegen tegen de licentiekosten, neem je een jaar aan Premium-licenties, trek je de kosten van de twee servers eraf en deel je door je eigen uurkosten. Zoveel uur onderhoud per jaar kun je besteden voordat CE duurder wordt dan Premium. Dit weegt alleen de kosten af, want CE dwingt goedkeuringen niet af zoals Premium dat doet. Is GitHub Team je andere optie, maak dan dezelfde berekening met de licentieprijs van $4. Bij die prijs duurt het veel langer voordat de licentiekosten oplopen tot de kosten van twee servers en hun onderhoud.

Op de GitLab VPS van DreamHost ondersteunt DreamHost de hardware, het netwerk en de connectiviteit 24/7, en volgens de productpagina regel je software-updates en configuratie zelf. Back-ups zijn ook jouw taak, zoals in de lijst hierboven staat.

Hoeveel server GitLab nodig heeft

De pagina met vereisten van GitLab noemt 8 vCPU en 16 GB geheugen als basis voor een installatie op één node. De GitLab VPS-abonnementen van DreamHost omvatten Stack 16 (4 vCPU, 16 GB) en Stack 32 (8 vCPU, 32 GB). Stack 32 is het eerste abonnement dat aan die basis voldoet. Stack 16 haalt de 16 GB, maar heeft de helft van de 8 vCPU, dus het zit onder de basis, en de kleinere abonnementen zitten er nog verder onder. De gids van GitLab voor beperkt geheugen gaat veel lager, voor maximaal vijf developers. Geen van beide pagina's noemt een team van 10 of 20.

Die getallen gelden voor GitLab zelf. CI-jobs horen ergens anders: volgens de installatiepagina voor de runner van GitLab installeer je GitLab Runner op een andere machine dan de machine waarop je GitLab-instance draait. GitLab publiceert geen formaat voor die machine. De pagina met vereisten voor de runner zegt dat het afhangt van hoeveel CPU en geheugen je jobs gebruiken, hoeveel er tegelijk draaien en hoeveel mensen parallel werken. Wij schatten zelf in dat Stack 8 volstaat, met 2 vCPU en 8 GB, gelijk aan de standaard gehoste runner van GitLab.com.

Pagina's met vereisten van GitLab geraadpleegd op 28 september 2026, runnerpagina's op 20 oktober 2026. Specificaties van de Stacks komen van de GitLab VPS-pagina van DreamHost.

De documentatie van GitLab zegt niet waar 4 vCPU tekortschiet voor een team van jouw omvang, en wij hebben dat ook niet gemeten. Daarom draait de test hieronder GitLab op Stack 16 en houdt die in de gaten terwijl pipelines draaien. Komen jobs tijdens de test in de wachtrij, controleer dan de concurrency-instelling van de runner en het CPU-gebruik op beide servers voordat je het abonnement de schuld geeft. Zit de CPU van een GitLab-server bijna vol terwijl pipelines draaien, dan heb je het tekort gevonden, en Stack 32 voldoet aan beide basiswaarden van de pagina met vereisten. Schijfruimte groeit mee met je repositories, containerimages en CI-artefacten, dus controleer de gebruikte ruimte aan het eind van de proefperiode en reken die door naar de toekomst.

Wat GitLab CE gebruikte op onze test-VM

De pagina's van GitLab over het formaat geven een basis voor echt gebruik en een ondergrens voor weinig geheugen, maar geen meting van wat een lege installatie werkelijk gebruikt. Daarom hebben we het officiële image van GitLab CE 19.5.0 gedraaid op een test-VM met 2 vCPU en 8 GB, ongeveer het formaat van de runnerserver hierboven, en het geheugen afgelezen 10 minuten nadat het tot rust was gekomen. Daarna draaiden we drie pipelines van een klein Node.js-project, met GitLab Runner op dezelfde VM.

In de CPU-cijfers staat 100% voor één vCPU, dus de job en GitLab hadden samen meer nodig dan de twee van de VM. Deze runs hadden geen gebruikers en één klein project, dus ze zeggen niets over teamgrootte. Ze laten wel zien dat GitLab in rust ongeveer 4.285 MiB geheugen gebruikt met de standaardinstellingen en ongeveer 2.657 MiB met de instellingen voor weinig geheugen, ongeveer een kwart van de 16 GB van Stack 16 of minder. Daardoor blijft de 4 vCPU het cijfer om in de gaten te houden. Let tijdens de proefperiode dus op de CPU van beide servers terwijl je eigen pipelines draaien.

Zo probeer je CE één sprint lang uit

Spiegel je code naar de testserver en laat het origineel staan waar het is. Valt de test tegen, dan hoef je niets terug te verhuizen.

1. Kopieer één echte repository

   Kies een repo met een werkende pipeline en de echte geschiedenis, zodat de test je werkelijke omvang en buildtijden meeneemt. De GitHub-importer van GitLab zet de repo, issues en pull requests over.

2. Stel de mergeregel in

   Bescherm main met Allowed to merge ingesteld op Maintainers en Allowed to push and merge op No one. Kijk daarna of je leads goed kunnen werken met goedkeuringen die GitLab niet afdwingt.

3. Draai een normale week CI

   Registreer een runner op een tweede server, een Stack 8, en draai je gebruikelijke pipelines. Zijn het GitHub Actions-workflows, herschrijf ze dan eerst voor GitLab CI en tel die uren mee in de test. Noteer hoe lang jobs wachten terwijl mensen de webapp gebruiken.

4. Test een herstel en een update

   Zet een back-up, plus je kopieën van gitlab.rb en gitlab-secrets.json, terug op een losse wegwerpserver en voer daarna een GitLab-update uit. Noteer hoe lang elke stap duurde en wat je met de hand moest oplossen. We hebben op onze test-VM geen update getimed, dus uit deze stap komt je cijfer voor het onderhoud.

Leg voordat de sprint begint vast wanneer de test geslaagd is: hoe lang een build mag wachten en hoeveel uur onderhoud per maand je accepteert.

Hoe we GitLab CE hebben getest

De GitLab-cijfers op deze pagina zijn op 20 oktober 2026 door DreamHost gemeten op een test-VM (arm64), niet op een DreamHost-server. Het is dezelfde meting als die achter onze gids over de kosten per gebruiker van GitLab en GitHub, waarin je de volledige opstelling en de metingen in rust uitgebreider vindt. Onze abonnementen gebruiken x86-processors van het type AMD EPYC, dus reken op kleine verschillen op een echte server. Kort samengevat: de officiële CE 19.5.0-image op een machine met 2 vCPU en 8 GB geheugen (7.922 MiB volgens Linux), één keer met de standaardinstellingen en één keer met de instellingen voor beperkt geheugen van GitLab. Voor de pipelines draaide GitLab Runner op dezelfde machine en voerde die de test- en buildjobs van het opensourceproject Express drie keer uit, terwijl we elke 3 seconden het geheugen- en CPU-gebruik uitlazen.

Wat we niet hebben getest: de belasting van een echt team, een grote repository, meerdere pipelines tegelijk, een runner op een tweede server, de 4 vCPU van Stack 16 of de 8 van Stack 32, en de downtime tijdens een update. Elke instelling draaide één keer. Abonnementsgegevens en prijzen komen van de eigen pagina's van GitHub en GitLab, op de data die bij de bronnen staan.

Veelgestelde vragen over GitLab of GitHub