Laravel Bridge Laravel Package

Product Decisions This Supports

• Infrastructure strategy: "do we run Laravel on Lambda?" This package is the go/no-go enabler for that decision. It is the glue that makes a stock Laravel app operable in a serverless runtime — queue workers, scheduled tasks, CloudWatch logging, and Lambda request handling — without forking framework internals. If you're evaluating a move off EC2/ECS/Forge-managed boxes to reduce idle cost or ops headcount, this is the piece that determines whether "lift and shift" is a two-week spike or a six-month rewrite.
• Cost/roadmap trade-off on low-traffic or spiky workloads. Serverless Laravel is compelling for admin backends, internal tools, webhook receivers, and event-driven APIs where traffic is bursty or near-zero most of the day. This package lets you commit to Lambda for those surfaces while keeping the same Laravel codebase — one stack, two deployment targets — rather than maintaining a parallel app in a different framework.
• Build vs buy on queue/scheduler plumbing. The bridge's core value is the queue worker and scheduler integration: it turns Laravel's queue and console kernel into something that behaves correctly inside a 15-minute execution ceiling and a non-persistent process model. Building that yourself means owning visibility-timeout handling, worker lifecycle termination, and scheduler dispatch — ongoing maintenance with real production failure modes. Buying means accepting a thin third-party dependency in the critical path of your job processing. Release 3.1.4 strengthens the case for "buy": it fixes a /tmp exhaustion class of failure (uploaded files were never deleted under Octane/HttpHandler) that is genuinely hard to diagnose from CloudWatch alone — exactly the kind of operational bug you do not want to own.
• Risk review of serverless fitness assumptions. 3.1.4 is a reminder that the runtime itself, not just your application code, can hold hidden state. /tmp is a shared, finite resource across warm Lambda invocations; a file-upload feature that looked "stateless" from the app's perspective could fill it and take down Laravel's storage layer with it. Treat the serverless audit as covering the runtime bridge version as well as the app: pin a minimum bridge version in your platform baseline, not just in composer.json incidentally.
• Feature scoping: which Laravel features are "serverless-safe." Adopting this package is effectively a decision to audit and constrain the app: no long-running daemons, no local-disk assumptions, no in-process caches that assume a warm process, and session/cache moved to shared stores (DynamoDB/ElastiCache/S3). That audit output should feed directly into your technical roadmap and definition-of-done for new features. Any feature that accepts file uploads should be explicitly reviewed against /tmp consumption and cleanup behavior.
• Vendor and platform lock-in posture, plus upgrade cadence. Choosing this package couples your runtime to Bref and AWS Lambda. 3.1.4 raises the floor to Bref 3.0.13 (required for correct upload cleanup on PHP 8.4+), which means the bridge and Bref must now be upgraded as a pair. That's an acceptable bet for a product whose growth is uncertain, and a poor one for a workload with steady high throughput, heavy CPU, or strict latency SLOs where provisioned containers are cheaper and more predictable per-request. Budget a recurring "platform baseline" line item: bridge + Bref upgrades are not zero-effort once you're past the point where Bref is optional.
• Logging/observability roadmap. 3.1.4 deprecates the bref.request_context option — it injected X-Request-ID into shared log context, but API Gateway never sends that header, so it was a no-op on the PHP-FPM path. Bref's own log formatter now prefixes every line with the request ID. Practical consequence: request correlation in production improves for free, but any saved CloudWatch Insights queries, log-based alerts, or dashboards that assumed the old injected field should be reviewed. Schedule the removal (flagged for the next major) as a known deprecation, not a surprise.

When to Consider This Package

Adopt when all of the following hold:

• The application is already Laravel and the team wants to stay on Laravel — this is a preservation play, not a modernization play.
• Traffic is spiky, low-baseline, or event-driven (webhooks, queue consumers, scheduled batch jobs, internal tooling) so that per-request billing beats always-on instances.
• The app's feature set fits the serverless constraints: stateless requests, short-lived jobs, shared session/cache/storage backing, and no unbounded use of local ephemeral disk.
• The team is comfortable with AWS primitives (Lambda, SQS, EventBridge, CloudWatch, IAM) or willing to invest in them; Bref's abstractions are thin, and debugging happens in CloudWatch.
• Your job processing fits within Lambda's execution ceiling, or can be decomposed into chained short jobs.
• Version-compatibility note from this release: 3.1.4 requires Bref >= 3.0.13 — earlier Bref versions missed every upload during cleanup on PHP 8.4 and above, so the /tmp leak fix is only effective on 3.0.13+. If you're on PHP 8.4, this is the minimum viable pair; do not take the bridge bump without the Bref bump. (The 3.1.3 change — relaxing bref/monolog-bridge to permit 2.0 — still stands, so the 2.x monolog line remains supported.)

Look elsewhere when:

• You have sustained, high-volume traffic. Per-request billing plus cold starts will lose to containers on both cost and p99 latency.
• You run long-lived processes: Websockets, queue workers with multi-minute jobs, in-memory caches, or anything relying on process persistence.
• The team has no AWS operational capacity and no appetite to build it. The abstraction leak is real — production incidents surface as Lambda timeouts and CloudWatch log spelunking, not tail -f.
• You need a mature, first-party-supported integration path. This is a community package in the critical path; evaluate its release cadence and issue responsiveness against your risk tolerance before committing. Positive signal: 3.1.4 includes a first-time external contributor fix, and the maintainer is actively closing production-impacting bugs.
• Latency budgets are tight (sub-100ms p99) or you need predictable cold-start behavior for user-facing endpoints.
• You cannot adopt a paired bridge/Bref upgrade policy — the two are now version-coupled in a way that affects correctness, not just features.

How to Pitch It (Stakeholders)

To executives: This is the enabler for running our Laravel product on AWS's serverless platform. It means we can keep the codebase and team we have while moving to a pay-per-request cost model — the win is lower infrastructure spend on idle capacity and less operational overhead, not a rewrite. The trade-off to accept explicitly: we take on a small community-maintained dependency in the request path, and we commit to AWS Lambda for the workloads we migrate. Release 3.1.4 is a maintenance release but a valuable one — it fixes a defect where file uploads accumulated on the runtime's local disk until it filled and broke storage writes, i.e. a latent outage that would have been extremely hard to attribute. Recommend a bounded pilot on one low-risk surface (internal tooling or a webhook/queue consumer) with a cost and latency baseline, before any broader commitment, and fund a small recurring line item for keeping the bridge and Bref upgraded together.

To engineering: 3.1.4 is a low-risk patch with three changes worth knowing about. (1) Upload cleanup: files uploaded during a request are now deleted when the next request starts, under both Octane and Bref\LaravelBridge\Http\HttpHandler. Previously they accumulated in the instance's /tmp until it filled, at which point everything writing to /tmp failed — including Laravel's storage. This requires Bref >= 3.0.13; older Bref skipped uploads during cleanup on PHP 8.4+. Bump both together. (2) Failed-job reporting: when a failed job could not itself be persisted (e.g. the database-uuids driver on an app with no DB), the storage error replaced the job's original exception, which was silently lost. Both are now reported — a quiet but important observability fix if you're on database-uuids. (3) Deprecation: bref.request_context is deprecated and will be removed in the next major. It set X-Request-ID in shared log context, but API Gateway doesn't send that header, so it was a no-op under PHP-FPM; Bref's log formatter now prefixes each line with the request ID instead. Action: bump bridge and Bref, run the suite, verify CloudWatch log formatting and any Insights queries/alerts that referenced the old context field, and confirm upload-heavy flows behave on a warm instance. No breaking changes. Strategically, this package is what lets us deploy Laravel to Lambda without hand-rolling queue-worker lifecycle and scheduler dispatch — the parts that break silently in production. It does not remove the need to audit the app for serverless fitness: statelessness, shared session/cache/storage, job duration limits, and bounded ephemeral-disk usage all remain our responsibility.