Laravel Vapor vs Laravel Forge in 2026: Which Deployment Platform Should You Choose?

Every few months someone asks me whether they should use Forge or Vapor for their next Laravel project. They're both official Laravel products, they both get you to production — and almost everything else about them is different.

Laravel Vapor vs Forge: the fundamental difference

Forge is a server management tool. You bring your own VM (DigitalOcean, Hetzner, AWS EC2, whatever), and Forge provisions it, deploys your code, manages your Nginx config, handles SSL, and gives you a dashboard to do all of this without SSH. Your server runs 24/7. Persistent processes — queues, scheduled tasks, WebSocket servers — work exactly as you'd expect.

Vapor is serverless deployment on AWS Lambda. There is no server. Your Laravel application runs as a function that spins up, handles a request, and disappears. AWS scales it horizontally and automatically with no action from you. The trade-off is that you give up a lot of standard PHP runtime assumptions.

That distinction matters more than any feature comparison.

When to choose Laravel Forge

Forge wins when your workload maps well to a traditional server model.

Persistent processes. If you're running Laravel Reverb for WebSockets, queue workers that maintain long-lived connections, or scheduled commands that need reliable timing — Forge is the right call. Lambda functions cap out at 15 minutes for CLI tasks and 30 seconds for web requests through API Gateway. Reverb won't run on Lambda at all.

Predictable traffic. If your app gets consistent traffic without wild spikes, you're not getting value from auto-scaling. A $12/month Forge Hobby plan plus a $6–12/month VPS (Hetzner, DigitalOcean) is real competition on price.

Tight budget. Forge starts at $12/month. Vapor is $39/month — before you factor in AWS usage fees for S3, SQS, RDS, ACM, and data transfer. For a side project or a low-traffic app, the gap is significant.

You want to own the server. Some teams need to know exactly where data lives and what software is running. Forge gives you a plain Linux box you can SSH into. If compliance requirements or personal preference leans that way, Vapor's managed abstraction will feel uncomfortable.

When to choose Laravel Vapor

Vapor wins when the serverless model actually solves your problem.

Unpredictable or spiky traffic. This is Vapor's killer use case. If you launch something and it goes viral, or you have flash sales, event-driven traffic bursts — Vapor scales without any action from you. On Forge, you'd either overprovision or scramble to resize your server.

Zero-ops preference. No patching the OS. No Supervisor config for queue workers. No firewall rules. No worrying about whether the Ubuntu security update breaks something. If your team is small and infrastructure time is expensive, Vapor removes that cost entirely.

Genuinely variable load. Lambda pricing is pay-per-invocation. If your app is idle for 20 hours a day, you're not paying for a running server those 20 hours. For apps with uneven usage patterns — internal tools, batch-processing apps, admin panels with bursts — that can be meaningful.

Cost breakdown

For a mid-size app, realistic numbers look like this:

Vapor's AWS costs depend heavily on traffic, your database choice (RDS vs Aurora Serverless), NAT gateway configuration, and S3 usage. They can surprise you. Budget conservatively and watch CloudWatch costs from the start.

Gotchas Worth Knowing

Vapor: cold starts. When a Lambda container hasn't handled a request recently, AWS has to spin one up. This adds 800–1,200ms to that request. It affects roughly 0.3–1% of requests in practice, but you'll feel it in development and right after deployment. Mitigate it with the warm option in vapor.yml:

# vapor.yml
id: 12345
name: my-laravel-app
environments:
  production:
    runtime: "php-8.4:al2023"  # al2 is deprecated after June 30, 2026 — use al2023
    memory: 1024
    cli-memory: 512
    warm: 5  # Keep 5 containers pre-warmed to absorb traffic spikes
    build:
      - "composer install --no-dev"
      - "npm ci && npm run build"
    deploy:
      - "php artisan migrate --force"
      - "php artisan config:cache"

Vapor: ephemeral filesystem. Lambda has no persistent local disk. The /tmp directory gives you 512MB per execution — but it's gone when the container is recycled. Any file your app writes (uploads, generated PDFs, logs) needs to go to S3 instead. If your app assumes storage/app is permanent, refactor that before going to Vapor.

Vapor: WebSockets don't work natively. You can't run Laravel Reverb on Lambda. Real-time features need a separate service — Pusher, Ably, or a dedicated Reverb instance running on a Forge server alongside your Vapor deployment. The hybrid approach is more common than you'd think: Vapor for the main Laravel app, a small Forge server just for Reverb and heavy queue work.

Vapor: use al2023 runtime, not al2. Amazon Linux 2 support ends June 30, 2026. If you're configuring or migrating a Vapor environment now, set the runtime to php-8.4:al2023 (or the al2023-arm variant for Graviton). Using al2 will stop receiving security updates and will eventually break deployments.

Forge: you own security patching. Forge provisions and deploys, but it doesn't auto-update your OS. You're responsible for apt upgrade, monitoring CVEs in your stack, and keeping the firewall tight. This is straightforward but it's your job, not Forge's.

Forge: scaling is manual. When your server runs out of headroom, you resize it or add more servers behind a load balancer — manually. There's no automatic horizontal scaling. For most apps this is fine; for genuinely elastic workloads it's a real constraint.

Quick Decision Table

Wrapping Up

If your app runs background jobs, WebSockets, or long-running processes, start with Forge — the persistent server model fits those workloads and you'll fight Vapor's Lambda constraints at every turn. If your traffic is genuinely unpredictable and you want to hand off infrastructure entirely, Vapor earns its premium. The hybrid — Vapor for the app, a small Forge server for Reverb and heavy queue work — is also a legitimate production setup that gives you the best of both. Start with the process model your workload needs, then pick the platform that supports it.