Zero-downtime deployments met Laravel.

Waarom downtime niet acceptabel is

De tijden van geplande onderhoudsmomenten zijn voorbij. Gebruikers van SaaS-applicaties verwachten 24/7 beschikbaarheid. Niet als luxe, maar als baseline. Ze loggen in wanneer het hen uitkomt — om 09:00 op maandagochtend, maar net zo goed om 22:30 op zondag. Een applicatie die op dat moment onbereikbaar is, verliest niet alleen een sessie maar ook vertrouwen.

"Even vijf minuutjes downtime" klinkt onschuldig tot het samenvalt met een piek in je verkeer. Een webshop die offline is tijdens een campagne. Een planningsysteem dat niet bereikbaar is op het drukste moment van de dag. Een klantportaal dat precies uitvalt wanneer iemand een deadline heeft. De schade is niet alleen gemiste omzet — het is reputatieschade die lastig te herstellen is.

Onderhoudspagina's waren ooit normaal. "We zijn bezig met een update, probeer het later opnieuw." In 2025 is dat geen acceptabel antwoord meer. Gebruikers hebben alternatieven en ze aarzelen niet om die te gebruiken. Elke deployment die downtime veroorzaakt is een risico dat je niet hoeft te nemen — want de tooling om het te vermijden bestaat al lang.

Hoe zero-downtime werkt

Het principe achter zero-downtime deployments is eenvoudig: de oude versie blijft draaien totdat de nieuwe versie bewezen gezond is. Pas dan wordt het verkeer omgeschakeld. Er zijn meerdere strategieen om dit te bereiken.

Blue-green deployments

Bij een blue-green deployment draai je twee identieke omgevingen: blue (de huidige productieversie) en green (de nieuwe versie). Je deployt de update naar green, test of alles werkt, en schakelt vervolgens het verkeer om. Gaat er iets mis? Je schakelt terug naar blue. Beide omgevingen staan klaar, de switch is vrijwel instant.

Rolling deployments

Bij rolling deployments vervang je servers een voor een. Terwijl de eerste server wordt geupdate, vangen de overige servers het verkeer op. Zodra de eerste server gezond is, volgt de tweede. Dit is geheugen-efficienter dan blue-green omdat je geen volledige dubbele omgeving nodig hebt, maar het is complexer om correct te implementeren.

Atomic deployments met Laravel Vapor

Laravel Vapor gaat een stap verder. Elke deployment creert een nieuwe versie van je Lambda-functie. De oude versie blijft actief tot de nieuwe versie volledig is ingericht — inclusief warmed-up containers. De switch is atomic: het ene moment bedient de oude versie je verkeer, het volgende moment de nieuwe. Er is geen overgangsperiode waarin je applicatie in een halve staat draait.

Een deployment die je team stress bezorgt is een deployment die niet goed is ingericht. Releases horen routine te zijn, geen evenement.

Database migraties zonder downtime

De applicatiecode vervangen is het makkelijke deel. Het lastige deel is de database. Schema-wijzigingen op een live database zijn waar de meeste zero-downtime strategieen falen — tenzij je er bewust mee omgaat.

Additieve migraties

De gouden regel: voeg toe, verwijder niet. Een nieuwe kolom toevoegen aan een tabel is veilig. De bestaande code gebruikt die kolom simpelweg niet tot de nieuwe versie live staat. Een kolom verwijderen of hernoemen terwijl de oude code nog draait, is vragen om problemen.

Twee-fasen migraties

Complexe schema-wijzigingen splits je op in meerdere stappen. Stel: je wilt een kolom in je database hernoemen. Doe dit niet in een stap. In plaats daarvan:

• Fase 1: Voeg de nieuwe kolom toe. Deploy code die naar beide kolommen schrijft maar leest uit de oude. De oude versie van je code werkt nog steeds, want de oorspronkelijke kolom is ongewijzigd.
• Fase 2: Migreer de data. Kopieer de waarden van de oude naar de nieuwe kolom. Schakel de code over naar lezen uit de nieuwe kolom.
• Fase 3: Ruim op. Verwijder de oude kolom en de code die ernaar verwijst. Dit kan in een volgende release, op een moment dat je zeker weet dat alles stabiel draait.

Dit voelt omslachtig, maar het is de enige manier om schema-wijzigingen door te voeren zonder dat je applicatie even in een inconsistente staat belandt. Elke stap is backward-compatible: de vorige versie van je code blijft functioneren na elke migratie.

