Http Bundle Laravel Package

Technical Evaluation

Architecture fit

• This is not a Laravel package. roadrunner/http-bundle is a Symfony bundle (roadrunner-symfony/http-bundle) that adapts RoadRunner's PSR-7 request/response model to Symfony's HttpKernel. It has no Laravel service provider, no config/ publishables, and no Octane-compatible worker hooks. Treating it as a Laravel dependency is a category error.
• For a Laravel estate, the architecturally correct path to the same runtime benefit is Laravel Octane with the RoadRunner driver, which is first-party, ships its own worker lifecycle, sandbox/singleton flushing, and is the supported integration surface. This bundle's only legitimate role in a Laravel-centric org is as a reference implementation for how the PSR-7 ↔ HttpKernel bridge and worker bootstrap are wired — or as a production dependency if the org also runs Symfony services.
• If the estate is genuinely polyglot PHP (Symfony + Laravel), RoadRunner as a shared Go-based application server is a coherent platform bet: one rr binary, one .rr.yaml operational model, consistent worker semantics across frameworks.

Integration feasibility

• Feasible but not turnkey. The bundle is a thin adapter; it does not supply the rr binary, the .rr.yaml configuration, or the container/entrypoint changes. Real integration work is: install and pin the RoadRunner binary, author .rr.yaml (pool sizing, max_jobs, timeouts, static file policy), change the process entrypoint from php-fpm to rr serve, and add health/readiness endpoints.
• The Symfony Runtime component provides a RoadRunner runtime that the bundle composes with; in Laravel you would be bypassing Octane's runtime entirely, which means inheriting the bundle's bootstrap assumptions rather than Laravel's.
• Blocking constraints to validate before committing: session storage must move off the filesystem (Redis/DB), uploads and streaming/SSE responses need explicit verification, and $_SERVER/$_FILES superglobal emulation has known edge cases.

Technical risk

• Low external validation. 47 stars, 0 dependents, and an opportunity score of 2.52 indicate a niche, low-adoption package. "0 dependents" is the strongest negative signal — there is no downstream corpus to infer stability from, and no evidence of third-party production hardening.
• Maintainer concentration. A single-effort Symfony bundle at this adoption level carries bus-factor and abandonment risk. A recent release date (2026-03-17) is mildly positive but does not establish cadence or long-term stewardship.
• Version tri-coupling. Three independently versioned surfaces must stay aligned: the bundle, the Symfony/PHP version, and the RoadRunner binary/protocol (Goridge). Bundle↔rr protocol drift is the most common breakage class and produces opaque failures at worker handshake time.
• Long-running worker state. The dominant production risk is not HTTP handling but state leakage across requests: container singletons, static caches, in-memory registries, and open connections persisting between requests. This is a codebase-audit problem, not an integration problem, and it is where most migrations fail.

Key questions

• Do we actually run Symfony anywhere, or is this being evaluated for Laravel? If Laravel-only, why not Octane's RoadRunner driver?
• What is the concrete driver — throughput at concurrency, latency p50/p99, or per-node cost? Without a baseline from php-fpm, there is no way to justify the operational delta.
• Who owns the rr binary lifecycle (patching, CVE response, image rebuilds)?
• Has the codebase been audited for request-scoped state assumptions that break under persistent workers?
• What is our fallback if this bundle goes unmaintained — fork it, or revert to php-fpm?

Integration Approach

Stack fit

• Laravel + Octane/RoadRunner is a supported, documented configuration: adopt that, and use this bundle only to read how the bridge is implemented.
• Symfony 6/7/8 services can adopt the bundle directly. Confirm the PHP floor (8.2+) and the Symfony major version against the bundle's compatibility matrix before scoping.
• If Octane is already in play with the Swoole driver, a RoadRunner migration is a lateral move with modest upside — the operational model shifts from PHP extension to Go sidecar binary. Justify it, don't assume it.

Migration path

