Roadrunner Http Laravel Package

Technical Evaluation

Correction to prior assessment. The previous evaluation was built on an empty data set ([]) and drew conclusions that this release directly contradicts. Two findings must be retracted: (1) the package is not a private/unknown repository — it is public at github.com/roadrunner-php/http, with linked PRs (#35–#48) and commit SHAs; (2) it is not "tightly coupled to Spiral" — it is the PSR-7/PSR-17 HTTP bridge for the RoadRunner application server and is framework-agnostic by design. That reframing materially changes the Laravel fit.

Architecture fit (Laravel). This is the HTTP request/response layer used by PHP workers running under RoadRunner. For Laravel teams, the relevant architecture is Laravel Octane with the RoadRunner driver, where this package sits beneath the framework and above the Go server. It is not a drop-in for a conventional FPM/nginx Laravel app, so fit should be scored as "viable and supported, but only on the Octane+RoadRunner path." Teams on Swoole or FrankenPHP get no value from it.

Release content assessment (v4.2.0).

• rename the package to roadrunner/http (#48) — the highest-impact change. A Composer package rename is a breaking event for composer.json constraints, lockfiles, and any replace/provide declarations. TPM action: confirm whether the old name is aliased or abandoned, and whether a metapackage shim exists.
• support RoadRunner v3 (#36) — a runtime-major alignment. This is where compatibility risk concentrates: the PHP package, the RoadRunner binary, and the Laravel/Octane bridge must be upgraded as a set, not independently.
• require PHP 8.2 (#44) — a hard floor. Any Laravel app on 8.0/8.1 is immediately excluded; this is a fleet-wide inventory question, not a per-repo one.
• migrate tests to Testo (#44) — internal, but it binds the project's test tooling to a Spiral-maintained framework. Low risk for consumers; relevant only if we intend to contribute patches and must run the suite locally.
• keep numeric header names in filterHeaders() (#35) — a correctness fix in header filtering. Worth flagging to QA: header handling in long-running workers is exactly the class of bug that surfaces as intermittent, hard-to-reproduce production issues rather than clean test failures.
• #[\Override] annotations (#47) — housekeeping; no consumer impact.

Technical risk. Reduced versus the prior assessment: active maintenance, conventional-commit changelog, linked reviewable PRs. Residual risks: (a) three of the five features are breaking or ecosystem-shifting in a single minor version bump, which suggests loose semver discipline — plan for this package to break on minors; (b) the changelog date 2026-10-10 is future-dated, consistent with the earlier anomaly (2026-02-26), so treat release timestamps as unreliable metadata and verify actual publication dates and tag contents before pinning; (c) the package now carries a second identity, and ecosystem documentation, Stack Overflow answers, and tutorials will lag the rename for a meaningful period.

Key questions for the maintainers. Is the previous package name aliased, and for how long? Is there a documented compatibility matrix across PHP version × RoadRunner v3 × Octane version? Does the RoadRunner v3 requirement force a coordinated binary upgrade with no mixed-version window? What is the support/deprecation policy for the pre-rename line? Is Testo required to run the suite, or is there a PHPUnit path for external contributors?

Integration Approach

Stack fit. Positive for Laravel shops already committed to Octane with the RoadRunner driver, or evaluating RoadRunner as a Swoole alternative for throughput and memory characteristics. Negative for standard FPM deployments, and negative for anyone whose platform team has standardized on Swoole or FrankenPHP — adopting this package implicitly adopts a server runtime, which is an infrastructure decision, not a dependency decision.

Migration path. This is a coordinated four-artifact upgrade, not a composer update:

1. PHP runtime to 8.2+ across the target fleet.
2. RoadRunner binary to v3, deployed via the same pipeline that ships the app.
3. This package to the renamed roadrunner/http coordinate, updating composer.json and the lockfile.
4. The Laravel/Octane bridge to a version compatible with RoadRunner v3.

Treat the rename as the forcing function: if the old name is not aliased, every service's composer.json must change, which means every service must be touched — schedule this as a portfolio-wide dependency initiative rather than N independent tickets.

Compatibility. Validate against our actual Octane and Laravel minor versions before committing; the release notes give no matrix. Also verify header behavior in staging, given the filterHeaders() fix — if we were unknowingly affected, a staging diff of numeric-header handling is worthwhile.

Sequencing.

1. Inventory: which services run Octane+RoadRunner, and what PHP versions do they pin?
2. Confirm the alias/deprecation story for the old package name.
3. Spike one non-critical service end-to-end on PHP 8.2 + RoadRunner v3 + renamed package; measure cold start, memory, throughput.
4. Establish an internal pinned version and a short upgrade runbook.
5. Roll out in waves, lowest-traffic first; hold the remainder until the spike has run in production for a defined soak period.

Operational Impact

Maintenance. Net improvement. Public repo, traceable PRs, a refreshed README, and semantic-release-generated notes mean we can audit changes before adopting them — the previous assessment's central complaint is resolved. The caveat is that a minor version carried a package rename and a runtime-major bump, so our maintenance posture should assume upgrades are never trivial: pin exactly, review changelogs, and budget real effort per minor.

Support. GitHub issues on a public repository — a normal but thin channel for a critical-path HTTP layer. There is no commercial SLA. For a TPM, that means: this dependency is acceptable for services where we can tolerate upstream latency, and should be flagged in the risk register for anything customer-facing and high-volume. Identify one internal owner who can read the source and file upstream patches; that person is our real support contract.

Scaling. RoadRunner's worker model is the reason to adopt this — long-lived PHP workers, Go-based request handling, better memory behavior under concurrency than FPM. The trade-off is that scaling is now a runtime-tuning exercise: worker counts, memory limits, and restart policy become operational parameters we own, not defaults inherited from a web server. Capacity planning must be redone rather than translated from existing FPM numbers.

Failure modes. (a) Worker death under load — long-running workers accumulate state; memory leaks manifest as restarts under sustained traffic, not in tests. Require memory ceilings and restart policies before go-live. (b) Version skew — a PHP package expecting RoadRunner v3 against a v2 binary, or an Octane bridge pinned to the old package name, fails in ways that look like application bugs. Enforce lockstep versioning in CI. (c) Header/serialization edge cases — the filterHeaders() fix shows this surface is still being hardened; treat unusual header handling as a test target. (d) Composer churn from the rename — transient resolution failures while the ecosystem catches up; expect a window of confusing dependency errors.

Ramp-up. Moderate. Engineers comfortable with PSR-7 and long-running worker semantics will adapt quickly; those with FPM-only experience need to internalize that request state persists across requests and that the Go server, not PHP, owns connection handling. Budget a short internal enablement session plus the spike as the learning vehicle. The rename adds a documentation tax: existing tutorials and blog posts reference the old name, so internal docs should be written fresh and name the new coordinate explicitly.

TPM recommendation. Update the assessment from "high risk / unclear legitimacy" to "viable, actively maintained, with a coordinated-upgrade cost." Proceed with a single-service spike; hold broad rollout pending the maintainers' answers on aliasing and the compatibility matrix, and until the release-date metadata anomaly is resolved.