CI/CD pipeline

Zero-downtime deployments zijn alleen betrouwbaar als het hele proces geautomatiseerd is. Handmatige stappen introduceren menselijke fouten en dat is precies wat je probeert te elimineren. Een solide CI/CD-pipeline is geen luxe maar een vereiste.

De stappen

Een typische pipeline voor een Laravel-applicatie ziet er zo uit:

• Build — Dependencies installeren, assets compileren, environment-configuratie valideren.
• Test — Unit tests, feature tests, en eventueel integration tests draaien. Faalt er een test? De deployment stopt hier. Geen uitzonderingen.
• Deploy — De nieuwe versie wordt uitgerold naar de doelomgeving. Bij Vapor is dit een enkel commando.
• Verify — Smoke tests op de live omgeving. Reageert de applicatie? Zijn de kritieke endpoints bereikbaar? Kloppen de health checks?

Faalt de verificatie, dan volgt automatische rollback. Geen Slack-bericht naar een developer die handmatig moet ingrijpen. De pipeline herstelt zichzelf en stuurt een notificatie dat er iets mis ging. Het team kan het probleem onderzoeken zonder dat er gebruikers last van hebben.

GitHub Actions is hiervoor een sterke keuze: het integreert naadloos met je repository, ondersteunt matrix-testing voor meerdere PHP-versies en heeft native ondersteuning voor secrets en environment variables. De workflow-definitie leeft in je repository, naast je code, onder versiebeheer.

Laravel Vapor specifiek

Vapor maakt zero-downtime deployments niet alleen mogelijk maar maakt ze de standaard. Elke deployment is per definitie zero-downtime. Dat is niet iets wat je configureert — het is hoe het platform werkt.

Atomic function versioning

Bij elke deployment maakt Vapor een nieuwe versie van je Lambda-functie aan. De oude versie blijft beschikbaar en bedient verkeer tot de nieuwe versie volledig is geconfigureerd. De omschakeling gebeurt via AWS API Gateway en is atomic: er is geen moment waarop verkeer naar een half-gedeployde versie gaat.

Queue workers

Queue workers herstarten graceful. Lopende jobs worden afgemaakt voordat de worker overschakelt naar de nieuwe codeversie. Er gaan geen jobs verloren en er worden geen jobs halverwege afgebroken. SQS-queues garanderen delivery, dus zelfs als een worker onverwacht stopt, wordt de job opnieuw opgepakt.

Asset versioning

Statische assets (CSS, JavaScript, afbeeldingen) worden geserved via CloudFront met unieke hashes in de bestandsnamen. De nieuwe versie van je applicatie verwijst naar nieuwe asset-URLs. Gebruikers die nog de oude pagina open hebben, blijven de oude assets laden — zonder 404's of gebroken stylesheets. Zodra ze de pagina herladen, krijgen ze de nieuwe versie.

Geen filesystem-problemen

Traditionele deployments worstelen vaak met gedeelde filesystemen: uploads die verdwijnen, cache die corrupt raakt, session files die niet meer kloppen. Vapor elimineert dit probleem volledig. Bestanden gaan naar S3, cache naar DynamoDB of Redis, sessies naar een externe store. Elke Lambda-invocatie is stateless — er is niets om kwijt te raken.

Wanneer je team op vrijdagmiddag zonder aarzeling deployt, weet je dat je deployment-strategie klopt.

Conclusie

Zero-downtime deployments zijn geen rocket science. Het vereist discipline in hoe je migraties schrijft, een geautomatiseerde pipeline die je vertrouwt en tooling die atomic deployments faciliteert. Laravel Vapor maakt dit triviaal voor Laravel-applicaties, maar de principes — additieve migraties, automated testing, automatic rollback — gelden ongeacht je hostingomgeving.

Het doel is niet alleen het elimineren van downtime. Het doel is het creeren van een deployment-cultuur waarin releases routine zijn. Waar je team met vertrouwen deployt, wetende dat er automatische vangnetten zijn. Waar een release op dinsdag om 14:00 net zo normaal is als een commit pushen.

Wil je je deployment-proces professionaliseren of overstappen op zero-downtime deployments? Wij helpen je graag met het opzetten van een pipeline die je team sneller en met meer vertrouwen laat deployen.