- How do I install bref/cli in a Laravel project?
- Install it as a Composer dev dependency, or use the standalone PHAR if you prefer not to touch composer.json. In most projects you never add it directly, because bref/bref pulls the CLI in as a dependency. Once installed, run bref init to scaffold the serverless.yml configuration and function layout.
- Does bref/cli support Laravel queues and scheduled tasks?
- Yes. Bref CLI has built-in support for Laravel queues and scheduled tasks, so queue workers and the scheduler can run as Lambda functions instead of long-lived processes. You declare those functions in serverless.yml, and the CLI builds and ships them alongside your HTTP handlers.
- Does bref/cli use the Serverless Framework or AWS SAM?
- Both. bref/cli is a Symfony Console application that shells out to the Serverless Framework or the AWS SAM CLI depending on how your project is configured. Feature parity is not guaranteed, though: for example, deploy parameters only work on the Serverless Framework path. Pick one driver deliberately, because every CLI feature added tends to assume Serverless first.
- What does bref deploy --param do?
- Added in version 1.3.4, bref deploy --param passes values straight through to the Serverless Framework's --param option at deploy time. That lets you inject per-environment values without templating serverless.yml or maintaining separate config files per stage. The change is purely additive with no breaking changes or runtime coupling, and it applies only to serverless.yml-based projects.
- Which PHP and Laravel versions does bref/cli support?
- The tooling assumes a PHP 8.x toolchain, and it is framework-agnostic but has first-class support for Laravel. Version coupling is the real constraint: bref/cli, bref/bref, the Lambda runtime layer (provided.al2 or provided.al2023), the PHP minor version, and your Serverless or SAM CLI must move together. Unpinned versions tend to fail at deploy time rather than build time, so pin deliberately and check your runtime deprecation horizon.
- How do I run and debug Lambda functions locally with bref?
- Use the bref binary to invoke functions locally through Docker, which reproduces the Lambda environment closely enough for handler-level debugging. You can also read function logs from the command line without opening the AWS console. Getting this working locally is usually fast; the surrounding IAM and stack configuration is the part that takes real time.
- Is bref/cli safe to run in a production CI/CD pipeline?
- It has low blast radius but high privilege. The CLI cannot crash production traffic directly, but it mutates CloudFormation stacks and holds AWS credentials that can, so treat it as a privileged CI component. Use least-privilege deploy roles, prefer OIDC identity federation over long-lived access keys, and gate production deploys behind manual approval.
- What infrastructure do I need before deploying with bref/cli?
- You need AWS credentials with deploy-role permissions, a PHP 8.x toolchain, and either the Serverless Framework (Node) or the AWS SAM CLI as the driver. Docker is required for local function invocation. Budget accordingly: wiring up the CLI is roughly a day, while IAM role design, stack naming, artifact retention, and CI identity federation is closer to a sprint.
- How is bref/cli different from bref/bref?
- bref/bref is the runtime and deployment layer that actually runs PHP inside AWS Lambda; bref/cli is the command surface you use to scaffold, build, deploy, and inspect functions. Because most teams install bref/bref, which pulls the CLI in transitively, bref/cli shows very low direct dependent counts. Read those numbers as a measurement artifact, not as evidence the tool is unused.
- Can I use bref/cli for non-Lambda deployments like ECS or EC2?
- No. bref/cli is the command surface for the Bref PHP-on-Lambda runtime, and its fit is near-zero for container, ECS, or EC2-based PHP deployments. It will not improve those architectures, so if AWS Lambda is not an actual requirement, evaluate other deployment tooling instead. Treat this package as first-party-coupled tooling rather than a general-purpose deployer.