vapor-core

Laravel Vapor Core is the runtime backbone of Laravel Vapor, the auto-scaling serverless deployment platform for Laravel powered by AWS Lambda. It bundles the service providers and Lambda runtime clients that let a standard Laravel application boot, serve HTTP requests, process queued jobs, and run scheduled tasks inside Lambda functions without changing how you write your app.

Installed as a Composer dependency, the package auto-registers a Laravel service provider that wires up SQS queue handling, Redis and DynamoDB configuration, signed storage URLs, static asset serving, and both FPM and Laravel Octane runtimes. It abstracts the low-level details of translating Lambda invocation events into Laravel HTTP kernels and job workers so applications behave the same locally and in production.

What You Get

• A Laravel service provider that auto-registers Vapor’s queue connector, storage, and runtime configuration with zero manual wiring
• Lambda runtime handlers for PHP-FPM and Laravel Octane, including load-balanced variants for HTTP invocations
• An SQS-backed queue connection, worker, and failed-job commands for processing background jobs on Lambda
• Runtime helpers for secrets, environment loading, storage directories, and CloudFront/asset serving
• Console commands for scheduling, health checks, and Octane status inside the serverless environment

Common Use Cases

• Deploying an existing Laravel app to AWS Lambda through Laravel Vapor without rewriting application code
• Processing SQS-driven queued jobs and scheduled tasks in a serverless runtime
• Serving high-traffic HTTP workloads that need to auto-scale on Lambda with FPM or Octane

Under The Hood

Architecture Vapor Core is organized around a VaporServiceProvider that composes several configuration traits (ConfiguresQueue, ConfiguresSqs, ConfiguresRedis, ConfiguresDynamoDb, ConfiguresAssets, DefinesRoutes) to wire a Laravel app for serverless execution during boot. At the runtime layer, src/Runtime/LambdaRuntime polls the AWS Lambda Runtime API via LambdaInvocation and dispatches each event through a callable handler, notifying Lambda of the response or error. Dedicated handlers under src/Runtime/Handlers (OctaneHandler, LoadBalancedFpmHandler, QueueHandler, WarmerHandler, WarmerPingHandler) translate invocation payloads into HTTP kernel calls, queued jobs, or warmer pings, while src/Runtime/Fpm and src/Runtime/Octane implement the two supported PHP execution models.

Tech Stack Written in PHP (supporting 7.2 through 8.x), the package builds on Illuminate components (container, http, queue, support) spanning Laravel 6 to 13. It depends on aws/aws-sdk-php for AWS integration, Guzzle and guzzlehttp/promises for HTTP, nyholm/psr7 and symfony/psr-http-message-bridge for PSR-7 interop, hollodotme/fast-cgi-client to talk to PHP-FPM, riverline/multipart-parser for request bodies, symfony/process for process control, and Monolog for logging. Dev tooling includes PHPUnit, PHPStan, Mockery, Orchestra Testbench, and StyleCI.

Code Quality The codebase is maintained by the core Laravel team and follows Laravel conventions with consistent PSR-4 namespacing under Laravel\Vapor. It ships a test suite of roughly 25 PHPUnit files split across Unit and Feature suites (covering the FPM request builder, HTTP kernel, queue connector, Octane handler factory, and console commands), a phpstan.neon.dist for static analysis, and StyleCI configuration for style enforcement. Runtime error handling is explicit - LambdaRuntime catches throwables per invocation, reports them to the Lambda error endpoint, and exits cleanly.

API Design Most of the package is framework-facing rather than a public developer API: the service provider and runtime handlers are registered automatically, so end users typically write ordinary Laravel code and never call Vapor internals directly. The public surface that does exist - the Vapor facade, console commands, and the SQS queue connection - follows Laravel’s own naming and ergonomics, keeping boilerplate near zero. Direct usage guidance lives in the external Vapor documentation rather than in-repo examples, which is appropriate given it is consumed through the managed Vapor platform.