Hoe Je GitLab CE Zelf Host op een VPS

Het is vrijdagmiddag, de pull-aanvraag van je team staat in beoordeling, en je laptop geeft een bekende melding: GitHub heeft weer problemen.

Mogelijk zijn acties vastgelopen.

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

De thread in je teamchat heeft al acht berichten.

De eerste keer dat dit gebeurt, lach je erom. De tweede keer linkt iemand naar de GitHub-statuspagina, en jullie gaan allemaal koffie halen. De derde keer, meestal vlak voor een releaseperiode, typt eindelijk iemand de vraag hardop: “Moeten we het zelf gaan doen?”

Voor de meeste teams is het eerlijke antwoord nee. GitLab.com Free dekt kleine teams comfortabel, en de operationele belasting van het draaien van je eigen versiebeheerserver is niet nul.

Het is het soort ruil dat je alleen maakt om een echte reden.

Als jouw team een van die redenen heeft, zoals een klantcontract dat het gebruik van externe SaaS verbiedt, een compliancegrens, of een licentierekening voor zitplaatsen die belachelijk begint te worden, is zelfhosting van GitLab CE de beste stap die je kunt nemen. Het is open source, draait op een enkele VPS en, eenmaal afgesteld, kost het onderhoud ongeveer een uur per maand.

Bij DreamHost hebben we talloze zelfbeheerde servers gehost, en we zien een patroon: ontwikkelaars die succes hebben met zelfgehoste GitLab kiezen vanaf het begin de juiste plan, regelen de Secure Shell Protocol (SSH) en Domain Name System (DNS) voorbereiding goed, en weerstaan vervolgens de drang om te blijven knutselen zodra het stabiel is.

Waarom Zou Je GitLab Zelf Hosten In Plaats Van GitLab.com Te Gebruiken?

Je host GitLab zelf wanneer GitLab.com of GitHub.com niet voldoen aan je privacy-, nalevings- of kostenbeheersingsbehoeften. Voor de meeste andere teams is de gehoste optie een betere keuze.

Drie echte redenen houden stand bij nadere beschouwing:

1. Privacy en gegevenssoevereiniteit: Jouw broncode bevindt zich op infrastructuur die jij beheert en waarop je zelf updates uitvoert. Geen toegang van derden, geen gedeeld platform, geen schadeomvang van een inbreuk buiten je eigen server.
2. Naleving: Gereguleerde industrieën zoals gezondheidszorg, financiën en overheid hebben vaak controle over gegevensresidentie nodig. Zelf-gehost GitLab CE is de eenvoudigste manier om code binnen een gecontroleerde grens te houden. 
3. Kostenbeheersing op schaal: GitLab.com rekent per actieve gebruiker. Volgens de prijspagina van GitLab kost Premium $29 per gebruiker per maand, terwijl Ultimate-prijzen alleen op aanvraag beschikbaar zijn. Een team van 50 personen op Premium kost $17,400 per jaar voor add-ons. Een zelfbeheerde VPS plus een uur maandelijks onderhoud kost vaak minder.

Als je een team van twee personen bent zonder privacy- of nalevingsredenen, is het juiste antwoord de gratis versie van GitLab. (Ja, we weten dat dit grappig klinkt omdat het van een hostingbedrijf komt).

Met zelfhosting ruil je een maandelijkse SaaS-rekening in voor doorlopende operationele tijd. Dat is alleen een waardevolle ruil als je een goede reden hebt om de overstap te maken.

Hier is waar deze optie zinvol is en waar niet:

Scenario	Beste Keuze
Privacy of naleving vereist	Self-hosted GitLab CE
Team groter dan ~30 actieve gebruikers	Self-hosted is vaak goedkoper
Code is jouw IE, en je wilt het lokaal hebben	Self-hosted GitLab CE
2-5 persoonsteam, geen nalevingsbehoeften	GitLab.com (gratis)
Je wilt geen server patchen	GitLab.com

