Opensource DevOps op schaal: GitLab in eigen beheer draaien
Broncode is het ene bezit dat vrijwel elk technologiebedrijf kritiek noemt, en tegelijk het bezit dat de meeste bedrijven bewaren op infrastructuur die ze niet bezitten, in een jurisdictie die ze niet kozen, onder een contract dat ze niet zorgvuldig lazen. Meestal gaat dat prima. Toch is het nuttig te weten wat het alternatief kost, want GitLab maakt het al meer dan tien jaar echt haalbaar om de hele ontwikkelcyclus zelf te hosten.
Het is ook een product waarvan het gratis niveau ruimhartiger is en de beheerlast zwaarder dan de meeste mensen verwachten. Allebei wil je begrijpen voordat je je vastlegt. Deze gids behandelt dus wat GitLab in eigen beheer werkelijk is, wat het gratis niveau echt geeft, en de drie operationele problemen die het grootste deel van de pijn veroorzaken.
Wat GitLab is
Geen Git-hosting met extra's eraan geschroefd. Een Rails-applicatie, PostgreSQL, Redis, Gitaly voor repository-opslag, Sidekiq voor achtergrondtaken en een container registry, samen verpakt als één systeem voor versiebeheer, code review, issuebeheer, CI/CD, pakket- en containerregistries, security scanning en deployment.
Die breedte is het hele argument. GitHub plus Actions plus Dependabot plus een pakketregistry plus een projecttracker levert een vergelijkbaar functiepakket, samengesteld uit onderdelen. GitLab is één applicatie met één rechtenmodel en één database. Dat is óf precies wat je wilt, óf meer dan je nodig hebt, en welke van de twee hangt af van hoeveel van de cyclus je werkelijk op één plek wilt draaien.
Het architectonisch belangrijke feit is hetzelfde als bij je analytics in eigen beheer met Matomo, je marketingautomatisering met Mautic of je teamchat met Mattermost: het draait waar jij het neerzet. Jouw repositories, jouw CI-logs, jouw artefacten, jouw database.
Het licentieplaatje, ronduit gezegd
Dit is werkelijk verwarrend en verdient precisie, want de verwarring loopt precies andersom dan mensen verwachten.
Er zijn twee brondistributies. Community Edition valt onder de MIT-licentie. Enterprise Edition heeft een eigen, beperkendere licentie die geldt voor de map ee/ van de repository. Tot zover klinkt het als het gebruikelijke open core-model.
Wat mensen verrast: het Linux-pakket dat vrijwel iedereen installeert is de Enterprise Edition-build, en zonder licentiesleutel draait die als Free-niveau en gedraagt zich als Community Edition. Je draait dus niet de MIT-gelicentieerde distributie, tenzij je bewust voor het CE-pakket hebt gekozen. In de praktijk maakt dat zelden uit, maar als je reden om zelf te hosten een strikt opensourcebeleid is en niet datacontrole, dan maakt het enorm veel uit, en bijna niemand controleert het.
De commerciële niveaus zijn Free, Premium voor 29 dollar per gebruiker per maand bij jaarlijkse facturering, en Ultimate op aanvraag. Premium voegt geavanceerde CI/CD, beter projectbeheer en prioriteitsondersteuning toe. Ultimate voegt het security- en compliancepakket toe: applicatiebeveiligingstests, supply chain-beveiliging, dependency scanning. Beide betaalde niveaus bevatten inmiddels GitLab Credits voor de AI-functies, 12 dollar per gebruiker per maand op Premium en 24 op Ultimate.
En hier is het feit dat voor de meeste teams de rekensom verandert, precies het omgekeerde van de Mattermost-situatie: het Free-niveau in eigen beheer kent geen gebruikerslimiet. Het plafond van vijf gebruikers waar mensen over hebben gehoord geldt alleen voor privégroepen op GitLab.com. Zelf gehost geeft Free je onbeperkte gebruikers, versiebeheer, CI/CD en registries, en opslag en runners breng je zelf mee. Een organisatie van honderd engineers kan er volledig op draaien.
Wat je inlevert is security scanning, compliancerapportage, geavanceerde goedkeuringsregels en support. Val je onder de Cyber Resilience Act en wil je dependency scanning en SBOM-generatie ingebouwd in je pipelines in plaats van samengesteld uit losse tools, dan is dat een Ultimate-gesprek. Voor de meeste andere teams is Free geen proefperiode. Het is een houdbaar permanent antwoord.
De installatie
Een kleine opzet
GitLab is zwaarder dan het lijkt. De gedocumenteerde basis voor één node is 8 vCPU en 16 GB RAM, en anders dan de meeste leveranciersminima is dat getal eerlijk in plaats van optimistisch. Het kan in 8 GB geperst worden, maar je merkt het, en swap zet je beter uit, want deze applicatie laten swappen is erger dan het geheugen niet hebben.
PostgreSQL is de enige ondersteunde database. Welke versie hangt af van je GitLab-versie: 17.x wil PostgreSQL 14.14 tot 16.x, 18.x wil 16.5 tot 17.x, en 19.x wil 17.x. Redis 7.2 wordt aanbevolen, 7.0 is het minimum, en Valkey 7.2 werkt als vervanger. Alleen losstaande instanties, want geclusterde en serverless varianten van Redis worden niet ondersteund.
Installeer met het Linux-pakket. Er zijn Helm-charts, een Operator, Docker-images en een route vanaf de broncode, maar het Linux-pakket is de meest volwassen optie en is waar GitLab.com zelf op draait. Het brengt PostgreSQL, Redis en Sidekiq mee, dus één machine en één configuratiebestand leveren een werkende instantie.
# /etc/gitlab/gitlab.rb
external_url 'https://git.example.com'
# Let's Encrypt, on by default when external_url is https
letsencrypt['enable'] = true
letsencrypt['contact_emails'] = ['ops@example.com']
# Keep Puma and Sidekiq honest on a small box
puma['worker_processes'] = 2
sidekiq['max_concurrency'] = 9
# Move artefacts and uploads off local disk early
gitlab_rails['object_store']['enabled'] = true
gitlab_rails['object_store']['connection'] = {
'provider' => 'AWS',
'region' => 'eu-central-1',
'aws_access_key_id' => 'REPLACE_ME',
'aws_secret_access_key' => 'REPLACE_ME'
}
Eén gitlab-ctl reconfigure later heb je een instantie. Zet external_url meteen goed, want die waarde belandt vastgebakken in clone-URL's, webhooks en registry-adressen.
Een productieopzet
GitLab publiceert referentiearchitecturen van 1.000 tot 50.000 gebruikers, en die zijn het lezen waard ook als je er nooit een implementeert, omdat ze laten zien welk onderdeel als eerste het knelpunt wordt.
Het advies dat het meeste geld bespaart komt van GitLab zelf en pleit tegen complexiteit: onder de 3.000 gebruikers raden ze een degelijke back-upstrategie aan boven hoge beschikbaarheid. De documentatie is er ongewoon eerlijk over en merkt op dat een back-upaanpak weliswaar een tragere hersteltijd heeft, maar een veel kleinere architectuur en lagere onderhoudskosten betekent. Boven de 3.000 gebruikers, of waar een storing het bedrijf echt stillegt, wordt hoge beschikbaarheid de aanbeveling.
Neem dat serieus. Eén goed geback-upte node met een geteste restore is in de praktijk betrouwbaarder dan een half begrepen HA-cluster, en een stuk goedkoper.
Verplaats artefacten, uploads, LFS-objecten en registry-images vanaf het begin naar objectopslag. Dezelfde redenering als overal: het houdt de node stateless, de back-ups hanteerbaar en de migratie mogelijk.
De drie dingen die misgaan
Alles hierboven staat in de documentatie. Dit zijn de dingen die incidenten opleveren.
Je back-up bevat niet wat hem ontsleutelt
Dit is de belangrijkste alinea van dit artikel.
gitlab-backup create legt veel vast: de database, repositories, LFS-objecten, CI-artefacten en joblogs, registry-images, wiki's, uploads, Pages-inhoud, Terraform-state, snippets. Wat het niet vastlegt is de configuratiemap, en met name /etc/gitlab/gitlab-secrets.json.
Dat bestand bevat de encryptiesleutel van de database. De documentatie is onomwonden over het gevolg: raak je het kwijt, dan kan de GitLab-applicatie geen enkele versleutelde waarde in de database meer ontsleutelen. Dat betekent CI/CD-variabelen, tokens, tweefactorgeheimen en integratiegegevens. Je hebt dan een back-up die terugzet in een instantie die haar eigen geheimen niet kan lezen.
Ook uitgesloten: /etc/gitlab/gitlab.rb, TLS-sleutels en certificaten, SSH-hostsleutels, en de inhoud van objectopslag zodra objectopslag is ingesteld. Dat laatste treft juist wie architectonisch het juiste deed en vervolgens aannam dat de back-up het dekte.
Back-up /etc/gitlab dus apart, bewaar het ergens anders dan naast het archief, want het is de sleutel tot het archief, en zet daarna het geheel terug op een wegwerpmachine en controleer of je kunt inloggen en een CI-variabele kunt lezen. Een ongeteste back-up is geen back-up, en bij GitLab is een ongeteste restore meestal een kapotte.
Je kunt niet in één sprong upgraden
GitLab kent verplichte tussenstops bij het upgraden, en dat is geen advies. Je kunt ze niet overslaan. Sinds 17.5 zijn de stops voorspelbaar en liggen ze op x.2, x.5, x.8 en x.11, dus van 18.0 naar 19.2 gaan betekent langs 18.2, 18.5, 18.8, 18.11 en 19.0.
Elke stop brengt achtergrondmigraties mee die volledig afgerond moeten zijn voordat je doorgaat. De volgende upgrade starten terwijl migraties nog lopen is hoe instanties in toestanden belanden die alleen support ontwart. Op een grote instantie kunnen die migraties uren duren.
Twee praktische gevolgen. Upgrade regelmatig, want een jaar uitgestelde upgrades is een weekend opeenvolgende upgrades. En neem altijd de laatste patchrelease van een doel-minorversie in plaats van de eerste, wat de documentatie expliciet zegt. GitLab onderhoudt een tool die het upgradepad voor je uitrekent, en die gebruik je beter dan er zelf over te redeneren.
De echte kosten zitten in de runners
De GitLab-server draait je CI niet. GitLab Runner is een apart onderdeel dat je installeert, configureert en betaalt, op infrastructuur die jij levert. Free in eigen beheer bevat helemaal geen rekenminuten, want er is geen inbegrepen rekenkracht om te geven: je brengt je eigen machines mee.
Meestal is dat een goede deal, want een eigen runner is per minuut goedkoper dan gehoste CI zodra het volume serieus wordt, en je kunt elke build de hardware geven die hij nodig heeft. Maar het is echt infrastructuurwerk. Je neemt besluiten over executors, of dat shell, Docker of Kubernetes is; over autoscaling, zodat runners niet om drie uur 's nachts stilstaan te draaien; en over caching, wat het verschil is tussen een pipeline van vier en een van veertien minuten.
Begroot de runnervloot als aparte post. Teams die de kosten van zelf hosten modelleren door alleen naar de GitLab-node te kijken, zitten er ruim naast en ontdekken het gat daarna als een rij wachtende jobs.
Weg bij GitHub
De GitHub-importer is goed, aanzienlijk beter dan de meeste migratietools van leveranciers, en brengt repositorygegevens, branches, LFS-objecten, issues en pull requests met hun opmerkingen, reviews en discussiereacties, wikipagina's, releases en bijlagen, labels, mijlpalen, branch protection-regels en medewerkers met rolmapping mee.
De gedocumenteerde gaten wil je inplannen. Organisaties en groepen komen niet mee, dus de groepsstructuur ontwerp je zelf in plaats van hem te erven, wat meestal een verbetering is. GitHub Actions-workflows converteren niet naar GitLab CI. Pull request-opmerkingen van vóór 2017 komen als aparte threads binnen door beperkingen van de GitHub-API, en repositories met meer dan ruwweg 30.000 opmerkingen vragen om de alternatieve importmethode voor opmerkingen.
Omdat GitHub # gebruikt voor zowel issues als pull requests en GitLab die twee onderscheidt, zullen sommige kruisverwijzingen niet oplossen. Er gaat niets verloren, maar links in oude discussies kunnen naar het verkeerde wijzen.
Plan het herschrijven van de CI als het eigenlijke project, want dat is het. Al het andere is een importklus die je draait en controleert.
De Europese invalshoek
Voor bedrijven die in Europa opereren komt er bij de kosten een compliancedimensie. Broncode, buildpipelines en artefacten horen bij het gevoeligste dat een technologiebedrijf heeft, en waar ze leven is steeds vaker een vraag die je gesteld wordt in plaats van een die je kiest te beantwoorden.
Zelf hosten brengt ze binnen een grens die jij beheerst, wat in één beweging de doorgifteanalyse onder de AVG en de toeleveringsketenvragen van NIS2 vereenvoudigt, en het is hetzelfde soevereiniteitsargument waar de Cloud and AI Development Act omheen is gebouwd.
Het scherpste verband is de Cyber Resilience Act. Breng je software op de EU-markt, dan heb je afhankelijkheidsinventarissen, kwetsbaarhedenbeheer en een gecoördineerd openbaarmakingsproces nodig. Die verplichtingen voldoe je in je buildpipeline en niet in een document, en de pipeline, de registry en het scannen in één systeem hebben dat je zelf beheert maakt het produceren van bewijs een stuk minder pijnlijk dan het bij elkaar sprokkelen bij vier leveranciers.
Wanneer je het moet laten
Ben je met minder dan twintig engineers, zonder regeldruk en zonder uitgesproken mening over waar de code leeft, neem dan de SaaS. GitLab.com en GitHub zijn allebei uitstekend, en het beheerwerk kost meer dan het abonnement.
Zit je organisatie diep in het ecosysteem van GitHub, tel dan eerlijk op wat je zou verliezen. Actions, de marketplace en de simpele vertrouwdheid van het platform bij elke kandidaat die je aanneemt zijn echte bezittingen, en het antwoord is niet automatisch dat GitLab wint.
En als niemand de instantie op zich neemt, begin er dan niet aan. GitLab beloont iemand die patcht, de runnervloot in de gaten houdt en de restore test. Zonder die persoon verwordt het tot een ongepatchte bak met je waardevolste bezit erin, en dat is erger dan de SaaS die je wilde verlaten.
Hulp nodig
Wij zetten ontwikkelinfrastructuur in eigen beheer op en draaien die voor bedrijven die in Europa opereren, inclusief de delen waar niemand van houdt: upgradereeksen langs de verplichte tussenstops, runnervloten die goed autoschalen, migraties naar objectopslag en back-upschema's die daadwerkelijk zijn teruggezet.
Wil je een eerlijk bemeten GitLab-installatie, een GitHub-migratie gepland door iemand die het CI-herschrijven eerder deed, of een toets of je huidige back-up een echte storing zou overleven, mail dan naar office@c9group.dev. Meer over ons infrastructuurwerk op de pagina over AWS-kostenoptimalisatie.
Stel je een volledige stack in eigen beheer samen, dan geldt dezelfde redenering voor analytics, marketingautomatisering en teamcommunicatie.
Gepubliceerd: 8 augustus 2026 Categorieën: DevOps, Open Source, Privacy