- Can I use baldinof/roadrunner-bundle in a Laravel app instead of Laravel Octane?
- No. This is a Symfony bundle that registers Baldinof\RoadRunnerBundle\BaldinofRoadRunnerBundle in a Symfony kernel and boots through a Runtime entrypoint wired with APP_RUNTIME, so it cannot be dropped into a Laravel application. For Laravel, the supported path to the same RoadRunner worker model is laravel/octane with --server=roadrunner. Treat this bundle as an architectural reference for how Octane's sandbox, listeners, and state resets should behave, not as a dependency.
- What problem does baldinof/roadrunner-bundle actually solve?
- It turns a standard Symfony front controller into a long-lived RoadRunner worker so the kernel and DI container are bootstrapped once and reused across requests, removing per-request bootstrap cost. You get an extendable worker with middleware support, configurable kernel reboots, and automatic integrations for Sentry, sessions, Doctrine ORM, Doctrine MongoDB, Blackfire, and Xdebug. Your controllers stay untouched; the work is in state hygiene and configuration, not in rewriting application code.
- How do I install baldinof/roadrunner-bundle and get the RoadRunner binary?
- Run composer require baldinof/roadrunner-bundle; with Symfony Flex the bundle and default .rr.* config files are registered automatically, otherwise register the bundle in your kernel and copy the .rr.* files from the vendor directory. Then require the download utility with composer require --dev spiral/roadrunner-cli, fetch the binary with vendor/bin/rr get --location bin/, and start the server with bin/rr serve or bin/rr serve -c .rr.dev.yaml for watch mode. The app is served on port 8080 by default.
- Which RoadRunner version does the bundle support, and should I pin the binary?
- Yes, pin it. The bundle's documented surface targets RoadRunner 2.x, while current RoadRunner releases use year-based versioning, and rr get pulls the latest binary by default. An unpinned binary can silently outrun the bundle's relay and RPC protocol assumptions, so pin the exact version in your Docker image and CI and treat binary upgrades as bundle upgrades. The bundle, the Go binary, and .rr.yaml should be evaluated and deployed as one unit.
- How do kernel reboots and the on_exception strategy with allowed_exceptions work?
- Kernel reboot strategy decides whether the Symfony kernel is reused, rebooted, or thrown away between requests, which is a correctness decision before it is a performance knob. The on_exception strategy with an allowed_exceptions allowlist is the efficient default: the kernel is kept unless an exception outside the allowlist occurs, which forces a reboot. Your team has to classify which exceptions actually leave services in a recoverable state, because getting that wrong is how stale container state reaches the next request.
- Why do middlewares run outside Symfony's Kernel::handle(), and when should I use them?
- Middlewares implement Baldinof\RoadRunnerBundle\Http\MiddlewareInterface and wrap the request before it reaches the kernel, so they cannot access the container-based HTTP kernel lifecycle or controller logic. The stack is resolved once at worker start, which makes middleware initialization a startup cost rather than a per-request cost. Use them for transport and response shaping only, not application logic.
- Does the bundle handle Doctrine connections, sessions, and Sentry context between requests?
- Yes, when the companion bundle or extension is installed. It clears opened Doctrine ORM managers and revalidates the connection, clears Doctrine MongoDB managers, attaches the session cookie to the Symfony response when sessions are enabled, configures the Sentry request context, and enables Blackfire probing and Xdebug trigger mode. All of this is conditional, and you can turn it off with baldinof_road_runner.default_integrations: false if you prefer to wire resets yourself.
- What state-leakage bugs should I test for before running this in production?
- Cross-request leakage is the failure class you inherit with any persistent worker. The project's changelog is a catalogue of exactly these fixes: kernel not properly reset, Sentry scope bleeding between requests, sessions not closed when a handler throws, invalid uploaded files, StreamedResponseListener firing early, and unpopulated Basic Auth server variables. Each was fixed, but the pattern shows an ongoing regression surface, so build integration tests that hit the same worker repeatedly with different users, auth modes, and error paths.
- Do I need a PSR-7 implementation such as nyholm/psr7 to run the bundle?
- Yes, the worker needs a PSR-7 and PSR-17 implementation in the container, typically nyholm/psr7 pulled in through symfony/psr-http-message-bridge. There is a known DI misconfiguration when sensio/framework-extra-bundle is installed without nyholm/psr7, so pre-empt it in your base image. Installing nyholm/psr7 explicitly avoids a confusing container error at boot.
- Is baldinof/roadrunner-bundle actively maintained, and what are the alternatives for Laravel teams?
- It is a single-maintainer MIT project with good hygiene, including a README, changelog, tagged releases, and recent activity, but low visible adoption at roughly 309 stars and no recorded dependents. Support is best-effort GitHub issues with no vendor SLA, so the bus factor is worth weighing. For Laravel, the direct alternatives are laravel/octane with the RoadRunner server, FrankenPHP, Swoole via Octane, or the symfony/runtime component approach if you want to stay closer to plain PHP.