GitLab Community Edition is gratis onder een MIT-stijl open-source licentie. Er is geen gebruikerslimiet, geen basisfuncties achter een betaalmuur, en geen upsell-aanwijzingen. Het hele platform is van jou om te gebruiken.

Wat Zijn de Hardwarevereisten voor GitLab CE?

GitLab CE heeft duidelijke hardwaregrenzen, en deze goed instellen maakt het verschil tussen een snelle installatie en een die worstelt met swapgeheugen (schijfruimte die je besturingssysteem gebruikt wanneer het RAM vol raakt).

Volgens de officiële installatievereisten van GitLab wordt de grootte uitgedrukt in aanvragen per seconde in plaats van vaste gebruikerstiers. De gepubliceerde basislijn is 8 vCPU en 16 GB aan RAM voor maximaal 1.000 gebruikers (ongeveer 20 aanvragen per seconde). Kleinere teams kunnen met minder werken, tot een gedocumenteerd minimum van 2 GB aan RAM en 1 GB aan swap voor evaluatie, hoewel de prestaties onder de 4 GB lijden.

Een verse GitLab-installatie verbruikt ongeveer 4-6 GB in rust. Zodra CI/CD-taken gaan draaien, schiet het geheugengebruik snel omhoog. Dus plan wat ruimte in — of reken op traagheid.

Wat opslag betreft, is de officiële basislijn van GitLab 40 GB plus de grootte van de repository, maar 50 GB is in de praktijk een veiliger startpunt. Repositories groeien en build-artefacten stapelen zich op. NVMe, een sneller type solid-state opslag, maakt een merkbaar verschil in Git-operaties en CI-cache lezingen.

Hier is hoe die drempels overeenkomen met de VPS hosting niveaus van DreamHost:

Gebruikssituatie	Aanbevolen RAM	DreamHost VPS Tier
Evaluatie / persoonlijk	4 GB RAM	Stack 4
Klein team, licht gebruik	8 GB RAM	Stack 8
Tot ~1.000 gebruikers (gepubliceerde basislijn van GitLab)	16 GB RAM	Stack 16
CI/CD runners draaien op dezelfde server	+ 2-8 GB RAM bovenop je tier	Groter kiezen (bijv. Stack 16 → Stack 32)

Het juiste startpunt voor de meeste teams die echte CI/CD pipelines uitvoeren is Stack 16. Dat klinkt als te veel totdat je de eerste build ziet starten en Sidekiq, Postgres en een runner tegelijkertijd pieken.

16 GB aan RAM geeft je genoeg ruimte voor de stapel diensten van GitLab (ongeveer 4 tot 6 GB in rust bij een standaardinstallatie) en een paar CI-medewerkers (1-2 GB elk) om tegelijkertijd actief te zijn zonder dat iemand in het teamoverleg het merkt.

Hoe Bereid Je Jouw VPS Voor Voordat Je GitLab Installeert?

Besteed 10 minuten aan de voorbereiding — het loont de eerste keer dat je opnieuw opstart. Volg gewoon deze stappen:

1. Configureer De VPS: Kies Ubuntu 22.04 LTS of 24.04 LTS. Beide worden ondersteund door GitLab’s officiële Omnibus pakketten (de gebundelde alles-in-één installer die GitLab levert) en hebben nog jaren gratis beveiligingsupdates voor de boeg.
   
2. Wijs Een Domein Aan Het IP Van De Server Toe: Maak een A-record aan (het type DNS-record dat een domein aan een IP-adres koppelt) en laat het minstens 15-30 minuten propageren voordat je installeert. Zonder dit zal de automatische SSL-configuratie falen omdat de certificaatautoriteit nergens kan valideren.
   
3. Update Pakketten: Verbind met de VPS via `ssh root@je-server-ip` en voer `sudo apt update && sudo apt upgrade -y` uit.
   
