Vapor Core Laravel Package

Technical Evaluation

Architecture fit

laravel/vapor-core is not an application-level library. It is the kernel plus invocation handlers that translate AWS Lambda event payloads (API Gateway v1/v2, SQS, CLI) into Laravel HTTP and console requests, and translate Laravel responses back into Lambda-shaped returns. It sits between the Lambda runtime and the framework, ships inside the deployment artifact, and is auto-discovered — there is no manual wiring.

The fit question for a TPM is therefore not "should we add this package" but "is serverless Laravel a product requirement." If the answer is yes (bursty or unpredictable traffic, per-request cost model, no desire to run a fleet), this is a mandatory, load-bearing component. If the answer is no, the package offers near-zero leverage. Note the v2.43.4 change that skips service-provider registration on Laravel Cloud: Laravel is deliberately hedging across hosting products, so code that runs under Vapor is increasingly portable to Laravel Cloud without rewrite. That materially reduces the "we're locked in" objection.

Integration feasibility

Integration effort is effectively zero at the package level — Composer resolves it, Vapor's build injects it, auto-discovery registers it. All real effort sits in making the application stateless: no local filesystem writes, sessions/cache on Redis or DynamoDB, assets on S3/CloudFront, queue workers on SQS, and database connections that survive container reuse. Budget engineering time for the app, not the dependency.

Technical risk

• Thin translation layer with high edge-case density. The changelog reads as a history of subtle production bugs: multi-value cookies (v2.44.0), Octane cookies (v2.37.8), multipart multidimensional arrays (v2.37.9), raw query strings shipped, reverted, and re-shipped within a single release (v2.46.0). These are fixed quickly, but each represents a class of incident your QA will not catch locally.
• Container reuse semantics. Scoped instance resets between jobs (v2.37.2) and MySQL wait_timeout recovery (v2.43.3) are exactly the failure modes that make serverless risky. State bleeding across invocations is the archetypal bug in this architecture.
• Compatibility treadmill. The package must track Laravel 10–13, PHP 8.4 deprecations, Symfony 8, and Guzzle 8 — and is doing so. The risk is the lag window: your Laravel major upgrade is gated on a matching runtime release.
• Commercial platform dependency. Code is MIT; the platform is a paid Laravel product with no package-level SLA.
• Metrics are misleading. 414 stars and 0 listed dependents reflect direct adoption, not usage — this is a transitive dependency. Judge it on changelog velocity and core-team authorship (Nuno Maduro, Tim MacDonald, Mohamed Said), which are strong.

Key questions

1. Is serverless a product requirement or an infrastructure preference? What does it buy us in cost or time-to-scale?
2. What is our cold-start budget per route, and which endpoints cannot tolerate p99 inflation?
3. Which of our dependencies assume FPM, a persistent filesystem, or long-lived processes?
4. Vapor vs Laravel Cloud vs Forge/k8s — how reversible is the decision, and what is the exit cost in engineer-weeks?
5. Who owns the AWS account, IAM, VPC, and the Vapor subscription line item?
6. Do we have a rollback path to FPM hosting that does not require re-architecture?

Integration Approach

Stack fit

PHP 8.x with Laravel 10–13, Composer, Vapor CLI, a vapor.yml, and a linked AWS account. The package is compatible with FPM as well as Lambda (see v2.31.1, v2.32.2), which is the single most useful de-risking property here: you can install and run dual-mode before committing.

Migration path

Greenfield is trivial. Brownfield should be sequenced, not big-banged: pick one stateless service or a read-heavy API surface, put it on Vapor, keep the primary application on FPM, and migrate queue workers and the scheduler separately once the web tier is stable.

Compatibility

Treat the changelog as the compatibility matrix. Pin the runtime minor to your framework support window, and add an explicit gate in the Laravel-major upgrade checklist. Verify Symfony, Guzzle, and PHP minor alignment (v2.43.5, v2.47.0, v2.37.10) before scheduling the upgrade.

Sequencing

1. Harden for statelessness: storage to S3, session/cache to Redis, config/route caching, no local writes, no in-process state.
2. Move the data tier: RDS Proxy or serverless Aurora, ElastiCache Serverless (supported from v2.35.0).
3. Wire queues to SQS, including custom Lambda events (v2.41.0) and overflow handling (v2.45.0).
4. Normalize sub-minute schedules via the proxy command (v2.34.0).
5. Instrument: Lambda execution context logging (v2.42.0) and request-timestamp server variables (v2.39.0) before you need them in an incident.
6. Cut CloudFront and DNS last — it is the least reversible step.

Operational Impact

Maintenance

Code maintenance is low: Dependabot-managed, frequent patch releases, no forking expected. Environment maintenance is high: AWS account, IAM, VPC, RDS, CloudFront, secrets rotation, and the Vapor subscription itself. Total cost of ownership lives in the environment, not the package.

Support

MIT, community-supported, no SLA on the package. The paid escalation path is the Vapor subscription. Fix turnaround is fast and core-team involvement is a genuine quality signal, but self-supporting a fork is not a realistic option — plan on the commercial relationship.

Scaling

This is the package's core value: Lambda concurrency scales the web tier without capacity planning. But scaling moves the bottleneck rather than removing it — the database connection pool becomes the constraint (hence RDS Proxy and the wait_timeout patch), SQS becomes the throughput governor, and Lambda concurrency quotas become an AWS conversation. Cold-start latency scales with artifact size and boot time, making container size a product decision (feature scope, package count), not just an engineering one.

Failure modes

Cold-start tails inflating p99 against API Gateway's 29-second ceiling; state bleed between invocations; DB connection exhaustion and "server has gone away"; Lambda timeouts on long-running requests and large uploads; and event-shape edge cases in the API Gateway translation layer, which have historically shipped, been reverted, and re-shipped. Each deserves a named runbook entry and an alert before launch, not after.

Ramp-up

Engineers fluent in Laravel need roughly one to two weeks to become productive on Vapor; the learning curve is AWS-shaped, not Laravel-shaped. Budget a named platform owner (0.25–0.5 FTE) for the AWS/Vapor estate, and run a two-to-three week pilot on a non-critical service before committing roadmap capacity.