Rapira Symfony Bundle Laravel Package

Product Decisions This Supports

• Runtime strategy for PHP services (build vs. buy vs. stay on PHP-FPM). This bundle is the integration layer that lets a Symfony application boot under Rapira's persistent-worker model instead of per-request FPM bootstrap. Adopting it is a decision to buy a runtime rather than maintain a bespoke worker bootstrap in-house — and 0.2.0 explicitly retires that bespoke surface (vendored worker.php removed in favour of a Symfony Runtime class plus a standard public/index.php).
• Consolidating deployment artifacts. One entrypoint (public/index.php) now serves both FPM and worker modes. That unlocks a real de-risking pattern: ship the same build, canary the worker mode behind a traffic slice, and keep FPM as the fallback without maintaining two bootstrap paths.
• Roadmap items that were previously blocked by per-request lifecycle limits. Three capabilities in these notes map directly to features teams defer on FPM:
  • Post-response work — uploads staying readable in kernel.terminate listeners makes virus scanning, image transcoding, and object-storage offload viable without holding the response.
  • DB-heavy features and queue consumers — connections held per worker and re-established when the server drops them (Doctrine, PDO; PostgreSQL, MySQL, MariaDB) is the prerequisite for long-running processes.
  • Anything behind auth — session and stray-output isolation between requests removes the class of bug that makes worker mode politically un-sellable internally.
• Supply-chain and dependency policy. Requiring stable rapira/contract ^0.9.1 removes the minimum-stability: dev escape hatch. That is a governance unlock: production dependency sets, automated update bots, and security-patch SLAs generally cannot tolerate a dev-stability floor.
• PHP version upgrade calendar. The PHP 8.4 dispatcher fix means the runtime is not a blocker for a platform upgrade — worth noting if 8.4 is on the roadmap.
• Compatibility-parity commitments. Form bodies, upload field names, cookies, zero-byte uploads, and hardened header handling are now "parsed like PHP-FPM." For a PM, this is the difference between "worker mode is a separate product with separate bugs" and "worker mode is a deployment toggle" — it changes the support and QA cost model, not just the feature list.

Adoption cost to budget for: 0.1.x → 0.2.x is a breaking operational change, not a drop-in. It requires setting extra.runtime.class in Composer, re-dumping autoload, and migrating rapira.toml from [pool]/worker.php to [http.pool]/public/index.php. Small in absolute terms, but it lands on whoever owns deploy config, and it is the second config-shifting release in a 0.x line.

When to Consider This Package

Consider it when:

• You run a Symfony application (or a Laravel app with a credible adapter path) that is IO-bound and spending meaningful time on per-request framework bootstrap.
• You are already running Rapira, or are evaluating it against RoadRunner / Swoole / FrankenPHP and want a maintained integration rather than hand-rolled worker scripts.
• You specifically want the Symfony Runtime integration model — that is the design centre of 0.2.0, and the reason the vendored worker disappeared.
• Your team can own worker lifecycle operations: graceful reloads, memory ceilings, health checks, connection-drop behaviour. The DB reconnect logic helps here, but it does not remove the operational discipline.
• You need FPM behavioural parity as a hard requirement (sessions, output buffering, upload parsing, cookies) — this release is largely a parity release, so it is the moment the gap narrows.
• You can pin and track two packages (rapira/contract ^0.9.1 and this bundle) in lockstep.

Look elsewhere when:

• You are Laravel-first. These release notes describe a Symfony bundle; there is no Laravel integration, service provider, or Octane compatibility called out. Laravel's supported persistent-worker path is Octane with RoadRunner/Swoole/FrankenPHP. Choosing this means committing to a Symfony-shaped integration and owning the glue.
• The workload is CPU-bound. Persistent workers buy you bootstrap savings, not compute.
• Third-party dependencies assume process isolation. Packages that lean on per-request globals, static caches, or superglobal mutation will surface as intermittent, hard-to-reproduce bugs regardless of what this bundle fixes.
• You need vendor support, an LTS, or semver guarantees. This is a 0.x line that just shipped a breaking config migration; the versioning contract does not yet promise stability.
• You lack ops capacity for worker lifecycle management. Worker mode without reload/memory discipline trades latency for outage classes you did not previously have.
• You need a single-vendor, commercially backed runtime with an on-call escalation path.

How to Pitch It (Stakeholders)

For executives (one paragraph): This release turns a promising runtime integration into something we can responsibly put in front of production traffic. The headline is not a feature — it is maturity: stable dependencies (so it fits our supply-chain and patch policies), proper isolation between requests (sessions and stray output no longer bleed across users), database connections that survive a worker being recycled, and request parsing that matches PHP-FPM closely enough that we no longer need a separate QA and support story for worker mode. Practically, it also collapses two deployment shapes into one entrypoint, which means we can trial worker mode on a slice of traffic and fall back to FPM with the same build if numbers disappoint. The cost is a small, well-documented config migration and an ongoing commitment to track a pre-1.0 dependency.

For engineering: The bespoke surface is gone — no vendored worker.php, no minimum-stability: dev. You register a Runtime class via Composer, point rapira.toml at public/index.php, and the same file serves both modes. That means one bootstrap to reason about, one artifact to build, and one place to debug. In exchange, expect to own worker-mode hygiene explicitly: memory growth, graceful reload, and validating that third-party packages do not carry request state across requests. The PHP 8.4 dispatcher fix removes a blocker if 8.4 is on your upgrade path.

Risk framing to state up front: this is a 0.x package that just required a breaking configuration migration. Treat v0.2.x as production-capable but not yet production-promised: canary it, keep FPM as the fallback (which the single-entrypoint design makes cheap), pin both rapira/contract and the bundle, and re-evaluate the integration's maturity at the next minor.