Vapor Core Laravel Package

Product Decisions This Supports

• Build vs. buy on Laravel hosting. This package is the runtime layer that lets a Laravel app boot inside AWS Lambda. It doesn't answer "should we use serverless" on its own, but it defines the size of the lock-in if you pick Vapor: request/response translation from API Gateway, SQS queue consumption, scheduled task normalization, Octane/streamed responses, ElastiCache/Redis, RDS certificates, S3/S3-compatible storage, CloudFront. The decision it informs is Vapor vs. Forge vs. Laravel Cloud vs. containers, not "should we install this."
• Feature feasibility for a serverless deployment. If you're evaluating whether a queue-heavy, cron-driven, or file-heavy feature can run on Lambda, the changelog is the evidence base: SQS overflow support, custom Lambda events from SQS, sub-minute schedule normalization via a scheduler proxy, scoped-instance resets between jobs. Those are the exact seams where serverless usually breaks a Laravel app.
• Framework upgrade timing. Laravel 11, 12, and 13 support, PHP 8.4 deprecation fixes, Symfony 8 and Guzzle 8 allowances all land here first. If you're on Vapor, this package is a gating dependency in your upgrade plan and should be on the same tracking board as the framework bump.
• Observability and environment branching. Recent work exposes AWS Lambda execution context for logging, API Gateway request timestamps, and the raw query string as a server variable, plus helpers to detect "am I running on Vapor." That directly supports decisions about environment-conditional code and log correlation across Lambda invocations.
• Platform strategy signal. The package explicitly skips its service provider registration on Laravel Cloud. That's a useful data point for a roadmap conversation about which Laravel-owned platform the company standardizes on — the two runtimes are diverging by design.
• What it should not drive. No product differentiator, no customer-facing capability. It is plumbing. Don't let it appear on a roadmap as an initiative; it belongs in the infrastructure and vendor-risk register.

When to Consider This Package

• You are deploying on Laravel Vapor. That's essentially the whole criterion. In the normal path you never composer require this deliberately — it ships as part of the Vapor runtime and is pulled in transitively. Direct adoption only makes sense if you're writing custom Lambda handlers, running the Vapor runtime outside Vapor (self-hosted or local parity testing), or building a Lambda-compatible platform of your own.
• You need Lambda-specific request semantics. Multi-value cookies, multidimensional multipart parsing, raw query string handling, GET-with-body safety, and Octane streamed-response fixes are concrete reasons someone would look at this code rather than reimplement it.
• You need queue semantics that survive Lambda's execution model. Resetting scoped instances between invocations, SQS overflow, and custom event payloads are non-obvious problems this package has already solved.
• Look elsewhere when: you're on Laravel Cloud (this package deliberately no-ops there), Forge/EC2, Kubernetes, or any non-AWS host; when AWS Lambda vendor lock-in or the Vapor subscription cost is a blocker; or when your team cannot absorb Vapor-specific operational knowledge (cold starts, concurrency limits, log shipping).
• Caveat on signals. 414 stars and 0 dependents is normal for a transitive runtime shim but does mean thin community documentation — the source of truth is docs.vapor.build, not the repo. There is no "evaluate it on its own merits" story here; it's only as good as the platform it serves.

How to Pitch It (Stakeholders)

To executives: This is not a product we adopt — it's the runtime component of Laravel Vapor, the paid serverless platform. So the framing is: "Do we want to run Laravel on serverless AWS?" If yes, this comes with the platform at no license cost (MIT); the spend is the Vapor subscription plus AWS consumption, and the return is autoscaling and zero server management. If we're not choosing Vapor, this package is irrelevant to us.

To engineering: It handles the unglamorous but load-bearing parts of running Laravel on Lambda — API Gateway request/response mapping, multi-value cookies, multipart parsing, raw query strings, SQS job dispatch with scoped-instance resets, sub-minute schedule normalization, RDS certificate handling, MySQL connection recovery, and Lambda execution context in logs. It's maintained by Laravel core contributors, with Dependabot hygiene, SHA-pinned CI, and current Laravel 13 / Symfony 8 / Guzzle 8 readiness — the maintenance signal is strong.

Risks to state up front: tight coupling to AWS Lambda and the Vapor platform; low standalone visibility and thin external docs; a support surface that runs through Vapor rather than the open-source repo; and mandatory version alignment with Laravel releases. Recommendation: treat it as infrastructure, do not fork or patch it locally, pin and track releases, and make "Vapor runtime compatible" an explicit acceptance criterion in every framework upgrade ticket.