Vapor Cli Laravel Package

Product Decisions This Supports

• Build vs. buy on deployment infrastructure. The CLI is the adoption surface for a commercial platform decision: do we run Laravel on AWS Lambda via Vapor, or do we own ECS/EKS/EC2, Forge, or another managed host? laravel/vapor-cli itself is free and MIT, but it is a client for a subscription-gated control plane — so the real decision is a recurring vendor spend plus AWS consumption versus internal platform headcount. Frame this as a buy decision with an explicit lock-in clause, not as "adding a dev dependency."
• Roadmap sequencing for operational maturity. Choosing the CLI commits us to a topology: vapor.yml manifests per project, environment-per-branch conventions, Docker-in-CI builds, and vendor-managed scaling of Lambda, SQS, RDS/Aurora, ElastiCache, and CloudFront. That is a multi-sprint migration if we have existing infrastructure-as-code. It should slot into the roadmap as an infrastructure initiative with a pilot, not as a story in a feature sprint.
• Feature scope unlocked (and foreclosed). Useful primitive set: serverless autoscaling, queue workers, managed Redis, database provisioning/scaling, CDN and vanity domains, scheduled tasks, team-scoped deploy commands. Forecloses: long-running processes beyond Lambda limits, persistent local disk assumptions, WebSockets without extra work, and any requirement to run on-prem or in a non-AWS cloud. Product teams must be told what shape of application this platform will not accommodate before they design around it.
• Time-to-market and release-cadence decisions. Because deploys become a repeatable CI command (vapor deploy), we can support faster release trains, per-PR ephemeral environments, and lower operational toil — that directly affects how aggressively the roadmap can be committed to. Conversely, the changelog shows frequent ecosystem breakage (Symfony Console v8 fixes in 1.70.0/1.70.1, PSR-7 v3 method casing in 1.70.5, Guzzle 7.15+ upload failures in 1.70.3). Budget for pinned versions and periodic upgrade work; do not assume "managed" means zero maintenance.
• Cost model inputs. Serverless pricing is traffic-shaped: cheap for spiky/low-average utilization, potentially expensive against steady high-throughput workloads. This is a genuine product-economics decision — it can change unit economics for a high-traffic product line versus a container fleet. Model per-environment and per-seat Vapor pricing plus AWS spend before committing a revenue-bearing product to it.
• Team topology and ownership. The CLI centralizes ops in the platform/DevOps function and reduces per-team infrastructure knowledge needed. That supports a "small platform team, many product teams" org design — and should be named as a benefit if that is the target operating model.
• Compliance and data-residency decisions. Running production on a closed-source vendor platform in our AWS account has specific answers for audits, DPAs, and incident response. This needs sign-off from security/legal, and it is a decision that is expensive to reverse — so it belongs in the gated review, not the tooling backlog.

When to Consider This Package

Adopt when most of the following hold:

• The stack is Laravel/PHP and will stay that way. This is a Laravel-shaped platform; the value proposition collapses for polyglot monorepos or services outside the framework.
• We are willing to run production on AWS Lambda under a paid vendor. No self-hosted fallback exists. If procurement cannot approve a recurring subscription plus AWS commitment, stop here.
• Traffic is spiky or low-average. Marketing sites, internal tools, seasonal peaks, early-stage products, and event-driven workloads are the sweet spot where "scale to zero / scale on demand" beats provisioned capacity.
• Operational headcount is the binding constraint. If we cannot staff on-call infrastructure work, outsourcing the AWS surface to the platform is a rational trade of money for focus.
• We already standardize on Laravel's tooling and conventions. Adoption friction is genuinely low — a dev Composer require, a token, a vapor.yml, and Docker on the runner. A pilot is a day; a service migration is weeks.
• A migration/exit path is defensible. The application still builds as a Docker image; if the same image can be redeployed to ECS or Lambda directly, lock-in is bounded and reversible.

Look elsewhere when:

• The organization is not on AWS, or has mandated another cloud, on-prem, or sovereign hosting. There is no substitute implementation of the Vapor API.
• Workloads are steady and high-throughput. Provisioned containers or reserved capacity will usually be cheaper and more predictable; serverless cold starts and concurrency ceilings become product problems.
• Requirements include long-running jobs, persistent local storage, custom daemons, or unusual runtime extensions that Lambda's execution model fights.
• Vendor-neutrality, open-source-only, or no-recurring-vendor-spend policies apply. MIT licensing on the CLI does not make the platform open source.
• We already have mature IaC (Terraform/Pulumi) and a platform team. The abstraction's main benefit — hiding AWS — is something we've already built, and adopting Vapor means giving up fine-grained control we value.
• Support expectations exceed what a 318-star, single-vendor tool provides. Support flows through the commercial subscription; there is no OSS community or formal LTS to lean on.
• Nobody owns the credential and destructive-command risk. This CLI can delete environments, domains, databases, and networks. Without scoped tokens, protected branches, and approval gates, do not put it in CI.

How to Pitch It (Stakeholders)

Executive summary. laravel/vapor-cli is the official command-line client for Laravel Vapor, a managed serverless hosting platform for Laravel on AWS Lambda. Adopting the CLI is straightforward — a dev-only dependency and a few CI commands — but it is the on-ramp to a commercial platform, and that is the decision worth approving. The platform trades money for operational capacity: we get autoscaling, managed queues, Redis, databases, CDN, and domains without building or staffing that layer, and we get repeatable, scriptable deploys with per-environment isolation. What we accept in exchange is vendor lock-in to a closed-source control plane, traffic-shaped costs that are attractive for spiky or low-average workloads and less attractive for sustained high throughput, and a real-but-bounded exit cost because the deployment artifact is still a standard Docker image.

For engineering. Low integration cost, real operational upside, and a short list of risks to manage rather than solve. Install as a composer require --dev, authenticate with a scoped API token, define vapor.yml, run vapor build and vapor deploy from CI. Nothing loads in production request paths, so there is no runtime coupling, no service provider, no autoload impact — treat it as deployment tooling alongside aws-cli or terraform. Two caveats: pin the CLI version and the PHP/Symfony/Guzzle matrix in the CI image, because the changelog shows a steady stream of upstream-compatibility fixes (Symfony Console v8, PSR-7 v3, Guzzle 7.15+, sequential Laravel 11/12/13 support); and treat every destructive command (environment:delete, domain:delete, database and network teardown) as production-privileged — scoped tokens, protected branches, no ad-hoc execution against production.

What we are asking for. Approval to run a bounded pilot (one non-revenue service, one sprint) with three deliverables: a cost comparison against our current hosting for a representative traffic profile, a written exit plan proving the same image can be redeployed without Vapor, and a security review of token scoping and the destructive-command guardrails. If those three come back clean, we proceed; if any fails, we have spent one sprint and lost nothing.