Git deploy op server: welke methode past bij jouw project

Gebruik een bare repository met SSH en een post-receive hook voor kleine projecten en eigen servers: eenvoudig, direct en volledig onder eigen controle. Ga je richting productie met meerdere ontwikkelaars, dan stap je over op CI/CD met GitHub Actions of GitLab CI en environment secrets voor veilige toegang. Lees verder voor de exacte server-setup, automatisering en zero-downtime aanpak.

Kort samengevat:

• Voor kleine projecten volstaat een bare repository met SSH en een post-receive hook, terwijl grotere teams beter af zijn met CI/CD-oplossingen zoals GitHub Actions of GitLab CI.
• Een bare Git-repository, geïnstalleerd met git init --bare --shared, vormt de basis voor zelfbeheer van een server en vereist correcte SSH- en permissie-instellingen voor veilige toegang.
• Automatisering via hooks en CI/CD zorgt voor veilige en efficiënte deployments, waarbij secrets en goedkeuringsprocessen essentieel zijn voor productieomgevingen.
• Gebruik dedicated deploy keys of machinegebruikers voor veilige automatische toegang en plan sleutelrotatie om risico’s bij compromittering te minimaliseren.
• Het toepassen van zero-downtime atomic deploys door symlinks te switchen en oude releases te bewaren, vermindert de kans op defecte live-omgevingen en vereenvoudigt rollback.

Inhoudsopgave

• Overzicht van gangbare deployment-methoden vanuit Git
• Server-setup: bare repository, SSH-toegang en permissies
• Automatiseren met git hooks en CI/CD
• Deploy keys, machine users en SSH-sleutelbeheer
• Zero-downtime en atomic deploy-strategieën
• Veelvoorkomende fouten, debugging en quick fixes
• Praktijkperspectief van Ken (NLXS): zelf doen of uitbesteden?
• NLXS als optie: hosting en managed serverbeheer
• Officiële documentatie en nuttige leesbronnen
• Bronnen
• Veelgestelde vragen

Overzicht van gangbare deployment-methoden vanuit Git

Er zijn een paar routes om code van je repository naar een server te krijgen, en elke route past bij een ander soort project. De keuze bepaalt hoeveel controle je hebt, hoeveel fouten je riskeert en hoeveel tijd je aan onderhoud besteedt.

• Direct uploaden via SFTP of FTP: snel op te zetten, maar foutgevoelig omdat je geen versiegeschiedenis of automatische controle hebt.
• Bare repository met git hooks: je pusht naar een self-hosted repository op de server, die zelf een script triggert. Eenvoudig, geschikt voor kleine teams zonder ingewikkelde build-stappen.
• CI/CD pipelines zoals GitHub Actions of GitLab CI: elke push doorloopt tests, build en deploy automatisch, met secrets en approvals voor extra veiligheid. Dit is de standaard voor teams die auditeerbaarheid en herhaalbaarheid nodig hebben.
• Rsync of scp naar een server, vaak binnen een CI-job, geschikt voor statische sites of builds die je eerst lokaal of in een pipeline compileert.

De eerste twee methoden werk je meestal zelf in, met volledige controle over elke stap. CI/CD kost meer opzet, maar betaalt zich terug zodra je met meerdere ontwikkelaars werkt of strengere eisen aan uptime stelt. Voor een simpele blog of interne tool is een bare repository met een hook vaak al voldoende, terwijl een productieomgeving met klantverkeer beter draait op een pipeline met expliciete goedkeuringsstappen.

Server-setup: bare repository, SSH-toegang en permissies

Een bare repository is de basis van elke self-hosted Git-server: hij bevat geen working directory en is daardoor niet vatbaar voor de corruptie die kan ontstaan als iemand direct naar een actieve branch pusht. Git raadt dit patroon aan voor server-side repositories die je via SSH benadert, met een conventie zoals /srv/git/project.git.

Zo richt je dat praktisch in:

1. Maak op de server een map aan, bijvoorbeeld /srv/git/project.git, en voer daar git init --bare --shared uit zodat bestandspermissies correct worden ingesteld voor meerdere gebruikers.
2. Kies tussen een gedeelde git-gebruiker voor alle ontwikkelaars of losse accounts per ontwikkelaar; een gedeelde gebruiker is eenvoudiger, losse accounts geven beter overzicht bij audits.
3. Zet de SSH-toegang op met public keys in ~/.ssh/authorized_keys van de gekozen gebruiker, en verifieer host keys bij eerste verbinding om spoofing te voorkomen.
4. Voeg vanaf je lokale project de remote toe met git remote add production ssh://git@server/srv/git/project.git en test met git push production main.

