Roadrunner Bridge Laravel Package

Product Decisions This Supports

• Enables scaling Laravel applications without framework rewrites by leveraging RoadRunner's persistent worker model
• Supports build vs buy: avoids custom server integration work while using battle-tested RoadRunner architecture
• Critical for high-traffic APIs where per-request PHP bootstrap overhead causes latency spikes
• Aligns with roadmap for infrastructure optimization in real-time or microservice architectures
• Reduces cloud costs by handling 2-3x more requests per server instance compared to traditional PHP-FPM
• v4.0.0 does not change this calculus: the release is maintenance and correctness work (logging levels, log normalization, graceful EXIT command handling, removal of deprecated code) — no new capabilities to re-plan around. Treat it as an upgrade-hygiene item, not a roadmap input.

When to Consider This Package

• ✅ When your Laravel app handles >100 RPS and experiences >100ms bootstrap overhead per request
• ✅ When infrastructure costs are rising due to vertical scaling needs for API workloads
• ✅ When your team has operational capacity to manage RoadRunner deployment (Docker/K8s)
• ✅ When you are on v3.6.x and can absorb a major-version upgrade: v4.0.0 makes several implementations internal and removes deprecated code, so it is a breaking release for anyone extending or type-hinting the package's internals. Budget a migration spike if you have custom integrations.
• ✅ If you rely on log-based observability/alerting — v4.0.0 fixes Alert/Emergency level handling, corrects log level and bubbling behavior, and stops escaping slashes/unicode in RoadRunner log output. Verify downstream log parsers and alert rules against the new output format.
• ❌ Avoid for low-traffic internal tools or monolithic apps with <50 RPS
• ❌ If already using Laravel Octane (different solution with similar goals)
• ❌ When your team lacks experience with persistent workers or needs zero-config solutions
• ❌ If you have deep customizations against package internals and no capacity for a breaking-change migration this cycle — stay pinned to v3.6.x, which remains functional

How to Pitch It (Stakeholders)

For executives: "This package lets us handle 2-3x more traffic with the same infrastructure, cutting cloud costs while improving API response times by 40-60%. It integrates seamlessly with our existing Laravel codebase—no rewrite needed—and uses MIT-licensed open source with active maintenance. The newly released v4.0.0 is a maintenance and reliability release, not a feature release: it fixes log severity handling so our alerting is trustworthy, corrects shutdown behavior, and cleans up deprecated code. It carries a major version number because internals were tightened, so we'll schedule a short, contained upgrade rather than adopt it ad hoc. This remains a low-risk, high-impact optimization for our growth-stage product."

For engineering: "It eliminates PHP bootstrap overhead via persistent workers with zero framework changes. The bridge handles RoadRunner configuration, environment management, and graceful shutdowns out-of-the-box. We get production-ready tooling (logging, metrics, worker pooling) while maintaining familiar Laravel development patterns. Minimal learning curve for our team and no licensing barriers.

On v4.0.0 specifically: this is a breaking major release with no new features. The work is Logger Handler fixes (Alert/Emergency levels, log level and bubble behavior, no escaping of slashes/unicode in RR log output), TCP and Centrifugo interceptor argument normalization, a fix for EXIT command handling, deprecated-code removal, and a pass to mark implementations internal. Plan for: (1) an audit of any code that extends or references package internals — those surface areas are now private; (2) a regression check on log ingestion, dashboards, and alert rules given the normalized output format; (3) verification of worker shutdown behavior in staging before rollout. Four first-time contributors landed changes, which is a healthy maintenance signal but argues for running our own smoke tests rather than relying on upstream coverage. Recommend upgrading deliberately within a sprint, not as an incidental dependency bump."