4. Installeer Afhankelijkheden: Voer `sudo apt install -y curl openssh-server ca-certificates perl postfix` uit. Het `postfix` pakket is een mailserver die uitgaande e-mails afhandelt zodat GitLab merge-verzoek notificaties en wachtwoord resets kan versturen.
   Wanneer de installer vraagt over mailconfiguratie, kies Internetsite en gebruik je domein. Dit zorgt ervoor dat GitLab direct mail verstuurt.
   Voor productie: sla lokale postfix over en configureer een SMTP relay in gitlab.rb in plaats daarvan. VPS IP’s zijn vaak op spam blocklists, en wachtwoord-reset e-mails via lokale postfix komen vaak in spam terecht. SendGrid, Mailgun, en DreamHost’s uitgaande relay werken allemaal — zie GitLab’s SMTP configuratie documentatie.
   
5. Open De Juiste Poorten: Configureer een firewall met UFW (Ubuntu’s ingebouwde firewall tool) en sta 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 vervolgens GitLab CE met je domein ingesteld als de externe URL:

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

Het instellen van `https://` hier zegt GitLab automatisch een Let’s Encrypt-certificaat aan te vragen tijdens de installatie, zolang poorten 80 en 443 open zijn en DNS correct is gericht. Als een van die niet gereed is, wordt de installatie voltooid maar mislukt SSL — en besteed je de volgende dertig minuten aan het oplossen van problemen met iets dat eigenlijk niet kapot is.

Wacht vervolgens op de herconfigureer stap.

GitLab voert `gitlab-ctl reconfigure` (het commando dat wijzigingen in de configuratie van GitLab toepast) automatisch uit aan het einde van de installatie. Het duurt vijf tot 10 minuten. En ja, de reconfigureer stap duurt echt zo lang.

Verkrijg het initiële root-wachtwoord:

sudo cat /etc/gitlab/initial_root_password

Dit bestand wordt automatisch gegenereerd en wordt binnen 24 uur verwijderd, dus pak het wachtwoord en log in. Bezoek je domein in een browser, log in als `root`, en verander het wachtwoord onmiddellijk.

Verifieer ten slotte de installatie.

Vanaf het welkomstscherm van GitLab, maak een testproject. Push een commit naar het project vanaf je lokale machine. Als de push slaagt en het bestand verschijnt in de web UI, is de installatie gezond.

Als de stap voor het opnieuw configureren blijft hangen, controleer dan `tail -f /var/log/gitlab/reconfigure/*.log`. Daar staat de eigenlijke fout.

Hoe Beveilig Je Een Zelf-gehoste GitLab Instantie?

GitLab wordt geleverd met redelijke standaardinstellingen, maar deze zijn afgestemd op een openbare communityserver, niet op jouw privéteaminstance. Besteed hier een uur aan.

1. Schakel Open Registratie Uit. Open registratie staat standaard aan. In het Beheergebied, navigeer naar Instellingen > Algemeen > Registratiebeperkingen en zet het vinkje bij “Registratie ingeschakeld” uit. Anders kan iedereen met de URL een account aanmaken.
2. Schakel Tweefactorauthenticatie In. Ga naar Beheergebied > Instellingen > Algemeen > Inlogbeperkingen en dwing 2FA af voor alle gebruikers. Verlaag de genadeperiode van de standaard 48 uur naar 8 uur.
3. Beperk Projectcreatie. Stel Standaard Projectcreatie in op Behouders of Niemand, afhankelijk van hoe gesloten je het wilt hebben.
4. Controleer SSL-vernieuwing. GitLab vernieuwt Let’s Encrypt certificaten standaard automatisch. Om te bevestigen, voer `sudo gitlab-ctl renew-le-certs` eenmaal uit en controleer de uitvoer.
5. Beveilig SSH op de VPS zelf. Schakel inloggen met root wachtwoord uit, sta alleen SSH-sleutelauthenticatie toe en (als het mogelijk is) verplaats SSH van poort 22. Een zelf-gehoste Git-server is alleen zo veilig als de server eronder.

