Laravel Vapor: Serverless PHP Arrives

Archive note: this is a backdated post, written years later while rebuilding this site. It’s dated to the moment it covers, but the hindsight is real.

The big reveal at this week’s Laracon US: Laravel Vapor, a first-party platform that deploys Laravel applications onto AWS Lambda — serverless, auto-scaling, with the queue workers, scheduled jobs, database and cache wiring handled for you. Taylor Otwell demoed apps absorbing traffic spikes with no servers provisioned anywhere, and the PHP corner of Twitter has been buzzing since.

“Serverless PHP” sounds like an oxymoron — our entire deployment culture is LAMP boxes and php artisan over SSH — so it’s worth unpacking what this actually is.

What serverless means for a Laravel app

There are servers, obviously; they’re just not your problem. On Lambda, your application isn’t a process waiting on a box you rent monthly — it’s a function invoked per request, scaled from zero to thousands of parallel executions by AWS, billed per use. Vapor’s job is making Laravel — a framework with assumptions about filesystems, sessions, and long-lived workers — feel native in that world: queues map to SQS, cache to managed Redis/DynamoDB, files to S3, the scheduler to actual events. The vapor deploy experience looks, from the demos, as polished as everything else in this ecosystem.

The honest trade-offs, visible even from the keynote distance:

Scaling anxiety dies; cold starts and new limits are born. No more “will the box survive the promo traffic” — but also: invocation time caps, package size limits, no local disk to lean on, and the cold-start tax when a function wakes. Different problems, not zero problems.
The bill becomes a function of traffic. Per-request billing is beautiful at low and spiky volume, and needs actual arithmetic at sustained high volume versus a boring fixed-price server. “Cheaper” is a workload property, not a platform property.
The lock-in is real and double-layered. Vapor is AWS-only and Laravel-only. You’re trading operational freedom for operational silence. Some days that trade is obviously right; it should still be made with eyes open — this month’s other tech news is one long sermon on what platform dependency costs when the weather changes.

What it signals beyond the product

The product is interesting; the posture is more so. PHP’s reputation abroad is stuck in 2008 — shared hosting, FTP uploads — while the actual ecosystem now ships first-party serverless deployment with a keynote and a SaaS. Laravel keeps doing this: Forge made server provisioning civilized, Nova made admin panels a product, now Vapor jumps the deployment story a full generation. The framework increasingly competes not with other PHP frameworks but with the entire experience of building and running a web product.

For a dev in the Philippines, the economics deserve a note too: serverless means client projects can start at near-zero infrastructure cost and scale with actual success — a fit for the budget realities of local SMEs, if the AWS bill’s unpredictability can be explained to a client who’s used to one hosting number per month. (“It depends on traffic” is a sentence that requires tea and a whiteboard.)

Will I use it?

Not tomorrow — my work runs on boring VPSes that I understand down to the socket, and that understanding is worth a lot when things break at 11pm. But I’m filing Vapor under direction of travel: the platform’s message is that where your code runs is becoming a config detail, not an identity. Worth absorbing even if you never click deploy — the parts of ops it abstracts away are exactly the parts worth learning before you let anything abstract them.