Zo host je GitLab CE zelf op een VPS

Het is vrijdagmiddag, de pull request van je team wacht op review en je laptop geeft een bekende melding: GitHub heeft weer problemen.

Misschien hangen de Actions.

Misschien geeft git push voor de derde keer deze maand een 500-fout.

De thread in je teamchat telt al acht berichten.

De eerste keer lach je erom. De tweede keer deelt iemand een link naar de statuspagina van GitHub en gaan jullie allemaal koffie halen. De derde keer, meestal vlak voor een release, stelt iemand eindelijk hardop de vraag: Moeten we niet gewoon onze eigen server draaien?

Voor de meeste teams is het eerlijke antwoord nee. GitLab.com Free is ruim voldoende voor kleine teams, en het beheren van je eigen versiebeheerserver kost wel degelijk tijd en moeite.

Het is een afweging die je alleen maakt als je er een echte reden voor hebt.

Heeft je team zo'n reden? Denk aan een klantcontract dat SaaS van derden verbiedt, een compliancegrens of een rekening voor licenties per gebruiker die belachelijk hoog begint te worden. Dan is GitLab CE zelf hosten de netste stap die je kunt zetten. Het is open source, draait op één VPS en kost na het afstellen ongeveer een uur onderhoud per maand.

Bij DreamHost hebben we talloze zelfbeheerde servers gehost en we zien steeds hetzelfde patroon. Ontwikkelaars die succes hebben met zelfgehoste GitLab kiezen meteen het juiste pakket en regelen de voorbereiding voor Secure Shell Protocol (SSH) en Domain Name System (DNS) goed. Daarna weerstaan ze de neiging om te blijven sleutelen zodra alles stabiel draait.

Waarom zou je GitLab zelf hosten in plaats van GitLab.com te gebruiken?

Je host GitLab zelf als GitLab.com of GitHub.com niet voldoet aan je eisen op het gebied van privacy, compliance of kostenbeheersing. Voor de meeste andere teams is de gehoste optie een betere keuze.

Drie redenen houden stand bij nader onderzoek:

1. Privacy en datasoevereiniteit: Je broncode staat op infrastructuur die je zelf beheert en bijwerkt volgens je eigen planning. Geen toegang voor derden, geen gedeeld platform en bij een datalek geen schade buiten je eigen server.
2. Compliance: Gereguleerde sectoren zoals de zorg, de financiële sector en de overheid moeten vaak kunnen bepalen waar hun data staat. Zelfgehoste GitLab CE is de eenvoudigste manier om code binnen een gecontroleerde omgeving te houden.
3. Kostenbeheersing op schaal: GitLab.com rekent per actieve gebruiker. Volgens de prijspagina van GitLab kost Premium $29 per gebruiker per maand. Voor de prijs van Ultimate moet je een offerte aanvragen. Een team van 50 personen op Premium kost $17.400 per jaar, nog zonder add-ons. Een zelfbeheerde VPS plus een uur onderhoud per maand is vaak goedkoper.

Ben je een team van twee personen zonder privacy- of compliance-redenen? Dan is de gratis versie van GitLab de juiste keuze. (Ja, we weten dat dat raar klinkt uit de mond van een hostingbedrijf).

Met zelf hosten ruil je een maandelijkse SaaS-rekening in voor doorlopende beheertijd. Dat is alleen de moeite waard als je een goede reden hebt om over te stappen.

Hier zie je wanneer deze optie zinvol is en wanneer niet:

GitLab Community Edition is gratis onder een opensourcelicentie in MIT-stijl. Er is geen gebruikerslimiet, de basisfuncties zitten niet achter een betaalmuur en je krijgt geen verkooppraatjes te zien. Het hele platform is van jou.

Wat zijn de hardwarevereisten voor GitLab CE?

GitLab CE heeft duidelijke hardwaredrempels. Schat je die goed in, dan krijg je een vlotte installatie. Zo niet, dan blijft je server ploeteren in het swapgeheugen (schijfruimte die je besturingssysteem gebruikt als het RAM vol is).

Volgens de officiële installatievereisten van GitLab wordt de benodigde capaciteit uitgedrukt in verzoeken per seconde in plaats van vaste niveaus per gebruiker. De gepubliceerde basis is 8 vCPU en 16 GB RAM voor maximaal 1.000 gebruikers (ongeveer 20 verzoeken per seconde). Kleinere teams kunnen met minder toe. Om te testen is het gedocumenteerde minimum 2 GB RAM plus 1 GB swap, al gaan de prestaties onder de 4 GB flink achteruit.