Voor een uitgebreide versie heeft GitLab een Verhardingsgids gepubliceerd die authenticatie, encryptie en instellingen voor instances behandelt. Lees het eens, pas toe wat past bij jouw dreigingsmodel en ga verder.

Hoe Maak Je Een Back-up Van En Herstel Je Een Zelfgehoste GitLab-Instantie?

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

Maak een back-up:

sudo gitlab-backup create

Dit plaatst een tarball in `/var/opt/gitlab/backups`. Plan dit dagelijks via een Cron Job 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 voortgangsuitvoer zodat het de cron-logboeken niet spamt.

Pro tip: de data back-up bevat niet `/etc/gitlab/gitlab-secrets.json` of `/etc/gitlab/gitlab.rb`.

Die bestanden bevatten de database encryptiesleutel, tweefactorzaden en CI/CD variabelen. De configuratiegeheimen maken geen deel uit van de reguliere back-up en moeten apart worden opgeslagen. Herstel data zonder het geheimenbestand en tweefactoraccounts gaan stuk, versleutelde variabelen veranderen in onzin, en je brengt een lange avond door met uitzoeken waarom.

Voeg dit toe aan dezelfde Cron Job:

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

Een back-up kan alleen worden hersteld naar dezelfde versie en editie (CE-naar-CE, niet CE-naar-EE) van GitLab waarop het is gemaakt.

Upgrade zorgvuldig: herstel geen oude back-up op een pas geïnstalleerd GitLab zonder eerst de installatie aan te passen.

Test het herstelproces ten minste één keer. Een back-up die je nooit hebt getest is slechts een bestand.

Is Self-Hosting GitLab Eigenlijk De Moeite Waard Voor Je Team?

Zelf-hosting van GitLab is een controlebeslissing voor de meeste teams. De kostenberekening klopt soms, maar de reden waarom mensen bij zelf-hosting blijven, is zelden het kostenoverzicht.

Hier zijn de eerlijke maandelijkse tijdskosten voor een installatie van een klein team:

• ~30 minuten van patchen – apt upgrades, GitLab kleine releases
• ~15 minuten van back-upverificatie – vertrouw geen back-up die je niet hebt hersteld
• ~15 minuten van capaciteitscontrole – schijfgebruik, RAM vrije ruimte
• ~2x als CI/CD draait op de server – Een drukke runner kan de belasting verdubbelen

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

Voor ongeveer $150 per uur kost 12 uur operationele tijd ongeveer $1,800 — ruwweg vijf GitLab.com Premium zitplaatsen.

Een praktijkvoorbeeld van Mad Devs beschrijft hoe hun team meer dan $10.000 per jaar bespaart door zelf-gehoste GitLab CE te gebruiken in plaats van te betalen voor Premium zitplaatsen. De besparingen worden pas zichtbaar wanneer het team groot genoeg is dat licenties voor zitplaatsen de begroting domineren.

Met dat gezegd, zelf-hosting is de verkeerde keuze voor:

• Teams van twee tot drie personen zonder nalevingsredenen. GitLab.com Free dekt je. De operationele tijd is meer dan de bespaarde kosten.
• Teams zonder iemand die comfortabel is met de commandoregel. “Comfortabel” betekent niet van het niveau systeembeheerder. Het betekent dat je fouten in `/var/log/gitlab` kunt lezen zonder in paniek te raken.
• Teams wiens grootste belemmering het aannemen van personeel is, niet het gereedschap. Zelf hosten leidt de aandacht af van het product. Als de productiesnelheid de beperking is, is gehost de juiste keuze.

Dus, wanneer is zelf-hosting zinvol? Hier zijn een paar scenario’s:

• Gereguleerde industrieën met expliciete eisen voor dataresidentie of ketenbeheer
• EU/UK teams met soevereiniteitszorgen over in de VS gehoste code
• Teams van 30+ waar licenties voor stoelen het budget domineren
• Klantencontracten die SaaS van derden voor broncode verbieden

Als je reden is “GitHub rekent per zitplaats,” kom je waarschijnlijk beter uit. Als je reden is “Ik wil controle voelen,” vind je de operationele realiteit misschien minder romantisch dan verwacht.

Moet Je GitLab CI/CD Runners Op Dezelfde VPS Draaien?

Voor evaluatie, ja. Voor productie, nee.

Een CI-runner op dezelfde server neemt geheugen en CPU weg van de GitLab UI. Het klassieke symptoom is “GitLab voelt traag om 9 uur ‘s ochtends,” wat meestal terug te voeren is op een build die de eerste pijplijn van de ochtend start en de web frontend uithongert. De schonere opstelling is een aparte kleine VPS (of een DreamCompute instantie) voor de runner, geregistreerd bij de GitLab-instantie via het netwerk.

Als je lopers op dezelfde box moet houden, verhoog dan de VPS naar 16 GB.

Volgens de systeemvereisten van de GitLab-runner is het runner-proces zelf licht. De workloads die het uitvoert zijn dat niet, en ze delen de CPU en schijf van de box met alles wat GitLab verder doet.

Klaar Om De Overstap Te Maken?

Terug naar de vrijdagmiddag teamchat.

Als GitHub geel wordt en je team er weer om lacht en koffie gaat halen, is dat prima.

Maar wat als het uitvallen van GitHub serieus begint te voelen?

Misschien bedreigt het een klantencontract? Komt het naar voren bij een compliance-audit? Of is de factuur voor de zitplaatslicentie eindelijk de grens overgegaan?

Zelf-hosting van GitLab CE begint een volledig redelijke optie te worden. Het enige wat je nodig hebt is een VPS, een domein, een Omnibus-installatie en een uur hardening.

De volgende keer dat de GitHub statuspagina oplicht, zal je code prima blijven pushen.

Veelgestelde Vragen Over Het Zelf Hosten Van GitLab

Wil je nog iets anders weten over het zelf hosten van GitLab op een VPS? Hieronder vind je de antwoorden op enkele veelgestelde vragen.

Is GitLab CE Gratis Voor Eigen Hosting?

Ja, GitLab CE is gratis voor zelfhosting onder een MIT-stijl open-source licentie. Er is geen gebruikerslimiet en geen prijs per zitplaats. De enige kosten zijn de VPS zelf en de operationele tijd om het te onderhouden.

DreamHost’s VPS Stack 4 is een redelijk startpunt voor evaluatie. Productieteams werken doorgaans op Stack 8 of Stack 16.

Hoeveel RAM Heeft GitLab CE Eigenlijk Nodig?

Plan voor 16 GB aan RAM voor maximaal 1.000 gebruikers, wat de gepubliceerde basislijn van GitLab is (ongeveer 20 verzoeken per seconde). Kleinere teams kunnen met minder toe, tot een gedocumenteerde ondergrens van 2 GB plus 1 GB aan swap voor evaluatie. Hoe dan ook, als je CI/CD-pijpleidingen op dezelfde machine draait, plan dan voor 16 GB.

Kan Ik GitLab Zelf Hosten Op Een 4 GB VPS?

Ja, je kunt GitLab CE draaien op 4 GB, maar het zal traag aanvoelen onder enige echte belasting. GitLab documenteert een 2 GB + 1 GB swap fallback voor geheugenbeperkte omgevingen — die weg is voor evaluatie, niet voor productie. Voor een team dat actief code pusht en pipelines uitvoert, is 8 GB het praktische minimum.

Hoe Lang Duurt Het Om GitLab CE Op Een VPS Te Installeren?

