Roadrunner Http Laravel Package

Product Decisions This Supports

• Reaffirms the strategic shift from PHP-FPM to worker-based architecture: RoadRunner v3 support makes this package viable for teams standardizing on the current RoadRunner runtime.
• Supports high-throughput API and real-time use cases where request concurrency and memory overhead matter, including event-driven services and sub-100ms response targets.
• Reinforces the build-vs-buy decision to use an open-source, PSR-compatible HTTP component in the RoadRunner ecosystem instead of custom server logic.
• Introduces a dependency modernization decision: the package is renamed to roadrunner/http, so PMs should plan Composer constraint updates, documentation changes, and migration communication rather than treating this as a drop-in feature.
• Raises the platform baseline to PHP 8.2, which should be sequenced with broader runtime upgrade planning and security/maintenance goals.
• The numeric header-name fix in filterHeaders() is a reliability improvement for services that inspect or forward headers with numeric names.

When to Consider This Package

• Consider adoption when the team is on PHP 8.2+ and either already uses RoadRunner v3 or is planning that upgrade.
• Strong fit for Laravel/Symfony services that need PSR-compatible HTTP handling inside a worker-based runtime, especially APIs with high concurrency or real-time workloads.
• Adopt when the organization can absorb the package rename from roadrunner-php/http to roadrunner/http and update dependency references, tests, and internal documentation.
• Defer or plan a migration if the product is pinned to RoadRunner v2, PHP below 8.2, or the old package name in critical deployment pipelines.
• Look elsewhere if the team is not using RoadRunner, needs a framework-native HTTP kernel without worker runtime, or cannot take on the PHP/runtime upgrade in the near term.

How to Pitch It (Stakeholders)

• Executives: This release strengthens the case for worker-based PHP services by adding RoadRunner v3 support, which protects the scalability and infrastructure-cost story. The main work is dependency modernization, including a package rename and PHP 8.2 baseline, not a new product bet.
• Engineering: Treat v4.2.0 as an upgrade-planning release: validate PHP 8.2 readiness, update Composer references to roadrunner/http, confirm RoadRunner v3 compatibility, and regression-test header handling where numeric header names are relevant.
• Product/roadmap: Sequence the package rename and PHP 8.2 upgrade with existing platform maintenance work; avoid bundling it into a feature release without migration capacity.
• Risk framing: The package rename and PHP minimum are the meaningful adoption gates; the RoadRunner v3 support is the strategic upside.