Een verse GitLab-installatie verbruikt in rust ongeveer 4-6 GB. Zodra er CI/CD-jobs draaien, schiet het geheugengebruik snel omhoog. Plan dus ruimte in, of reken op traagheid.

Voor opslag hanteert GitLab officieel 40 GB plus de grootte van je repository's, maar in de praktijk is 50 GB een veiliger uitgangspunt. Repository's groeien en build-artefacten stapelen zich op. NVMe, een snellere vorm van SSD-opslag, maakt een merkbaar verschil bij Git-bewerkingen en het lezen van de CI-cache.

Zo verhouden die drempels zich tot de VPS-hostingpakketten van DreamHost:

Het juiste pakket voor de meeste teams met echte CI/CD-pipelines is Stack 32, de enige Stack die voldoet aan de basis van GitLab van 8 vCPU. Stack 16 heeft het geheugen, maar de helft van de cores, dus zie dat als testformaat. Dat klinkt overdreven, totdat je de eerste build ziet starten en Sidekiq, Postgres en een runner allemaal tegelijk pieken*.*

Met 16 GB RAM heb je genoeg ruimte voor de services van GitLab (ongeveer 4 tot 6 GB in rust bij een standaardinstallatie). Daarnaast kunnen een paar CI-workers (elk 1-2 GB) tegelijk op volle toeren draaien, zonder dat iemand in de teamchat er iets van merkt.

Hoe bereid je je VPS voor op de installatie van GitLab?

Besteed 10 minuten aan de voorbereiding: dat betaalt zich terug zodra je voor het eerst herstart. Volg gewoon deze stappen:

1. Richt de VPS in: Kies Ubuntu 24.04 LTS. Die versie wordt ondersteund door de officiële Omnibus-pakketten van GitLab (het alles-in-één-installatieprogramma dat GitLab meelevert) en krijgt nog jarenlang gratis beveiligingsupdates.
   
2. Koppel een domein aan het IP-adres van de server: Maak een A-record aan (het type DNS-record dat een domein aan een IP-adres koppelt) en geef het minstens 15-30 minuten om te verspreiden voordat je installeert. Zonder dat record mislukt de automatische SSL-configuratie, omdat de certificeringsinstantie nergens kan valideren.
   
3. Werk de pakketten bij: Maak verbinding met de VPS via ssh root@your-server-ip en voer sudo apt update && sudo apt upgrade -y uit.
   
4. Installeer de afhankelijkheden: Voer sudo apt install -y curl openssh-server ca-certificates perl postfix uit. Het pakket postfix is een mailserver die uitgaande e-mail afhandelt, zodat GitLab meldingen over merge requests en wachtwoordresets kan versturen.
   Vraagt het installatieprogramma naar de mailconfiguratie, kies dan Internet Site en gebruik je domein. Zo kan GitLab meteen mail versturen.
   Voor productie: sla de lokale postfix over en stel in plaats daarvan een SMTP-relay in via gitlab.rb. IP-adressen van VPS'en staan vaak op spamblokkeerlijsten, en e-mails voor wachtwoordresets die via een lokale postfix lopen, belanden vaak in de spam. SendGrid, Mailgun en vergelijkbare SMTP-relays werken allemaal. Zie de documentatie over SMTP-configuratie van GitLab.
   
5. Open de juiste poorten: Stel een firewall in met UFW (de ingebouwde firewalltool van Ubuntu) en sta de poorten 80, 443 en 22 toe.

sudo ufw allow http
sudo ufw allow https
sudo ufw allow ssh
sudo ufw enable

Hoe installeer je GitLab CE op Ubuntu met het Omnibus-pakket?

Voeg de GitLab CE-repository toe:

curl -sSL https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | sudo bash

Installeer daarna GitLab CE met je domein als externe URL:

sudo EXTERNAL_URL="https://gitlab.example.com" apt install gitlab-ce

Door hier https:// in te stellen, vraagt GitLab tijdens de installatie automatisch een certificaat van Let’s Encrypt aan. Daarvoor moeten de poorten 80 en 443 open staan en moet DNS correct zijn ingesteld. Is een van die twee nog niet klaar, dan wordt de installatie wel voltooid, maar mislukt SSL. Dan ben je het volgende halfuur bezig met iets oplossen dat eigenlijk niet kapot is.

Wacht vervolgens op de herconfiguratiestap.