Het duurt ongeveer 10 tot 15 minuten om het pakket te installeren, plus ongeveer een uur voor voorbereiding en beveiliging, dus ongeveer 90 minuten van begin tot eind. De installatie zelf bestaat voornamelijk uit wachten tijdens de herconfiguratiestap.

De beveiligingsfase, waarbij het uitschakelen van open inschrijving, het afdwingen van tweefactorauthenticatie en het vergrendelen van projectcreatie vereist is, neemt het resterende uur in beslag en is verplicht voor elke productie-instance.

Is het zelf hosten van GitLab de moeite waard voor een team van vijf personen?

Waarschijnlijk niet, tenzij je een privacy- of nalevingsreden hebt. GitLab.com Free dekt tot vijf gebruikers met onbeperkte privéprojecten en 400 CI/CD-minuten per maand. De operationele tijd van zelfhosting weegt niet op tegen de bespaarde kosten per stoel bij die teamgrootte.

Zelf-hosting begint zich terug te betalen, in zuivere kostentermen, vanaf 30+ actieve gebruikers.

Wat is het verschil tussen GitLab CE en GitLab Community Edition?

GitLab CE en GitLab Community Edition zijn hetzelfde product. CE is de standaardafkorting. De terminologie “Self-Managed” verwijst naar waar je het uitvoert (je infrastructuur), niet naar welke editie.

GitLab Community Edition is open-source. GitLab Enterprise Edition (EE) voegt betaalde functies toe bovenop dezelfde codebasis.

Waar Verschilt GitLab CE Van GitLab EE?

GitLab CE is de gratis, open-source editie. GitLab EE gebruikt dezelfde codebasis, plus betaalde functies die activeren wanneer je een licentiebestand uploadt.

Het praktische verschil komt neer op het volgende:

• CE heeft een MIT-licentie en is volledig functioneel. Broncontrole, samenvoegen van verzoeken, problemen, basis CI/CD, containerregister, alles.
• EE voegt enterprise-functies toe achter een licentie. Denk aan epics, geavanceerde compliance-frameworks, waardestroomanalyses, meerdere goedkeuringsregels en geavanceerde beveiligingsscanning. Volgens GitLab’s vergelijking van zelfbeheerde functies, is het verschil voornamelijk belangrijk voor organisaties met formele wijzigingsbeheerprocessen.
• Je kunt EE installeren zonder een licentie, en het functioneert als CE tot het gelicentieerd is. Zo anticiperen de meeste teams op een toekomstige behoefte om te upgraden.
• Je kunt EE niet schoon downgraden naar CE. Plan dienovereenkomstig.

Voor de meeste zelf-hostende teams is CE voldoende. Als je reden privacy of kosten zijn, veranderen EE-functies zelden de berekening.

Hoe houd ik mijn zelf-gehoste GitLab-instance bijgewerkt?

Voer `sudo apt update && sudo apt upgrade gitlab-ce` uit om beveiligingspatches toe te passen. Een maandelijkse frequentie is het praktische minimum voor een productie-exemplaar. Maak altijd een back-up voordat je een upgrade uitvoert.

Grote versie-upgrades moeten achtereenvolgens worden uitgevoerd — je kunt geen grote versies overslaan. Overstappen van 16.x naar 18.x vereist eerst een upgrade naar 17.x en dan naar 18.x. Het overslaan van een grote versie zal database-migraties onderbreken. Controleer altijd de GitLab upgrade path tool voordat je upgrade, en maak direct voor elke stap een back-up.

Waar past DreamHost bij zelf-gehost GitLab?

DreamHost’s VPS Hosting biedt de root-toegang Linux-server waar GitLab CE op geïnstalleerd wordt. Het Stack 16 plan (16 GB RAM) voldoet aan de officiële eisen van GitLab voor maximaal 1.000 gebruikers, met ruimte voor actieve CI/CD-pijpleidingen.