Vapor Cli Laravel Package

Technical Evaluation

Reframe the decision first. laravel/vapor-cli scores 32.4 and shows Dependents: 0 because it is not a library — it is an operator-facing control-plane client. There is no service provider, no config surface, no runtime footprint, and nothing composes against it. The TPM should therefore not evaluate this as "which packages do we adopt," but as "do we adopt Laravel Vapor as our deployment platform." The CLI is the on-ramp, not the product. Presenting it to a steering committee as a dependency decision will produce the wrong conversation and the wrong risk register.

Architecture fit. The correct architectural home is the deployment toolchain: developer workstations and CI runners, installed as composer require --dev laravel/vapor-cli with the vapor binary on PATH. It makes authenticated HTTP calls to Vapor's hosted API, which orchestrates AWS Lambda, API Gateway, SQS, RDS/Aurora, ElastiCache, CloudFront, and Route 53 on your behalf. The correct mental model is aws-cli or terraform, not a Laravel package. Because it never loads in a production request path, the entire class of concerns a TPM normally manages — autoload weight, transitive runtime risk, provider bootstrapping, version conflicts in the app's dependency graph — is absent. What replaces it is a smaller but sharper set: pipeline topology, credential custody, environment topology, cost model, and exit path.

Integration feasibility. Mechanically trivial, strategically conditional. Installation is one dev require; onboarding requires a Vapor API token, a vapor.yml manifest per project, a commercial Vapor team account, a linked AWS account, and Docker on the runner for vapor build. A pilot can be stood up in a day. The gating factors are non-technical: the README defers all operational documentation to docs.vapor.build, a paid-product site. That is an onboarding, training, and offboarding dependency that belongs in the risk register alongside the technical ones.

Technical risk.

• Vendor lock-in — high, and the dominant risk. The CLI is MIT, but its value is inseparable from the closed-source Vapor platform and AWS. No self-hosted fallback, no substitute API implementation, no community fork path. Accept this explicitly and in writing, not implicitly.
• Dependency churn — medium-high. The changelog is a ledger of ecosystem breakage: Symfony Console v8 support in 1.70.0 followed by a compatibility fix in 1.70.1; PSR-7 v3 request-method casing breaking the API in 1.70.5; Guzzle 7.15+ asset-upload failures in 1.70.3; php-8.0:al2 deprecation warnings in 1.61.0; sequential Laravel 11/12/13 and PHP 8.4/8.5 enablement. This is a thin shell over fast-moving PHP and AWS surfaces. Unpinned versions will break deploys at the worst possible moment, and each of these was a patch release — meaning breakage reached users before the fix did.
• Release provenance — low-medium. High patch velocity, a "last release" date of 2026-09-03 that should be verified as a genuine tag rather than a forward-dated or mirrored artifact, and no published API-contract stability guarantee.
• Maturity signal — low for a platform dependency. 318 stars, README/changelog/releases only, no formal LTS, no OSS support channel. Support flows entirely through the commercial subscription. That is acceptable for a paid product, but it must be matched by an actual contract, not a free-tier assumption.
• Blast radius — high if mishandled. The CLI is credential-bearing and can destroy infrastructure: environment:delete, domain:delete --force (added 1.65.3/1.63.0), database and network teardown, ElastiCache scaling (1.62.0). Misuse in CI is not a red build; it is downtime or data loss. Destructive verbs need guardrails before the first production environment exists, not after.

Key questions.

1. What SLA, per-environment and per-seat pricing, and support tier does the target Vapor plan include — and what is the projected monthly cost at our expected Lambda invocations, queue volume, and database size?
2. Is the Vapor API versioned, and does the CLI pin to a contract version, or does a CLI upgrade silently change API behavior?
3. How are API tokens scoped — can they be constrained per environment, per project, or read-only for non-deploy pipelines?
4. Which PHP/Laravel and AL2-vs-AL2023 image matrix is currently supported, and what is the deprecation cadence we must track?
5. What is the documented rollback and exit path? Can the same Docker image be deployed to ECS Fargate or Lambda directly if Vapor becomes uneconomic or unavailable?
6. What cold-start and concurrency profile do we get for our specific workload, and does it satisfy our latency SLOs?

Integration Approach

Stack fit. Vapor is the highest-fit option only if three conditions hold simultaneously: the application is Laravel 10+ on a currently supported PHP version; the workload is spiky, low-baseline, or queue-heavy enough that serverless economics beat reserved capacity; and the team has no existing deep investment in container orchestration it would be abandoning. If any of those fails, the honest recommendation is ECS/Fargate with a conventional Laravel container — same Dockerfile lineage, no vendor lock, and a materially simpler exit. A TPM should run this triage before sponsoring a pilot, because the most expensive outcome here is a partial migration to a platform that was never going to fit.

Migration path. Three-stage ladder, each with a decision gate:

1. Shadow (2-4 weeks). Deploy one non-critical internal service or a staging clone to a Vapor staging environment. No production traffic, no DNS cutover. Establish: does the build produce a working image, what is the cold-start profile, what does the manifest look like for our conventions.
2. Production pilot (4-8 weeks). One production workload with a rollback-ready parallel deployment behind Route 53 or CloudFront weighting. Explicit success criteria agreed in advance: p95 latency, error rate, cost per 1,000 requests versus current baseline, and deploy lead time.
3. Fleet (per service, gated). Only after the pilot's cost and latency data are in hand, and only for services that met the triage in "stack fit" above. Services that fail triage stay on the existing platform permanently — a mixed estate is a legitimate and often correct end state.

Compatibility. Pin the CLI to an exact version in composer.json (not a caret range) and rebuild the CI base image deliberately, on a schedule, as a reviewed change — the 1.70.x sequence demonstrates that a routine dependency bump can break asset uploads. Verify at pilot time: PHP and Laravel version support for the image you intend to ship, AL2023 versus AL2 base image status, and whether route caching behavior (deliberately changed in 1.57.0 to not run on build) matches your expectations. Note also that 1.60.0 added Pest support to vapor test and shifted vapor local to PHP 8.2 by default — reconcile local dev parity with that before developers form habits.

Sequencing. Order matters and is not negotiable:

1. Commercial agreement and support tier signed before technical work begins.
2. Secrets management designed: Vapor API token stored in the CI secret store, scoped per environment, rotated on a documented cadence, never on a developer laptop for shared accounts.
3. vapor.yml manifest authored and reviewed like code, in-repo, with destructive operations gated behind manual CI approval.
4. CLI version pinned; base image built and tagged.
5. Staging environment created, then the shadow deployment.
6. Production pilot with parallel-run rollback in place.
7. Runbook written from the pilot's actual incidents, then fleet rollout.

The single most common sequencing failure is starting at step 5. Every step before it is cheap; every step after it is expensive to retrofit.

Operational Impact

Maintenance. Low ongoing surface, but not zero. The CLI itself needs no patching beyond the deliberate base-image cycle, but the manifest, the pinned version, and the supported PHP/Laravel/image matrix all require a named owner and a quarterly review. Budget roughly 1-2 engineer-days per quarter for version tracking, plus the cost of a re-deploy whenever a CLI pin moves. The larger maintenance cost is conceptual: developers must learn vapor.yml semantics and the vapor command vocabulary in addition to, not instead of, the Laravel commands they already know.

Support. This is the sharpest operational constraint. There is no meaningful OSS support channel — no maintainer triage on issues, no community forum with vendor presence, no LTS branch. Everything routes through the paid Vapor subscription. Before pilot, confirm in writing: support hours and timezone coverage, the escalation path for a failed production deploy, and whether the plan's response time matches the internal SLO of the service being deployed. A 24-hour vendor response on a service with a 99.9% availability target is a mismatch worth discovering in contracting rather than in an outage.

Scaling. Genuine strength: Lambda concurrency, ElastiCache serverless scaling (1.62.0), and CloudFront are managed for you, and the CLI exposes the levers. The scaling caveats are the ones serverless always carries and that a TPM should surface early: cold starts on latency-sensitive endpoints, per-account Lambda concurrency quotas that become a shared ceiling across the whole fleet, and connection-pool pressure on RDS/Aurora from many short-lived execution contexts. The CLI will not tell you when you are near a quota; monitoring must be built independently of it.

Failure modes. Rank these and pre-write the response for each:

• Deploy fails mid-flight. Highest frequency. Mitigation: pinned CLI version, --debug flag (added 1.56.0) wired into CI for failed runs, and a documented revert-to-previous-deployment procedure rehearsed in the pilot.
• Asset upload failures. Observed with Guzzle 7.15+ in 1.70.3 — a dependency-drift failure that surfaces at deploy time. Mitigation: immutable base image containing the pinned CLI.
• API contract drift. Observed with PSR-7 v3 request-method casing in 1.70.5 — a failure mode where the vendor API and the CLI disagree on protocol details. Mitigation: same pin, plus a canary deploy to a disposable environment on any image change.
• Environment unhealthy after deploy. The CLI surfaces relevant logs (1.57.0), but detection and recovery are yours. Mitigation: external health checks and alerting independent of the CLI.
• Destructive command executed in error. Lowest frequency, catastrophic impact. Mitigation: manual approval gates on environment:delete and domain:delete, no production-scoped tokens on developer workstations, and the --force flag never used in automated pipelines.
• Vendor or account-level failure. Uninsurable by us. Only mitigation is the exit path: a container build artifact that runs outside Vapor, validated at least once before fleet rollout.

Ramp-up. Plan for two to three weeks before a mid-level Laravel developer is independently productive with the deploy workflow, and roughly twice that before anyone can debug a failed deployment unaided. The learning curve is not the CLI syntax — that is a day — it is the operational model: what vapor.yml controls, how environments differ from Laravel's .env conventions, why build and deploy are separate phases, and which commands are irreversible. Accelerants that work: promote the pilot's author to internal champion, write the runbook during the pilot rather than after, and have a second engineer drive a full deploy end-to-end in staging before production rights are granted. Do not let a single developer hold sole operational knowledge of the deploy path — the bus factor on a vendor-specific deployment toolchain is a real availability risk, and the vendor's support contract does not cover your team's knowledge concentration.