- Is roadrunner/http-bundle a Laravel package?
- No. The Composer package is roadrunner-symfony/http-bundle, a Symfony bundle that adapts RoadRunner's PSR-7 request/response model to Symfony's HttpKernel. It ships no Laravel service provider, no publishable config, and no Octane-compatible worker hooks, so treating it as a Laravel dependency is a category error. If your estate is Laravel-only, the supported path to the same runtime benefit is Laravel Octane with the RoadRunner driver.
- How do I install roadrunner/http-bundle in a Symfony application?
- Install it with Composer, register the bundle in your bundles.php or kernel, and pair it with the Symfony Runtime component's RoadRunner runtime. You must also install and pin the rr binary and author a .rr.yaml file, because the bundle itself is only a thin adapter. Finally, change your process entrypoint from php-fpm to rr serve and add health and readiness endpoints.
- Can I use roadrunner/http-bundle with Laravel instead of Octane?
- You can technically wire it up, but you would be bypassing Octane's runtime entirely and inheriting the bundle's bootstrap assumptions rather than Laravel's. Octane with the RoadRunner driver is first-party and ships its own worker lifecycle plus sandbox and singleton flushing, none of which this bundle provides. For a Laravel estate, use this package only as a reference implementation for how the PSR-7 to HttpKernel bridge is wired.
- Which Symfony and PHP versions does roadrunner/http-bundle support?
- The bundle targets modern Symfony (6.x, 7.x, 8.x) on PHP 8.2 or newer. Confirm the exact constraints in its composer.json before committing, because three independently versioned surfaces must stay aligned: the bundle, your Symfony and PHP version, and the RoadRunner binary and Goridge protocol. Bundle-to-RoadRunner protocol drift is the most common breakage class and usually fails opaquely at worker handshake time.
- How does the bundle bridge PSR-7 requests to Symfony's HttpKernel?
- RoadRunner receives the HTTP request and passes it to a long-running PHP worker, where the bundle converts the PSR-7 request into a Symfony Request object. That request is dispatched through HttpKernel, and the resulting Symfony Response is converted back into a PSR-7 response for RoadRunner to emit. Because workers stay alive between requests, you get lower bootstrap overhead than php-fpm but must reason carefully about request-scoped state.
- What do I need to configure besides installing the bundle?
- The bundle does not supply the rr binary, the .rr.yaml configuration, or container and entrypoint changes, so that is real integration work. Expect to author .rr.yaml with pool sizing, max_jobs, timeouts, and a static file policy, change the process entrypoint to rr serve, and add health and readiness endpoints. You should also move session storage off the filesystem to Redis or the database before going live.
- What production risks come with RoadRunner's long-running workers?
- The dominant risk is state leakage across requests rather than HTTP handling itself. Container singletons, static caches, in-memory registries, and open connections persist between requests, so the codebase needs an explicit audit for request-scoped assumptions. Also verify file uploads and streaming or SSE responses, and be aware that $_SERVER and $_FILES superglobal emulation has known edge cases.
- How does roadrunner/http-bundle compare to Laravel Octane as an alternative?
- They solve the same problem at different layers. Octane is Laravel's first-party integration with a documented worker lifecycle, sandbox and singleton flushing, and a supported RoadRunner driver, while this bundle is a niche Symfony adapter with minimal downstream validation. For Laravel, Octane is the correct choice; for Symfony services, this bundle is the direct route. In a polyglot Symfony plus Laravel estate, running one rr binary and one .rr.yaml operational model across both frameworks is a coherent platform bet.
- Is roadrunner/http-bundle actively maintained and safe for production?
- Adoption signals are weak: roughly 47 stars, zero dependents, and an opportunity score around 2.52 indicate a niche package with little third-party production hardening. A single-effort Symfony bundle at that level carries bus-factor and abandonment risk, and a recent release date alone does not establish cadence. Pin versions, run a spike in staging, and decide in advance whether your fallback is forking the bundle or reverting to php-fpm.
- How should I benchmark and test a RoadRunner migration before committing?
- Establish a php-fpm baseline first, then measure the same workload through rr serve at realistic concurrency for throughput, p50 and p99 latency, and per-node cost. Without that baseline there is no way to justify the operational delta of owning the rr binary lifecycle, including patching and CVE response. Run functional tests against a live rr serve in staging, exercise uploads, streaming, sessions, and superglobal edge cases, and define who owns binary upgrades and image rebuilds.