Let bij de sshd-configuratie op dat wachtwoordauthenticatie uitstaat en dat alleen key-based toegang is toegestaan. Dat voorkomt de meeste ongewenste inlogpogingen zonder dat je extra software nodig hebt.

Automatiseren met git hooks en CI/CD

Een post-receive hook draait op de server nadat een push succesvol is verwerkt, en is daarmee de eenvoudigste manier om een deployment te triggeren. Git’s eigen documentatie beschrijft dat pre-receive en update hooks vóór de ref-update lopen, terwijl post-receive pas na afronding start, precies het moment waarop je veilig kunt uitchecken en bouwen.

Een typische flow ziet er zo uit:

• Ontwikkelaar pusht naar de bare repository op de server.
• De post-receive hook checkt de nieuwe commit uit naar een werkmap.
• Het script draait bijvoorbeeld docker compose up --build of herstart de betreffende service.

Voor teams met meerdere ontwikkelaars of strengere eisen is CI/CD veiliger en beter te controleren. GitHub Actions werkt met environments waarin secrets alleen beschikbaar zijn voor jobs die expliciet naar die omgeving deployen, met optionele handmatige goedkeuring als extra slot op de deur (GitHub Actions documentatie). GitLab CI gebruikt CI/CD-variabelen zoals SSH_PRIVATE_KEY om via ssh-agent veilig te verbinden met de server, gecombineerd met een tmp-map en symlink-switch om downtime te vermijden (GitLab’s deployment voorbeeld).

Pro-tip: verifieer altijd de host key van de doelserver in je CI-job voordat je rsync of scp aanroept, anders loop je risico op een man-in-the-middle verbinding zonder dat je het merkt.

Deploy keys, machine users en SSH-sleutelbeheer

Automatische toegang vraagt om ander sleutelbeheer dan een persoonlijke login. Een deploy key is gekoppeld aan één repository en heeft standaard geen vervaldatum en meestal geen passphrase, wat handig is maar ook risico met zich meebrengt (GitHub’s documentatie over deploy keys).

• Gebruik voor één repository een dedicated deploy key met alleen leesrechten, tenzij schrijftoegang echt nodig is.
• Beheer je meerdere repositories op dezelfde server, kies dan een machine user met eigen sleutel in plaats van een persoonlijke sleutel te hergebruiken.
• Configureer ~/.ssh/config met aliassen per host, zodat elke sleutel automatisch bij de juiste server hoort zonder handmatig te schakelen.
• Plan sleutelrotatie in en trek toegang direct in bij een vermoeden van compromittering, zeker omdat deploy keys standaard niet verlopen.

Uitgebreidere richtlijnen voor het inrichten en roteren van sleutels vind je in ons artikel over SSH-sleutels beheren.

Zero-downtime en atomic deploy-strategieën

Een release die halverwege breekt terwijl gebruikers actief zijn, is het scenario dat je met een atomic deploy voorkomt. Het patroon is eenvoudig en werkt op vrijwel elke server:

1. Bouw de nieuwe versie in een tijdelijke map naast de huidige live-release.
2. Draai een sanity check, bijvoorbeeld een health check endpoint of een korte smoke test.
3. Wissel de symlink die naar de live-map wijst in één atomaire operatie naar de nieuwe release.
4. Houd de vorige release-map bewaard zodat een rollback simpelweg de symlink terugzet.

Database migraties en assets passen hierin als pre- of post-hook rond de symlink-switch, zodat het schema klaarstaat voordat verkeer de nieuwe code raakt. GitLab’s eigen voorbeeld bevestigt dat deze tmp-map-plus-symlink aanpak eenvoudiger is dan blue-green opzetten en in kleine setups weinig overhead toevoegt.

Pro-tip: bewaar minstens de laatste twee releases op schijf, zodat een rollback een kwestie van seconden is in plaats van een nieuwe build.

Veelvoorkomende fouten, debugging en quick fixes

De meeste deploy-problemen zijn te herleiden tot een klein aantal oorzaken die je snel kunt herkennen.