GitLab voert aan het einde van de installatie automatisch gitlab-ctl reconfigure uit (de opdracht die alle wijzigingen in de configuratie van GitLab toepast). Dat duurt vijf tot 10 minuten. En ja, de herconfiguratiestap duurt echt zo lang.

Haal het initiële root-wachtwoord op:

sudo cat /etc/gitlab/initial_root_password

Dit bestand wordt automatisch aangemaakt en na 24 uur verwijderd, dus kopieer het wachtwoord en log in. Ga in een browser naar je domein, log in als root en wijzig het wachtwoord meteen.

Controleer tot slot de installatie.

Maak vanaf het welkomstscherm van GitLab een testproject aan. Push er een commit naartoe vanaf je lokale computer. Lukt de push en verschijnt het bestand in de webinterface, dan is de installatie in orde.

Blijft de herconfiguratiestap hangen, kijk dan in tail -f /var/log/gitlab/reconfigure/*.log. Daar staat de echte foutmelding.

Hoe beveilig je een zelfgehoste GitLab-instantie?

GitLab wordt geleverd met redelijke standaardinstellingen, maar die zijn afgestemd op een open communityserver, niet op de privéomgeving van je team. Trek hier een uur voor uit.

1. Schakel open registratie uit. Open registratie staat standaard aan. Ga in de Admin Area naar Settings > General > Sign-up restrictions en vink Sign-up enabled uit. Anders kan iedereen met de URL een account aanmaken.
2. Schakel tweestapsverificatie in. Ga naar Admin Area > Settings > General > Sign-in restrictions en maak 2FA verplicht voor alle gebruikers. Verlaag de respijtperiode van de standaard 48 uur naar 8 uur.
3. Beperk het aanmaken van projecten. Stel Default Project Creation in op Maintainers of No one, afhankelijk van hoe strikt je het wilt.
4. Controleer de verlenging van SSL. GitLab verlengt certificaten van Let’s Encrypt standaard automatisch. Voer ter controle één keer sudo gitlab-ctl renew-le-certs uit en bekijk de uitvoer.
5. Beveilig SSH op de VPS zelf. Schakel inloggen als root met een wachtwoord uit, sta alleen authenticatie met SSH-sleutels toe en verplaats SSH (als het lukt) naar een andere poort dan 22. Een zelfgehoste Git-server is maar zo veilig als de machine eronder.

Wil je meer diepgang, dan heeft GitLab een Hardening Guide gepubliceerd over authenticatie, versleuteling en instance-instellingen. Lees die één keer door, pas toe wat bij je dreigingsmodel past en ga verder.

Hoe maak je een back-up van een zelfgehoste GitLab-instantie en hoe zet je die terug?

GitLab heeft een ingebouwde back-uptool. De eerste keer dat je hem nodig hebt, ben je blij dat je hem hebt ingesteld.

Maak een back-up:

sudo gitlab-backup create

Dit zet een tarball in /var/opt/gitlab/backups. Plan dit dagelijks in via cron met een bewaartermijn van zeven dagen. Voer sudo crontab -e uit en voeg deze twee regels toe:

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
0 3 * * * find /var/opt/gitlab/backups -name "*.tar" -mtime +7 -delete

De vlag CRON=1 onderdrukt de voortgangsuitvoer, zodat je cron-logs niet vollopen.

Tip: de databack-up bevat /etc/gitlab/gitlab-secrets.json en /etc/gitlab/gitlab.rb niet.

Die bestanden bevatten de versleutelingssleutel van de database, de seeds voor tweestapsverificatie en CI/CD-variabelen. De configuratiegeheimen maken geen deel uit van de gewone back-up en moet je apart opslaan. Herstel je data zonder het bestand met geheimen, dan werken accounts met tweestapsverificatie niet meer en worden versleutelde variabelen onleesbare rommel. En dan ben je een lange avond bezig om uit te zoeken waarom.

Voeg dit toe aan dezelfde cronjob:

sudo cp /etc/gitlab/gitlab-secrets.json /etc/gitlab/gitlab.rb /var/opt/gitlab/backups/

Een back-up kun je alleen herstellen op dezelfde versie en editie van GitLab (CE naar CE, niet CE naar EE) als waarop hij is gemaakt.

Wees voorzichtig met upgraden: herstel geen oude back-up op een vers geïnstalleerde GitLab zonder de installatie eerst naar de bijbehorende versie te downgraden.

Test het herstelproces minstens één keer. Een back-up die je nooit hebt getest, is gewoon een bestand.

Is GitLab zelf hosten echt de moeite waard voor je team?

Voor de meeste teams is GitLab zelf hosten een beslissing over controle. Soms valt de kostenberekening gunstig uit, maar de reden dat mensen bij zelf hosten blijven, is zelden die ene post op de begroting.

Dit is de eerlijke maandelijkse tijdsinvestering voor een installatie van een klein team:

• ~30 minuten bijwerken – apt-upgrades, kleine releases van GitLab
• ~15 minuten back-ups controleren – vertrouw geen back-up die je niet hebt hersteld
• ~15 minuten capaciteit controleren – schijfgebruik, vrije RAM
• ~2x als CI/CD op dezelfde machine draait – Een drukke runner kan de belasting verdubbelen

Dat is ongeveer een uur per maand in een rustige week, of twee in een drukke.

Bij ongeveer $150 per uur kost 12 uur beheertijd zo'n $1.800. Dat is ongeveer evenveel als vijf Premium-licenties op GitLab.com.

Een praktijkcase van Mad Devs laat zien hoe hun team meer dan $10.000 per jaar bespaart door zelfgehoste GitLab CE te gebruiken in plaats van te betalen voor Premium-licenties. Die besparing is er pas als het team zo groot is dat licenties per gebruiker het grootste deel van het budget opslokken.

Toch is zelf hosten de verkeerde keuze voor:

• Teams van twee tot drie personen zonder compliance-eisen. Met GitLab.com Free zit je goed. De tijd die het beheer kost, is meer dan wat je bespaart.
• Teams waarin niemand zich thuis voelt op de opdrachtregel. Thuis voelen betekent niet dat je op sysadmin-niveau moet zitten. Het betekent dat je foutmeldingen van /var/log/gitlab kunt lezen zonder in paniek te raken.
• Teams waarvoor werving het grootste knelpunt is, niet tooling. Zelf hosten haalt aandacht weg van je product. Is de ontwikkelsnelheid van je product de beperking, dan is een gehoste oplossing de juiste keuze.

Wanneer is zelf hosten dan wel zinvol? Hier zijn een paar scenario's:

• Gereguleerde sectoren met expliciete eisen voor dataresidentie of chain of custody
• Teams in de EU of het VK met zorgen over soevereiniteit bij code die in de VS wordt gehost
• Teams van 30+ personen waarbij licenties per gebruiker het grootste deel van het budget opslokken
• Klantcontracten die SaaS van derden voor broncode verbieden

Is je reden GitHub rekent per gebruiker af, dan kom je er waarschijnlijk voordeliger uit. Is je reden ik wil zelf de touwtjes in handen hebben, dan valt de dagelijkse praktijk van het beheer misschien minder romantisch uit dan je verwacht.

Moet je GitLab CI/CD-runners op dezelfde VPS draaien?

Om te testen: ja. Voor productie: nee.

Een CI-runner op dezelfde machine snoept geheugen en CPU af van de GitLab-interface. Het klassieke symptoom: GitLab voelt om 9 uur 's ochtends traag, en dat is meestal terug te voeren op een build die de eerste pipeline van de ochtend start en de webfrontend uithongert. Netter is een aparte VPS voor de runner (één Stack 8 per runner), die via het netwerk bij de GitLab-instantie is geregistreerd.

Moet je runners toch op dezelfde machine draaien, kies dan Stack 32 en laat ruimte over voor de jobs.

Volgens de systeemvereisten voor runners van GitLab is het runnerproces zelf licht. De workloads die het uitvoert zijn dat niet, en die delen de CPU en schijf van de machine met al het andere wat GitLab doet.

Klaar om over te stappen?

Terug naar de teamchat op vrijdagmiddag.

Kleurt GitHub geel en lacht je team er weer om voordat iedereen koffie gaat halen? Prima.

Maar wat als een storing bij GitHub serieus begint te voelen?

Brengt het misschien een klantcontract in gevaar? Komt het ter sprake bij een compliance-audit? Of is de rekening voor licenties per gebruiker eindelijk over de grens gegaan?

Dan wordt GitLab CE zelf hosten een heel redelijke optie. Je hebt alleen een VPS, een domein, een Omnibus-installatie en een uurtje beveiligen nodig.

De volgende keer dat de statuspagina van GitHub oplicht, kun je gewoon doorpushen.

Veelgestelde vragen over GitLab zelf hosten