Laravel Bridge Laravel Package

Product Decisions This Supports

Baseline established at v6.6.2. No prior assessment existed; this release is the reference point for future reviews. It is a patch release with no breaking changes, so it can be adopted as a routine dependency bump.

• Runtime strategy (build vs. buy). roadrunner-php/laravel-bridge is the integration layer that lets a Laravel app run under the RoadRunner application server (Go-based worker runtime) instead of PHP-FPM. The decision it unblocks is whether to move to worker-mode execution for lower per-request bootstrap cost and higher throughput per core. Buying this bridge is materially cheaper than maintaining in-house worker glue.
• Queue reliability is now a supported claim, not an assumption. Four of the six fixes land in the job/worker path: release() delay now converts to seconds correctly, array $backoff values are honored on failed-job release, maxTries falls back to 10 when null, and a failing job without an exception no longer breaks the handler. These are exactly the paths that produce "job retried at the wrong time" or "job lost" incidents. If retry/backoff semantics appear in customer-facing SLAs or in our error-budget targets, this patch measurably reduces that risk.
• Cache counter correctness. Preserving remaining TTL on increment/decrement matters for anything built on atomic counters with expiry: rate limiters, quota windows, inventory holds, per-tenant throttles. Previously these could silently become permanent keys. If our roadmap includes rate limiting or usage metering, this removes a workaround we would otherwise have had to build.
• Durable workflow roadmap. The Temporal fix (rethrowing exceptions from failed activities) is a prerequisite for trustworthy saga/compensation patterns. It makes Temporal a more credible option for multi-step business processes (order fulfillment, onboarding, billing runs) than it was one patch ago.
• Operational maturity signal. Passing PHPStan at max level plus a README/install refresh indicates the maintainers are investing in maintainability and onboarding, which lowers the "bus factor" concern in a build-vs-buy comparison.

When to Consider This Package

Adopt when:

• Laravel is the application framework and PHP-FPM or a single-process queue worker is a proven throughput or latency ceiling.
• You are already running, or willing to run, the RoadRunner binary — i.e., you have container/orchestration capability and can own a non-PHP process alongside the app.
• Queue throughput, retry/backoff fidelity, and delayed jobs are business-critical (payments, notifications, webhooks, provisioning).
• You want durable, multi-step workflow orchestration (Temporal) without leaving the Laravel programming model.
• You need cache-backed rate limiting or metering where counter TTL semantics must be correct.
• You can pin to a patch version and accept a community-maintained dependency with active, frequent releases.

Look elsewhere or defer when:

• Hosting is shared/managed PHP with no ability to run a sidecar binary or custom supervisor config.
• The team has no appetite for operating a Go runtime; Laravel Octane or Swoole may meet the same performance goal with a smaller operational delta.
• You require a commercial SLA, vendor indemnity, or a support contract.
• Roadmap depends on Laravel features the bridge does not yet cover — validate the specific integrations you need against current docs before committing, since bridge coverage lags core Laravel by design.
• The performance win is unquantified. If a load test has not shown PHP-FPM as the bottleneck, adopting a second runtime adds cost without a matching return.

Version guidance: take 6.6.x as a patch upgrade; no code changes or migration steps are required. Regression-test only the retry/backoff and cache-counter paths in staging, since that is where behavior changed.

How to Pitch It (Stakeholders)

For executives: This is the small, well-maintained piece of plumbing that lets our Laravel application run on a faster worker-based runtime. The release is a maintenance patch — no new features, no breaking changes, no migration work. Its value is risk reduction: it fixes six bugs in job retries, delayed job scheduling, cache counter expiry, and workflow error handling, all of which are the kinds of defects that surface as intermittent production incidents rather than clean failures. Cost to adopt is effectively a version bump plus a focused staging check. Recommendation: adopt the patch, and treat "move Laravel to worker-mode runtime" as a de-risked option for the next capacity-planning cycle rather than an open research question.

For engineering: 6.6.2 contains six fixes, concentrated in RoadRunnerJob and worker options — release() delay unit conversion, array $backoff on failed-job release, maxTries null fallback (now 10), exception-less job failure handling, non-object task payload tolerance, and remaining-TTL preservation on cache increment/decrement. Temporal failed activities now rethrow exceptions. The codebase also now passes PHPStan at max level and the README/installation docs were refreshed. No API changes; upgrade is a lockfile bump. Ask: add regression coverage for retry/backoff timing and counter TTL, and run one staging pass on the queue workers before rollout.