• receive.denyCurrentBranch: git blokkeert pushes naar een branch die is uitgecheckt; zet receive.denyCurrentBranch updateInstead of laat je post-receive hook naar een aparte werkmap uitchecken.
• Hook draait niet: controleer of het bestand uitvoerbaar is (chmod +x) en of de shebang-regel naar het juiste pad wijst.
• SSH-verbinding faalt: check permissies op ~/.ssh (moet 700 zijn) en op authorized_keys (600), en controleer op een host key mismatch na een serverwissel.
• Stille fouten in hooks: git hooks draaien in $GIT_DIR en lange processen houden de clientverbinding open, dus log output altijd naar een bestand in plaats van te vertrouwen op de terminal (githooks documentatie).

Praktijkperspectief van Ken (NLXS): zelf doen of uitbesteden?

Voor een klein team met beperkte uptime-eisen is een eigen bare repository met hooks vaak de snelste en goedkoopste route, en die controle heb je dan ook volledig zelf. Zodra je een SLA, 24/7 bereikbaarheid of een migratie zonder downtime nodig hebt, verschuift de afweging: dan telt niet alleen de techniek, maar ook wie er ’s nachts opstaat als iets breekt.

— Ken

NLXS als optie: hosting en managed serverbeheer

Zelf een deploy-pijplijn onderhouden kost tijd die je liever aan je product besteedt, en dat is precies waar NLXS het verschil maakt: wij nemen serverbeheer, monitoring en migraties over zodat jij niet elke storing zelf hoeft op te lossen.

• Hosted serverbeheer houdt je infrastructuur draaiende zonder dat jij zelf hooks of pipelines moet onderhouden.
• Snelle support bij problemen, in plaats van lange wachttijden.
• Migratie met minimale downtime wanneer je van een zelfgehoste opzet naar een beheerde omgeving overstapt.

Bekijk onze ICT-diensten en serverbeheer voor de mogelijkheden, of vraag een scan aan om te zien wat bij jouw situatie past.

Officiële documentatie en nuttige leesbronnen

Voor verdere verdieping zijn de onderstaande bronnen een goed startpunt.

• Git Hooks documentatie voor de werking van post-receive en andere hooks.
• Git on the Server voor het opzetten van een bare repository.
• GitHub Actions environments voor secrets en goedkeuringsregels.
• Voor SEO-tooling naast je technische stack kun je ook kijken naar Bolt.dev SEO Autopilot.

Bronnen

• Git – Git Hooks
• Git – Getting Git on a Server
• GitHub Actions — deployment environments
• GitLab CI example: deployment with rsync/atomic deploy pattern

Veelgestelde vragen

Hoe host ik een Git-repository op mijn eigen server?

Je maakt een bare repository met git init --bare --shared op een geschikt pad en geeft ontwikkelaars SSH-toegang via public keys. Vanaf daar voeg je de server toe als remote en push je zoals bij elke andere repository.

Wat is het verschil tussen deploy en deployment?

“Deploy” is het werkwoord voor de actie: code naar een server sturen en live zetten. “Deployment” is het zelfstandig naamwoord voor het gehele proces of de specifieke uitrol, inclusief build, checks en de eventuele rollback-mogelijkheid.

Kan ik GitHub zelf hosten op mijn eigen server?

GitHub zelf is een cloud-dienst en niet bedoeld om zelf te hosten, maar je kunt met een gewone bare repository dezelfde functionaliteit zelf opzetten via SSH. Voor teams die specifiek GitHub-achtige features zelf willen beheren, bestaan losstaande self-hosted alternatieven, los van GitHub zelf.

Kan ik deployen via GitHub zonder losse server-scripts?

Ja, via GitHub Actions kun je een workflow bouwen die bij elke push automatisch test, bouwt en deployt naar je server, met environment secrets voor de SSH-sleutel. Dat vervangt een handmatige hook-opzet door een pipeline die je in de repository zelf beheert.

Wanneer kies ik voor managed serverbeheer in plaats van zelf deployen?

Zodra uptime, 24/7 bereikbaarheid of een migratie zonder downtime belangrijker worden dan de besparing van het zelf beheren, is managed serverbeheer meestal de logischere keuze. NLXS biedt dat via hosted serverbeheer voor teams die deze zorg willen uitbesteden.

Aanbevelingen

• Cloud of lokale server: wat past beter?
• Developer toegang hosting configureren voor bedrijven
• Hosted werkplek of kantoorserver kiezen
• Managed hosting vergelijken zonder verrassingen