Cli Laravel Package

Product Decisions This Supports

• Build vs. buy for deployment tooling. bref/cli is the piece that decides between maintaining bespoke deploy scripts (raw CloudFormation, Serverless Framework configs, custom Makefiles) and adopting an opinionated vendor/bin/bref deploy path. It is the concrete artifact behind the "serverless Laravel" bet, so it belongs in any build/buy/assemble evaluation.
• Runtime and hosting roadmap. Choosing this CLI effectively selects AWS Lambda as the execution substrate. That commits the roadmap on cold starts, a 15-minute execution ceiling, ephemeral filesystem, and no long-lived websockets — decisions that ripple into queue design, session storage, and file uploads.
• Cost and scaling model. It enables the pay-per-request economics decision: viable for spiky, low-average-traffic products (internal tools, webhooks, multi-tenant SaaS with idle tenants) where always-on ECS/EC2 capacity is wasted spend.
• CI/CD architecture. Adding the CLI to a pipeline is a discrete, reversible decision — a dev dependency plus a deploy step — which makes it a good low-commitment spike to de-risk a larger serverless initiative. As of 1.3.4, bref deploy --param lets a single pipeline inject per-environment values (stage names, account IDs, feature-flagged resources) into serverless.yml without maintaining per-environment config forks — a real reduction in the cost of standing up a staging environment alongside production.
• Environment promotion strategy. Parameterized deploys make the dev → staging → prod path an explicit, versioned decision rather than a set of hand-edited YAML files. PMs can now ask for "the same artifact, different parameters" as a release requirement.
• Dependency and upgrade policy. Because the CLI is versioned separately from the parent Bref framework, PMs now need an explicit pinning and upgrade cadence decision rather than inheriting it from the main package. The 1.3.4 release is additive and non-breaking, which supports a low-risk "stay on latest minor" policy for now.
• Feature scoping for scheduled and async work. Lambda-native cron (EventBridge) and queue workers are first-class deploy targets here, which can replace self-managed worker fleets and unlock features that were previously too operationally expensive.

When to Consider This Package

Adopt when:

• The product is Laravel/PHP, traffic is bursty or low-average, and the team is small enough that not running servers is worth a real premium.
• You already run (or are actively evaluating) Bref on Lambda — the CLI is effectively mandatory tooling there, not an optional add-on.
• Your team has, or is willing to build, baseline AWS literacy: IAM roles, CloudFormation/SAM semantics, log and metric access.
• You can absorb cold-start latency in the user journey or mitigate it with provisioned concurrency.
• You need multiple environments deployed from one pipeline and want that expressed as deploy-time parameters rather than duplicated configuration (strengthened by --param in 1.3.4).

Look elsewhere when:

• Traffic is consistently high and steady — container or VM hosting will be cheaper and simpler.
• Workloads are long-running (large media processing, persistent sockets, heavy PDF/ETL jobs) or depend on a writable local filesystem.
• The team has no appetite for AWS account, IAM, and infrastructure-as-code ownership; a managed PaaS is the honest answer.
• You are already paying for Laravel Vapor and value the managed dashboard over open-source control — Vapor is the "buy" branch of this same decision.

Signal caveat worth stating plainly: 4 stars and 0 recorded dependents are weak adoption signals, but they are an artifact of the CLI being recently split out of the main bref/bref repository rather than evidence of an unproven tool. Do not read them as maturity; do read them as a reason to require a two-week proof of concept and to pin the version explicitly before committing.

Release cadence note: 1.3.4 is a single small, additive feature (--param) with no breaking changes or deprecations, which is consistent with a young but actively maintained 1.x line. That is a green light for a spike, not yet a green light for treating the CLI as a stable platform dependency without pinning.

How to Pitch It (Stakeholders)

To executives: This is open-source deployment tooling for running our Laravel application on AWS Lambda — no license fee, no per-application SaaS subscription, and we pay AWS only for what we actually consume. It removes a category of operational work (server patching, capacity planning, idle worker fleets) and lets us ship scheduled jobs and background processing without standing up new infrastructure. Because it generates standard AWS infrastructure under the hood, our exit cost is low and we are not locked into a proprietary platform. The latest release adds deploy-time parameters, which means one pipeline can promote the same build across staging and production instead of us maintaining separate configuration copies.

To engineering: composer require bref/cli --dev gives us a single deploy command that provisions functions, queues, cron schedules, and HTTP endpoints declaratively, works from any CI runner, and keeps environment configuration in version control. bref deploy --param (new in 1.3.4) covers serverless.yml-based apps, so per-environment values are injected at deploy time rather than committed as separate files. It is a small, isolated dependency we can pin, evaluate in a spike, and back out of without touching application code. The known constraints — cold starts, 15-minute execution limit, ephemeral disk, connection pooling via RDS Proxy — are documented and bounded, and we should validate them against our heaviest endpoints before rollout.