Updated June 2026. Concepts tested against current Vapor. Part of the Techalyst Vapor series. For what Vapor actually is, see What Is AWS Lambda, and How Laravel Vapor Uses It.

Vapor is great, but it is not for every project. Rather than hype it, here are the objections people actually raise, answered honestly, so you can decide whether it fits your case.

"A small server is cheap. Why pay for Vapor?"

If a single small instance comfortably runs your project, you genuinely do not need Vapor. The case for it appears when one server is no longer enough and you would otherwise be setting up several instances, load balancing, and scaling them yourself. That is exactly the work Vapor hands to AWS Lambda, so you stay focused on your business logic while the platform handles scaling. For a simple app on one box, stick with the box.

"Serverless is hype, and I do not want to be locked in."

Two parts to this. On the hype: auto-scaling that you never manage, paying only for what runs, is a real and useful thing, not a fad. On lock-in: Vapor is unusually gentle here. Your app is still an ordinary Laravel app. If you ever want to go back to running on a normal server, you remove laravel/vapor-core from the project and deploy it the traditional way. You are not rewriting your application to escape; the serverless wiring is an add-on, not a rebuild.

"I do not need auto scaling, I am happy on one server."

Fair, if the app is not critical. But two things are worth weighing. Servers go down, so at the very least add uptime monitoring (something like Oh Dear) to warn you when yours does, so you can fix or replace it. Vapor's pitch is that you do not have to: a container is always available, and if one crashes another takes over. If availability matters and you do not want to babysit a server, that resilience is the draw even without dramatic scaling needs.

"Local development on serverless is hell."

This worry comes from the microservices style, where the app is split across many lambdas and running it locally is genuinely awkward. Vapor does not work that way. Your app stays a single normal Laravel codebase, so local development is exactly what you already do: Valet, Herd, or Docker, no special setup. And when you want to test against the same runtime Vapor uses on Lambda, the vapor test command runs your suite in that environment. The serverless part lives in deployment, not in your day-to-day coding.

So, should you?

A rough rule of thumb:

  • Stay on a server if a single small instance handles your app and you are comfortable maintaining it.
  • Consider Vapor when you need more than one instance, want automatic scaling and resilience without managing infrastructure, or value not thinking about servers at all.

Because the lock-in is so light, you can also start on a server and move to Vapor later (or the reverse) without a rewrite, which takes a lot of pressure off the decision.

Wrapping up

Vapor is not a no-brainer for tiny projects, and it does not need to be. Use a cheap server while one suffices; reach for Vapor when scaling, resilience, and never touching infrastructure become worth it. The lock-in is minimal (remove a package to go back), local development stays normal Laravel, and vapor test covers the runtime difference. Decide on your actual scaling and operational needs, not the hype.

More in the series: cost and performance optimisation and API Gateway vs load balancer. Questions welcome below.