- How do I install and configure bref/laravel-bridge for a Laravel app on AWS Lambda?
- Install it with Composer using composer require bref/laravel-bridge and follow the official Bref Laravel documentation for serverless.yml and deployment setup. The bridge registers the Lambda-aware bootstrapping, configuration, and logging integration your Laravel app needs. You should not need to rewrite a conventional Laravel HTTP app for Lambda. For queues and scheduled tasks, add the relevant Bref function events as described in the docs.
- Which Laravel and PHP versions does bref/laravel-bridge support?
- The bridge is intended for Laravel 10, 11, and 12 on Bref 3.0.13 or newer with PHP 8.1 through 8.4. It is the official integration path for Laravel on Bref 2.0 and later. Check the package constraints and Bref docs before upgrading an older app. PHP 8.4 support depends on the newer Bref core floor.
- What Bref version do I need for the latest bref/laravel-bridge release?
- Current releases require Bref core 3.0.13 or newer because earlier Bref versions missed uploads during cleanup on PHP 8.4+. If your app is on an older Bref 3.0.x release, plan to upgrade Bref core and the bridge together. This transitive floor means a bridge update can pull the runtime forward. Review both dependency trees before a routine Composer update.
- How does bref/laravel-bridge handle queues on AWS Lambda?
- It provides an SQS queue connector so Laravel queue workers can run as Lambda functions under Bref. You configure an SQS queue connection and deploy a Bref queue-worker function with the appropriate event source. This lets you process jobs without managing queue servers. Keep job payloads small and use S3 or another durable store for large files.
- Can I run Laravel scheduled tasks and Artisan commands with this bridge?
- Yes. The bridge includes Artisan and serverless workflow integration so scheduled tasks and console commands can run on Lambda through Bref. You define the schedule or command invocation in your serverless configuration. This is useful for cron-like Laravel schedules without an always-on server. Test time limits and memory settings because Lambda functions are bounded.
- How does storage work on Lambda's read-only filesystem with Laravel?
- AWS Lambda only allows writes to /tmp, and bref/laravel-bridge provides a writable-storage strategy that redirects Laravel storage there. It also includes an S3 filesystem adapter for durable storage. Do not treat /tmp as persistent across requests or instances. Use S3 for uploads, generated assets, and anything that must survive.
- Why are uploaded files deleted at the start of the next request after upgrading to 3.1.4?
- The 3.1.4 release fixes uploaded files accumulating in /tmp under Octane and Bref's HttpHandler until the instance fills and writes fail. Files uploaded with a request are now deleted at the start of the next request. This makes the unsafe pattern of capturing $file->getRealPath() and passing it to a queued or deferred job fail fast instead of leaking slowly. Process or move the file before the response, or store it durably first.
- Does bref/laravel-bridge work with Laravel Octane on Lambda?
- Yes, the bridge includes a Bref HttpHandler integration for Octane-style long-lived workers. The 3.1.4 upload cleanup specifically addresses file accumulation in that mode. If your app writes scratch files to /tmp, verify that cleanup scope and timing match your workload. For deferred processing, do not assume an uploaded file's /tmp path remains valid across requests.
- What is bref.request_context and why is it deprecated?
- bref.request_context was an option that injected an X-Request-ID header into Laravel's shared log context. API Gateway does not send that header, so it was inert under PHP-FPM. On Lambda, Bref's log formatter now prefixes each log line with the request ID instead. The option is deprecated and slated for removal in the next major release.
- Why are previously hidden failed-job exceptions now showing up in CloudWatch?
- In earlier versions, when a failed job could not be persisted, the storage error could overwrite the job's own exception, so the real failure was never logged or reported. The bridge now reports both errors. After upgrading, expect previously swallowed exceptions to appear in CloudWatch and error alerting. Treat this as corrected visibility rather than a new regression.