Roadrunner Bundle Laravel Package

Product Decisions This Supports

• Runtime/hosting strategy (build vs. buy vs. don't change) — with an important caveat. This is a Symfony bundle, not a Laravel package. If the codebase in question is Laravel, the correct evaluation target is Laravel Octane; this package should be rejected on applicability grounds before any technical diligence. For a Symfony codebase, the decision is really "do we move off PHP-FPM to a persistent Go-based application server (RoadRunner)?" — and this bundle is the cheap "buy" half of that decision: the glue that makes Symfony behave correctly inside a long-running worker. The build alternative (hand-rolling your own Runtime + PSR-7 bridge + reset logic) is weeks of specialist work for something MIT-licensed and already solved.
• Performance/cost roadmap. This is the enabler for "same hardware, more throughput" — RoadRunner keeps the kernel and DI container warm between requests, eliminating per-request bootstrap. That translates into a PM-legible decision: defer a horizontal-scaling/infra-spend increase, or reduce instance count at flat traffic. Quantify before committing: benchmark one representative hot endpoint on FPM vs. RoadRunner, then extrapolate.
• Reliability policy as configuration, not code. The reboot-strategy options (on_exception, always, max_jobs with dispersion, memory threshold, and combinations) are genuinely product-facing knobs. They encode a decision about how much degraded-worker risk you'll tolerate in exchange for performance: on_exception + an allowed_exceptions allowlist is the "trust the app" position; always is the "correctness over speed" fallback; max_jobs + memory are the pragmatic leak-containment defaults. A PM can set the policy and let engineering implement it declaratively.
• Feature bets that only exist on a persistent runtime. Two capabilities are strategically interesting rather than merely fast: gRPC (implement proto-generated interfaces, services auto-register — a low-friction path to offering an internal service API alongside the HTTP app) and KV caching (RoadRunner's in-memory KV exposed as a standard Symfony cache adapter — useful for hot, disposable, cross-request data like rate-limit counters or feature-flag snapshots). Also gRPC makes this a candidate for service-to-service contracts where REST is a poor fit.
• Observability/SLO groundwork. Native Prometheus metrics collection declared in Symfony config plus a metrics endpoint, and lifecycle events (WorkerStart, WorkerStop, WorkerException, WorkerKernelRebooted) give you hooks for alerting on worker churn. Worker reboots are a silent performance cliff; being able to alert on reboot frequency is the difference between "we adopted this and it's fine" and "we adopted this and latency mysteriously doubled."
• Prioritizing migration scope. The bundle's built-in integrations (Sentry context, sessions, Doctrine ORM connection re-checks and manager clearing, Doctrine Mongo, Blackfire, Xdebug trigger mode) define the actual work backlog. Anything not on that list — custom caches, in-memory registries, singletons holding request data, custom auth state — becomes explicit migration tickets. That makes this an unusually well-scoped initiative to estimate.

When to Consider This Package

• Symfony 4.4–6.x application, containerized, already behind a load balancer — this is the sweet spot. Docker guidance is in the README (multi-stage build, rr get-binary to /usr/local/bin, EXPOSE 8080, CMD ["rr","serve"]), and the Runtime integration means minimal bootstrap changes.
• You have a measured performance problem or a cost target, not a vague ambition. Adopt when p95 latency or cost-per-request is on the roadmap and you can A/B it.
• Your team can own a non-PHP binary in the deploy pipeline. RoadRunner is a Go process; you need to pin, download, scan, and ship it, plus manage .rr.yaml alongside your Symfony config. No ops maturity, no adoption.
• Your services are mostly stateless per request, or you're willing to do the hygiene work (ResetInterface on stateful services, session handling, Doctrine connection health). The default_integrations: false escape hatch exists but is explicitly discouraged — treat it as a red flag, not a plan.
• You want a low-commitment pilot. The .rr.dev.yaml watch mode and the fact that FPM remains a viable rollback path make this reversible: run it in staging on one service, measure, decide.
• Look elsewhere when: the app is Laravel (this package does nothing for you — Octane is the analogue); you're on shared hosting or a platform that only supports FPM/mod_php; the app depends on request-scoped globals or third-party code you can't audit for state leakage; you need commercial support or an SLA — 309 stars, 0 dependents, and a single-maintainer profile mean there is no vendor to escalate to, and "0 dependents" is a weak ecosystem-validation signal even if the package is the de facto choice; or the Symfony version is newer than the documented 6.x ceiling. Verify the last release date (listed as 2026-05-27, which is anomalous — confirm the actual latest tag and whether it's a pre-release) and confirm RoadRunner 2.x alignment before scheduling anything.
• Also look elsewhere if you need RoadRunner's features but not Symfony — the bundle is only useful as Symfony glue; the runtime itself stands alone.

How to Pitch It (Stakeholders)

For executives: We can increase request throughput and cut per-request cost on our Symfony services without rewriting application code. This is an MIT-licensed adapter that lets Symfony run inside RoadRunner, a Go-based application server — the practical effect is that PHP stops paying its bootstrap tax on every request. Cost is contained: no license fee, no vendor lock-in, and a reversible rollout (we can pilot one service and fall back to our current setup). The risks are operational rather than product: it adds a Go binary to our deployment footprint and requires discipline around long-running-process state, which the package partially manages for us via configurable kernel-reboot policies and built-in Sentry/Doctrine/session handling. One clarification up front: this is Symfony-only — if the service in question is Laravel, the equivalent decision is Octane, and this package is out of scope.

For engineering: This is the smallest correct amount of code to run Symfony as a persistent RoadRunner worker. The kernel and container persist across requests; the bundle reboots them on exceptions, and you choose the strategy — on_exception with an allowed_exceptions allowlist for well-understood domain/HTTP exceptions, max_jobs with dispersion (e.g. 1,000 ± 20%) to bound leaks, and/or a memory threshold (default 128 MB) — and strategies compose. Session, Sentry scope, Doctrine ORM connection health and manager clearing, Mongo managers, Blackfire, and Xdebug trigger mode are handled out of the box. Middleware is supported via MiddlewareInterface, but note it runs outside Kernel::handle() and the stack resolves once at worker start, so don't expect per-request kernel services there. Also budget for auditing stateful services and implementing ResetInterface — that audit, not the install, is the real work. Metrics (Prometheus), gRPC service auto-registration, and a RoadRunner KV cache adapter are available if we want them.

Decision requested: Approval for a time-boxed pilot on one non-critical Symfony service — benchmark against FPM, implement ResetInterface on flagged services, wire reboot-strategy config and reboot-frequency alerting, then report latency, cost-per-request, and incident delta before any broader rollout.