• Run php-fpm and RoadRunner in parallel behind the same router/LB. RoadRunner is a process model swap, not a code change, so both can serve the same codebase.
• Order of work: (1) baseline metrics on php-fpm, (2) author .rr.yaml in version control, (3) container image gains rr and a new entrypoint, (4) health/readiness endpoints, (5) canary one low-risk service, (6) compare, then expand.
• Keep php-fpm images buildable and deployable for at least one full release cycle as an escape hatch.

Compatibility

• Pin the bundle version, the RoadRunner binary version, and the Symfony/PHP versions together in a single dependency manifest. Never float rr independently of the bundle.
• Verify PSR-7/PSR-17 implementation choice matches what the bundle expects; mismatches surface as header/body coercion bugs that are painful to diagnose.
• Third-party bundles/extensions that assume php-fpm lifecycle hooks (profiler, some debug toolbars, certain queue integrations) will need validation or replacement.

Sequencing

• Phase 0: decision gate — Laravel (Octane) vs. Symfony (this bundle) vs. no change.
• Phase 1: statefulness audit and session/upload remediation. This gates everything else.
• Phase 2: single-service canary with parallel traffic.
• Phase 3: observability parity — metrics, tracing, log correlation must be equivalent to php-fpm before expanding.
• Phase 4: incremental cutover, service by service, with php-fpm retained as the documented rollback.

Operational Impact

Maintenance

• New operational surface: the rr binary becomes a versioned, patched artifact in every image. That is a recurring cost even when nothing in PHP changes.
• .rr.yaml becomes a first-class config file with real blast radius (worker counts, timeouts, static file serving). It needs ownership, review, and environment parity — it is not a set-and-forget file.
• Code deploys now require worker restarts; opcache no longer reloads per request. Every deployment pipeline must handle graceful worker cycling, and any deploy that skips it silently serves stale code.

Support

• Debugging model changes materially: no per-request xdebug attach, altered dump/dd semantics, and stack traces that may terminate in the Go worker rather than in PHP. Expect a productivity dip and a support-desk knowledge gap during ramp-up.
• Error surfacing splits across two log streams (PHP worker stdout/stderr and RoadRunner's own logs). Log correlation must be configured deliberately or incident triage gets slower.
• Fewer engineers will have seen this bundle than Octane/Swoole; external support is effectively the maintainer plus upstream RoadRunner docs.

Scaling

• Scaling model is pool.numWorkers per instance, sized to CPU. This is simpler and more predictable than php-fpm's process-per-request model and yields better memory density per unit of concurrency — the core economic argument.
• Horizontal scaling is unchanged (replicas behind an LB), but worker recycling (max_jobs) must be tuned to bound memory growth; without it, long-lived workers degrade until OOM.
• Autoscaling signals shift: CPU per worker rather than request queue depth. Revisit HPA thresholds.

Failure modes

• Worker crash → request error or silent retry depending on config; a single poisoned request can cycle the pool.
• Stuck worker → request timeouts pile up; needs explicit pool.allocate_timeout / request timeout configuration.
• Memory leak per worker → gradual degradation then OOM kill; max_jobs is the mitigation, not a fix.
• Protocol/version mismatch between bundle and rr → handshake failures at startup, often with unhelpful errors.
• Stale code after deploy → workers serving pre-deploy bytecode.
• State bleed → cross-request data leakage, the highest-severity and hardest-to-reproduce failure class.
• Static asset and upload edge cases → differing behavior from nginx/php-fpm.

Ramp-up

• Estimate 2–4 weeks of engineering for a canary service including the statefulness audit, config authoring, container rework, and observability parity — plus ongoing ownership of the rr binary.
• Team enablement needed on: RoadRunner worker lifecycle, .rr.yaml tuning, two-stream log correlation, and the persistent-worker programming discipline (no request state on singletons).
• Given 0 dependents, 47 stars, and a low opportunity score, the honest TPM read is: do not adopt this bundle as a Laravel dependency. If Laravel, use Octane/RoadRunner; if Symfony, pilot this bundle on one service with a documented php-fpm rollback and treat maintainer risk as a standing item on the risk register.