De combinatie die wij inzetten
Bij Coding Agency draaien de meeste projecten op Laravel Vapor en AWS. Niet omdat het hip is, maar omdat het de meest pragmatische keuze is voor applicaties die betrouwbaar moeten zijn, moeiteloos moeten schalen en minimaal operationeel beheer vragen. De wereldwijde serverless markt groeit van $28 miljard in 2025 naar verwacht $92 miljard in 2034 (Precedence Research) — serverless is geen trend meer, maar de standaard.
Vapor is de brug tussen Laravel en AWS: het vertaalt je Laravel-applicatie naar een serverless architectuur op Amazon Web Services, zonder dat je zelf AWS hoeft te begrijpen.
Wat AWS levert onder de motorkap
Vapor orkestreert een reeks AWS-services die samen een robuust platform vormen:
- AWS Lambda — Je applicatiecode draait op Lambda-functies die automatisch schalen van nul naar duizenden gelijktijdige verzoeken. Met 29% marktaandeel is Lambda de marktleider in serverless computing (GM Insights, 2025).
- API Gateway — Routeert HTTP-verzoeken naar je Lambda-functies, inclusief SSL-certificaten en custom domeinen.
- S3 — Bestanden, uploads en assets worden opgeslagen in S3, de meest betrouwbare object storage ter wereld.
- CloudFront — CDN voor statische assets en full-page caching. Je content wordt geserveerd vanuit het dichtstbijzijnde datacenter.
- SQS — Queue-service voor achtergrondtaken: e-mails versturen, imports verwerken, notificaties dispatchen.
- RDS — Managed databases (MySQL of PostgreSQL) met automatische backups, failover en scaling.
- ElastiCache — Managed Redis voor caching en sessie-opslag.
Het bijzondere aan deze opzet is dat je nergens een server hoeft op te tuigen of te onderhouden. Vapor en AWS regelen de orkestratie. Jij werkt verder met de Laravel-concepten die je kent: een route, een job, een mailable, een storage disk. Achter de schermen vertaalt Vapor dat naar de juiste AWS-service.
Hoe schalen, cold starts en concurrency werken
De kern van serverless is dat er pas rekencapaciteit wordt opgestart op het moment dat er een verzoek binnenkomt. Bij weinig verkeer draaien er weinig functies, bij een piek schalen er automatisch meer bij. Standaard kan een AWS-account tot ongeveer 1.000 verzoeken tegelijk verwerken over alle Lambda-functies in een regio; heb je meer nodig, dan vraag je via AWS een verhoging van die limiet aan.
Die manier van werken heeft één bekend aandachtspunt: de cold start. Als een functie een tijd niet is aangeroepen, moet AWS eerst een nieuwe container opstarten, je code laden en de applicatie bootstrappen voordat het verzoek wordt afgehandeld. Volgens de Vapor-documentatie kost zo'n eerste verzoek doorgaans een paar seconden extra.
Vapor beperkt dit met pre-warming. Je geeft in de configuratie aan hoeveel containers Vapor warm moet houden. Vapor maakt die containers al klaar vóórdat een nieuwe deployment publiek wordt, en blijft volgens dezelfde documentatie elke vijf minuten dit aantal containers pre-warmen zolang de applicatie draait. Daarmee staat er altijd een aantal containers klaar en merken je gebruikers in de praktijk niets van cold starts.
Databases en queues serverless draaien
Een veelgehoord misverstand is dat serverless alleen je applicatiecode betreft. In de praktijk draait een Vapor-project veel meer onderdelen zonder dat je een server beheert.
Voor databases biedt Vapor twee smaken. Je kunt een klassieke RDS-database met een vaste hoeveelheid geheugen en schijfruimte kiezen (MySQL of PostgreSQL), of een Aurora Serverless-database die automatisch op- en afschaalt en geen vaste capaciteit heeft. Met de komst van Aurora Serverless v2 schaalt de database sneller en met kleinere stappen mee met de belasting, wat goed past bij applicaties met wisselend verkeer.
Achtergrondtaken lopen via SQS. Verstuur je een e-mail, verwerk je een import of dispatch je een notificatie, dan plaatst Laravel die job op een queue en handelt een aparte Lambda-functie het af. Caching en sessies gaan via ElastiCache (Redis). Het resultaat is dat je hele applicatie — web, database, queue, cache, bestandsopslag — meeschaalt zonder dat je ergens handmatig capaciteit hoeft te reserveren.
Waarom niet gewoon een VPS?
Een traditionele VPS (via Laravel Forge of handmatig) werkt prima voor veel projecten. Maar het heeft nadelen die met Vapor verdwijnen:
Schaalbaarheid. Een VPS heeft een vast plafond. Groeit je verkeer, dan moet je handmatig opschalen naar een grotere server of load balancing configureren. Met Vapor schaalt je applicatie automatisch — je merkt het verschil pas op de factuur, niet in de performance.
Beschikbaarheid. Een VPS is een single point of failure. Server crasht? Applicatie offline. Vapor draait verspreid over meerdere AWS availability zones. Een heel datacenter kan uitvallen zonder dat je gebruikers er iets van merken.
Onderhoud. Een VPS vereist OS-updates, security patches, PHP-upgrades, Nginx-configuratie. Met Vapor is dat allemaal AWS' verantwoordelijkheid. Je team besteedt nul uur per maand aan serverbeheer.
Deployments. Deployen naar een VPS heeft altijd een risico: iets kan fout gaan en je site is offline. Vapor doet zero-downtime deployments als standaard. Gaat er iets mis? Rollback in seconden.
Serverbeheer is geen kernactiviteit van je bedrijf. Elke uur die je team besteedt aan OS-updates en patches is een uur die niet naar je product gaat.
Hoe een deployment eruitziet
Het deployproces met Vapor is radicaal simpel. Je configureert je omgeving; database, cache, domein, instellingen; en deployt met één commando. Vapor bouwt een pakket van je applicatie, plaatst deze op AWS en schakelt het verkeer over.
Dit duurt typisch 60-90 seconden. Geen SSH, geen manual steps, geen stress. En als de deployment mislukt? Het verkeer blijft naar de vorige versie gaan. Niets is kapot.
Meerdere omgevingen in minuten
Een krachtig aspect van Vapor: het opspinnen van extra omgevingen is triviaal. Productie, staging, demo voor een klant, feature branch testen — elke omgeving is een kopie met eigen resources. Dit is vooral waardevol bij projecten met meerdere stakeholders die features willen reviewen voordat ze naar productie gaan.
De kosten
De licentie van Vapor wordt per project afgerekend; daarbovenop komen de AWS-kosten, die bij serverless volgens een pay-per-use model lopen. Je betaalt dus naar werkelijk gebruik — verwerkte requests, rekentijd en opslag — in plaats van voor vaste servercapaciteit die ook stilstaand doorloopt. Voor applicaties met wisselend of laag verkeer pakt dat model vaak gunstig uit, omdat je niets betaalt voor capaciteit die je niet gebruikt.
De vergelijking met een traditionele VPS is genuanceerd: een vaste server kan op papier voordeliger lijken, maar je betaalt in uren serverbeheer. Tel je de tijd van je team mee, dan valt de vergelijking voor de meeste projecten in het voordeel van Vapor uit.
Wanneer Vapor niet de beste keuze is
Eerlijkheid: Vapor is niet altijd het antwoord. Niet geschikt wanneer:
- Je applicatie WebSockets gebruikt (Laravel Reverb draait op een aparte server)
- Je langlopende processen hebt van meer dan 15 minuten
- Je budget zeer beperkt is en je verkeer constant en laag
- Je volledige controle over de serveromgeving nodig hebt
In die gevallen adviseren we Laravel Forge of Ploi op een DigitalOcean- of AWS EC2-server. Het verschil met Vapor zit in waar de verantwoordelijkheid ligt: Forge en Ploi beheren een traditionele server waarop jij zelf de capaciteit bepaalt en het besturingssysteem in de lucht houdt, terwijl Vapor het serverbeheer volledig uit handen neemt en automatisch meeschaalt. Forge en Ploi geven je meer controle over de omgeving en zijn voorspelbaar in kosten bij constant verkeer; Vapor wint bij wisselend verkeer en bij teams die geen tijd aan infrastructuur willen kwijt zijn.
Welke aanpak voor jouw situatie het beste past, hangt af van je verkeerspatroon, je team en je behoefte aan controle. We zetten de afwegingen uitgebreider naast elkaar in ons artikel over traditionele hosting versus serverless op AWS.
Een vaste server lijkt goedkoop, tot je de uren serverbeheer meetelt. Reken eerlijk en de vergelijking valt anders uit.
EU-regio's en dataresidentie
Voor Nederlandse bedrijven is het belangrijk dat data binnen de Europese Unie blijft. AWS biedt daarvoor meerdere Europese regio's. De regio eu-central-1 staat in Frankfurt, Duitsland, en daarnaast zijn er onder meer regio's in Ierland (eu-west-1), Parijs (eu-west-3) en Stockholm (eu-north-1). Door je Vapor-omgeving in een van deze regio's te draaien, blijven je verzoeken, databases en bestandsopslag fysiek binnen de EU.
Elke AWS-regio bestaat bovendien uit meerdere, van elkaar gescheiden Availability Zones — geïsoleerde locaties binnen dezelfde regio. Doordat je applicatie over die zones verspreid draait, kan één locatie uitvallen zonder dat je dienst onderbroken wordt. Voor wie te maken heeft met de AVG of met sectorspecifieke eisen rond dataresidentie, is het kiezen van een Frankfurt- of Ierland-regio een eenvoudige manier om data binnen Europa te houden. Hoe wij dat in de praktijk inrichten, lichten we verder toe in ons artikel over AWS-hosting binnen de EU.
Altijd migreerbaar
Een belangrijk principe: we bouwen je applicatie nooit afhankelijk van AWS. De code is standaard Laravel — geen AWS-specifieke SDK's of services in je business logic. Vapor is een deployment-laag, niet een architectuur-afhankelijkheid. Wil je ooit verhuizen naar een andere provider? Dan deployen we dezelfde codebase op een VPS via Forge of op een andere cloud. Je bent eigenaar van je code en je bent vrij om te vertrekken.
Conclusie
Laravel Vapor en AWS vormen het platform waar wij de meeste projecten op draaien. Het combineert de productiviteit van Laravel met de schaalbaarheid en betrouwbaarheid van AWS, zonder de operationele overhead van serverbeheer. Voor onze klanten betekent dit: een applicatie die altijd draait, automatisch meeschaalt en waarvoor ze nooit wakker gebeld worden.
