Updated June 2026. Concepts tested against Laravel 13 and current Vapor. Part of the Techalyst Vapor series.

Laravel Vapor is a serverless deployment platform for Laravel, powered by AWS Lambda. The clever engineering is in how Vapor maps a normal Laravel app onto serverless infrastructure, but to appreciate that you first need to understand what "serverless" actually means.

The idea behind serverless

Look at the public/index.php of any Laravel app and you find the heart of it.

$response = $kernel->handle(
    $request = Illuminate\Http\Request::capture()
);

$response->send();

A request comes in, handle() turns it into a response. Normally you run this on a server that sits there waiting for requests, and you pay for that server whether it is busy or idle, say five dollars a month for a small droplet.

Now imagine you could upload just that handle() step to a service, and only pay when it actually runs. No provisioning a server, no patching libraries, no managing storage. Upload the function, pay per execution. That is serverless in a sentence.

AWS Lambda is Amazon's Function as a Service. You give it a function, and it runs that function only when something invokes it. Lambda is the engine Vapor runs your Laravel app on.

The usual serverless headache: microservices

Lambda is traditionally used in a microservices style, where each function does exactly one job.

  • Upload an image to S3, a lambda generates a thumbnail.
  • Push a job to a queue, a lambda processes it.
  • A schedule fires, a lambda runs.
  • An HTTP request arrives, a lambda generates the response.

Done this way, you split your app into many separate functions, each its own codebase, and you wire them together yourself: this event runs that lambda, that endpoint runs this one. Powerful, but the "wiring" is a lot of extra complexity.

What Vapor does differently

Vapor takes your whole Laravel codebase and turns it into a single function. Depending on the event that triggers it, Vapor runs the right part of your app, and does all the wiring for you.

  • A request to /api/products is handed to the Laravel router, and the response comes back.
  • A job lands on SQS, and Vapor marshals it to a worker to process.

So you get the benefits of serverless without changing how you write Laravel. You still build a normal app; Vapor handles converting it to run on Lambda.

Two lambdas: HTTP and CLI

To let you tune HTTP and command-line workloads separately, Vapor creates two identical lambdas from your one codebase.

  • The HTTP lambda serves web requests. You configure its memory, timeout, and concurrency limit. It is invoked through API Gateway or an Application Load Balancer (which to use is its own decision).
  • The CLI lambda runs artisan commands, queued jobs, and scheduled tasks, with its own memory, timeout, and concurrency settings.

How the pieces connect:

  • Queues: Vapor points your app at SQS, and the CLI lambda is invoked whenever a job is waiting.
  • Scheduling: Vapor creates a CloudWatch/EventBridge rule that fires every minute and invokes the CLI lambda with php artisan schedule:run.
  • Ad-hoc commands: vapor command invokes the CLI lambda to run a specific artisan command.

Wrapping up

Serverless means uploading your code as a function and paying only when it runs, with AWS Lambda as the engine. Instead of forcing you into a tangle of single-purpose microservices, Vapor converts your entire Laravel app into HTTP and CLI lambdas, wires them to API Gateway, SQS and EventBridge for you, and lets you keep writing Laravel exactly as you always have. vapor deploy production and your app is live, no servers to manage.

Next in the series: cost and performance optimisation in Vapor and should you use Vapor. Questions welcome below.