Laravel Vapor Limitations: What Breaks and When to Look Elsewhere
What Vapor Actually Is
Vapor deploys Laravel applications to AWS Lambda — no servers to patch, automatic scaling with traffic, and a genuinely serverless operating model for a framework that wasn't originally built with serverless in mind. For a Laravel app with real traffic spikes (a flash sale, a viral moment, unpredictable seasonal load), that scaling model is a legitimate advantage over a fixed-capacity server that either sits idle most of the time or falls over during a spike.
The constraints below aren't reasons Vapor is bad. They're reasons it's not universally right, and they matter most when a team adopts Vapor for the "serverless" story without checking whether their specific app hits one of these walls.
The Ephemeral Filesystem
Lambda functions don't have a persistent local disk — anything written to /tmp or the local filesystem during one invocation is gone by the time the next one runs, possibly in a completely different container. Vapor works around this by routing file storage to S3 by default.
The problem shows up in code that assumes local-disk persistence, which is a common pattern in Laravel apps that were built for traditional hosting: temporary file processing, local caching of generated assets, anything using Storage::disk('local') as if it survives between requests. None of that breaks loudly — it just silently doesn't persist, which is a worse failure mode than a crash because it can ship unnoticed.
Lambda Execution Time Limits
AWS Lambda functions have a hard execution time ceiling. Long-running processes — a big data export, a video transcode, an import job that takes several minutes — don't fit that model at all. Vapor handles Laravel's queue system by dispatching jobs to separate Lambda invocations, which works for most background jobs, but a genuinely long-running task still needs to be broken into smaller chunks or moved off Vapor entirely.
Test your Laravel app's real behavior, not just its Lambda-compatible code paths.
A per-PR environment with a persistent filesystem and no execution limits catches what Vapor's constraints would otherwise hide until production.
WebSockets and Laravel Reverb
Laravel Reverb — Laravel's own WebSocket server, for real-time features like live notifications or presence — needs a persistent, long-running process holding open connections. That's structurally incompatible with Lambda's request-scoped, ephemeral execution model.
Marcus ran platform for a Laravel app with a real-time collaboration feature built on Reverb, deployed on Vapor for everything else. The fix wasn't complicated once identified — Reverb runs on a small traditionally hosted instance outside Vapor, with the rest of the app still on Lambda — but it meant the "everything's serverless" pitch didn't hold for the whole application, and the team had to maintain two deployment targets instead of one.
Cost at Steady Traffic
Serverless pricing is pay-per-invocation, which is genuinely cheaper than a fixed server when traffic is spiky and idle time would otherwise go to waste. It inverts for steady, predictable traffic: a Lambda invocation costs more per request than the equivalent slice of a traditional server's capacity, so a consistently busy app can end up paying a premium for elastic scaling it doesn't actually need.
The practical test: if your traffic graph looks like a flat line with occasional spikes, Vapor's model fits. If it looks like a flat line with no spikes, a traditional host or container platform is probably cheaper for the same load.
What This Means for Testing and Preview Environments
None of Vapor's constraints are unique to production — they show up in any environment built the same way, including previews. A PR preview environment on Vapor inherits the same ephemeral filesystem and execution limits as production, which is correct if you want production-representative previews, but means a test that relies on local file persistence will fail in preview for the same reason it would fail in production — worth catching there rather than after merge.
Teams that don't need Lambda's scaling model at all sidestep these constraints by running Laravel on a platform with a persistent filesystem and no execution ceiling. Bunnyshell's Laravel preview environment guide covers the Docker Compose and Helm-based setup for that approach — full-stack, including a Node.js worker or a separate service alongside Laravel if your app needs it, which isn't something Vapor's Laravel-specific Lambda model does at all.
Deciding If Vapor Is Right For Your App
Genuinely spiky traffic, no long-running processes, no WebSocket-heavy features, and file storage already routed through S3 or similar — Vapor is a reasonable, well-supported choice. Steady traffic, long-running jobs, Reverb, or code with local-filesystem assumptions — any one of those is a real reason to look at a traditional server or container-based platform instead, not a sign you're using Vapor wrong.
If the app is Laravel plus something else — a Node.js worker, a separate frontend — that's also worth weighing against Laravel Cloud and Laravel Forge directly, since none of the three officially-adjacent options handle a mixed stack in one environment the way a BYOC Kubernetes platform does.
✅ Key Takeaways
- Vapor's ephemeral filesystem means anything written to local disk doesn't persist between Lambda invocations — file storage needs to route through S3
- Lambda's execution time limits rule out long-running processes without breaking them into smaller jobs
- Laravel Reverb and other WebSocket-heavy features need a separate, traditionally hosted process — they don't fit Lambda's model
- Vapor's pay-per-invocation pricing is cheaper for spiky traffic and more expensive than traditional hosting for steady, predictable load
- None of these constraints are Vapor being broken — they're reasons it fits some Laravel apps and not others
FAQ
What are the main limitations of Laravel Vapor?
An ephemeral filesystem that resets when a Lambda container recycles, meaning anything written to local disk doesn't persist. AWS Lambda execution time limits that rule out long-running processes. Limited native support for Laravel Reverb and other WebSocket-heavy features, which typically need to run outside Vapor. And cost that can exceed traditional hosting once traffic is steady rather than spiky.
Can Laravel Vapor handle WebSockets?
Not natively for sustained connections. Laravel Reverb and other WebSocket servers need a persistent, long-running process, which doesn't fit Lambda's execution model. Teams running Vapor for their main app typically run Reverb on a separate, traditionally hosted server.
Is Laravel Vapor cheaper than traditional hosting?
It depends on traffic shape. For genuinely spiky, unpredictable traffic, Vapor's pay-per-invocation model can be cheaper because you're not paying for idle server capacity. For steady, predictable traffic, a traditional server or container-based host is usually cheaper — you're paying Lambda's per-invocation premium for scaling you don't need.
How do you store files with Laravel Vapor?
Vapor's Lambda functions have an ephemeral filesystem, so file storage needs to go to S3 (Vapor's default) rather than local disk. Any code that assumes files persist on the local filesystem between requests — a common pattern in traditionally hosted Laravel apps — needs to be rewritten around S3 before it works on Vapor.
What's a good alternative to Laravel Vapor for preview environments?
A platform like Bunnyshell provisions full-stack Laravel environments — with a persistent filesystem, no Lambda execution limits, and native WebSocket support — on your own Kubernetes cluster, which sidesteps Vapor's serverless-specific constraints entirely for teams that don't need Lambda's scaling model.
Not every Laravel app needs Lambda's constraints.
Full-stack preview environments with a persistent filesystem and no execution limits — for the apps where Vapor's model doesn't fit.
