Laravel Bridge Laravel Package

Technical Evaluation

What this package is: roadrunner-php/laravel-bridge is the official integration layer between Laravel and RoadRunner (a Go-based PHP application server), plus optional Temporal workflow support. It replaces the php-fpm request lifecycle with long-lived PHP workers and supplies Laravel-native adapters for RoadRunner's queue (jobs), KV cache store, and gRPC/HTTP worker modes. Release 6.6.2 is a patch release: seven bug fixes, a docs refresh, and a PHPStan-max refactor. No declared breaking changes.

Architecture fit: Strong fit where the driver is throughput, latency, or durability of long-running work — high-RPS APIs, queue-heavy workloads, and services that need durable orchestration (Temporal). Poor fit for teams unwilling to own worker-lifecycle semantics: the application must be safe in a persistent-process model (no leaked singletons, no per-request globals, no assumptions about process isolation), and the runtime is no longer a stock php-fpm container. This is an infrastructure decision as much as a library decision.

Integration feasibility: Composer-installable with Laravel package auto-discovery; configuration is split between Laravel config and RoadRunner's .rr.yaml, and requires the RoadRunner Go binary in the deployment image. Feasible in a sprint for a small service; 4–8 weeks end-to-end for a production service including load testing, runbook work, and rollback rehearsal. The Temporal path is materially more work and should be treated as a separate initiative.

Technical risk (informed by 6.6.2):

• Moderate — queue timing semantics. release() delay is now correctly converted to seconds. Any code that compensated for the previous (incorrect) unit will silently change retry cadence. This is a fix, but it is a behavioral change on a patch version.
• Moderate — silent defaults. WorkerOptions::$maxTries === null now falls back to 10. Jobs that previously ran with an unbounded/unknown try count will now stop after 10 attempts. Confirm this matches your intended policy before upgrading.
• Low–moderate — retry/backoff correctness. Array $backoff is now honored on failed-job release, and failing jobs without an exception are handled. Both improve reliability but change retry timing and failure classification versus prior behavior.
• Low — cache correctness. Remaining TTL is preserved on increment/decrement. Previously counters could lose or reset TTL; any alerting or expiry logic built around the old behavior should be re-validated.
• Low — Temporal error propagation. Failed activities now rethrow exceptions instead of swallowing them, which will surface errors that were previously invisible. Expect a transient increase in alert volume after upgrade.
• Low — payload tolerance. Non-object task payloads no longer break job deserialization.
• Positive — quality signal. PHPStan at max level and a README/installation refresh indicate active maintenance and reduced onboarding friction.

Key questions:

1. Which Laravel and PHP versions does the 6.6.x line officially support, and are we inside that matrix?
2. Is the existing codebase worker-safe (singletons, static state, request-scoped assumptions, in-memory registries)?
3. Do we rely on unbounded job retries or on the previous delay unit behavior anywhere in application code or config?
4. Is Temporal in scope now, or is this purely an HTTP/queue performance play?
5. What is the rollback story — can we run php-fpm behind the same load balancer as a fallback?
6. Who owns the RoadRunner binary version, .rr.yaml, and worker sizing as a standing operational responsibility?

Integration Approach

Stack fit: Targets Laravel applications running PHP 8.2+ who want an alternative to php-fpm + Nginx and, optionally, a Redis-free queue/cache path. Best value where the app already leans on Laravel queues or where Temporal-style durable workflows are on the roadmap. Low value for small, low-traffic apps — the operational surface outweighs the performance win.

Migration path:

1. Pin 6.6.2 explicitly; do not float ^6.6.
2. Start with the queue worker only, keeping php-fpm for HTTP. This isolates worker-safety risk to background jobs.
3. Move HTTP traffic to RoadRunner for one non-critical service behind a load balancer, with php-fpm retained as a hot standby.
4. Only then evaluate the KV cache store and Temporal adapters, each as its own change.

Compatibility: Verify the Laravel/PHP support matrix in composer.json rather than the README. Audit for php-fpm assumptions: $_SERVER/$_ENV mutations, static caches, container singletons holding request state, register_shutdown_function usage, and filesystem-based session/cache drivers. Note that Horizon is Redis-specific and does not manage RoadRunner queues — if Horizon is central to your operations tooling, that is a gap to plan for. Third-party packages that assume process-per-request are the most common source of surprises.

Sequencing:

1. Dependency pin + changelog review (0.5 day).
2. Staging deploy; explicitly test cache increment/decrement TTL, job delay in seconds, array backoff, max-tries-at-10, and Temporal activity failure paths (2–3 days).
3. Worker-safety code audit and fixes (1–2 weeks).
4. Load test with realistic concurrency and memory ceilings (1 week).
5. Canary at low traffic percentage; compare p95 latency, error rate, and memory growth over 72 hours.
6. Full cutover with documented rollback to php-fpm.

Operational Impact

Maintenance: Active release cadence with small, focused patch releases — good for security and correctness, but it means behavior can shift on patch versions (as 6.6.2 shows). Pin versions, subscribe to releases, and treat upgrades as small change-managed events rather than routine composer update noise. Budget roughly one engineer-day per quarter for upgrades and validation.

Support: Community-supported open source with a small maintainer pool — bus-factor risk is real. No vendor SLA unless procured separately. Mitigate by keeping the integration surface thin (don't build custom drivers on top of internals) and by documenting your .rr.yaml and worker configuration in-repo so it isn't tribal knowledge.

Scaling: Scales horizontally by adding worker processes/containers; the Go server handles connection management and balancing. The binding constraint shifts from CPU-per-request to per-worker memory ceiling and worker count. Size workers against peak memory with headroom, set explicit max_jobs/memory limits to force recycling, and load test with the real payload distribution rather than synthetic pings.

Failure modes to instrument:

• Worker memory growth and OOM kills; recycle thresholds as the primary control.
• State bleed between requests (wrong user data, stale auth) — the highest-severity failure class and hardest to detect; needs targeted integration tests, not just monitoring.
• Job retry storms or silent job exhaustion after the new 10-try default.
• Cache TTL drift on counters affecting rate limiting or expiry-based logic.
• Temporal activity failures now surfacing as exceptions — expect alert noise post-upgrade, then tune.
• RoadRunner binary/app version skew during partial rollouts.

Ramp-up: Moderate to high. Expect 2–4 weeks before a mid-level engineer is productive and 1–2 months before the team can debug worker-lifecycle issues unaided. Required knowledge: RoadRunner worker model and .rr.yaml, Laravel container lifecycle in long-lived processes, queue retry/backoff semantics, and — if used — Temporal workflow/activity concepts. Front-load a short internal walkthrough and a one-page runbook covering restart, memory alerts, and rollback.

Recommendation: Adopt 6.6.2 for new or queue-heavy Laravel services where worker-safety can be audited up front. Treat the delay-unit and max-tries changes as behavioral, not cosmetic — validate both in staging before production. Defer the Temporal integration until the HTTP/queue path is stable in production.