Product Decisions This Supports
- Runtime architecture / platform bet: this package is the adapter layer that lets PHP worker code speak PSR-7 to the RoadRunner Go application server. Adopting it is not a feature decision — it is a decision to move off the request-per-process model (PHP-FPM) toward a resident worker pool. That choice gates throughput, latency, container density, and hosting cost for every service behind it.
- Roadmap: cost-per-request and p95 latency work. RoadRunner keeps workers warm across requests, removing framework bootstrap and autoload cost from the hot path. If your roadmap has a "reduce infra spend" or "improve p99 under peak" item, this is one of the few levers that moves both without a rewrite of business logic.
- Build vs. buy vs. adopt: MIT-licensed, ~small code surface, glue rather than product. Building an equivalent PSR-7 transport binding in-house is pure undifferentiated work; the real build cost sits in the migration (state hygiene, lifecycle, observability), not the client. Buy the package, budget the migration.
- Ecosystem compatibility as a feature gate: if your application, router, or middleware stack is PSR-7/PSR-15 based (Mezzio, Slim-style stacks, League routers, PSR-7 middleware you already own), this package is what preserves that investment on RoadRunner. Without it, adopting RoadRunner means rewriting the HTTP boundary of the app — which flips the business case.
- Vendor/stack consolidation: a credible alternative to FrankenPHP, Swoole, and Laravel Octane's own worker management. Useful as a negotiating/benchmarking option in a runtime bake-off even if you don't ship it.
- Portability hedge: PSR-7 at the boundary means the handler code stays server-agnostic, so a later move to another worker runtime is a transport swap rather than an application rewrite.
When to Consider This Package
Consider it when:
- You are already running, or are actively evaluating, RoadRunner as the app server, and need the PSR-7 HTTP worker client to bind handlers to it.
- Your codebase or a subsystem is genuinely PSR-7/PSR-15-shaped, so the standard interface is an asset rather than overhead.
- Your workload is I/O-bound, high-RPS, or latency-sensitive (API gateways, JSON services, internal platform services) where per-request bootstrap is a measurable share of wall time.
- You are containerized and care about memory-per-request and cold-start density; resident workers change the packaging and scaling math favorably.
- You want a permissive-license, thin dependency at the transport layer.
Look elsewhere when:
- You are on Laravel/Symfony and not already committed to RoadRunner. Octane (or Symfony Runtime) manages worker lifecycle, state resets, and the server integration for you; hand-wiring this package means owning that lifecycle yourself. Prefer the framework's integration.
- You need a support contract, SLAs, or broad community precedent. 78 stars and 0 dependents is a real signal — though partly an artifact of it being a split sub-package of a much larger, widely used project. Diligence the parent project's health, not this repo's star count, and confirm the release cadence (the listed 2026-10-19 release date needs verification before you plan around it).
- Your traffic is low or bursty with long idle periods. Warm workers cost memory when idle; FPM's on-demand model is cheaper and simpler at low volume. The performance case evaporates.
- Your app is not state-clean. Global/singleton state, static caches,
$_GET/$_POST/$_SERVER reliance, and per-request ini_set assumptions are the classic failure mode of long-running workers. If a state audit looks expensive, the ROI collapses — fix the app first.
- You need bleeding-edge PSR-7 features or long-term API stability guarantees without pinning and owning the upgrade path.
Mandatory diligence before committing: benchmark your own workload (not vendor numbers); audit for superglobal and static-state leakage; confirm upload, streaming, session, and timeout semantics against your requirements; verify how errors and worker restarts surface in your observability stack.
How to Pitch It (Stakeholders)
To executives: This is a low-cost, MIT-licensed component that unlocks a meaningful infrastructure decision — running PHP on a persistent worker model instead of booting the framework on every request. The expected payoff is lower CPU and memory per request, better tail latency at peak, and fewer/smaller instances for the same traffic, which is a direct line to cloud spend. The cost is engineering time, not license fees: the risk is concentrated in migration and operational discipline, not in the package itself. Recommend a time-boxed spike on one non-critical service with a clear go/no-go on measured p95 latency and cost-per-million-requests, rather than a platform-wide commitment. Note that the package itself is a thin, low-adoption glue library — treat the parent RoadRunner project's health, not this repo's stars, as the real vendor-risk question, and keep the PSR-7 boundary so we retain an exit to another runtime.
To engineering: This is the PSR-7 worker client for RoadRunner — it gives handlers a standard request/response contract and lets us keep an existing PSR-7/PSR-15 middleware stack instead of rewriting our HTTP layer. It is deliberately small and boring: no framework opinions, no hidden magic. The real work is on our side — we must guarantee request isolation (no leaked static/singleton state, no reliance on superglobals), define worker lifecycle and graceful shutdown, and instrument worker restarts and memory growth. Ask: is our HTTP boundary already PSR-7, and can we prove state cleanliness with a soak test? If yes, this is a clean transport swap behind a stable interface. If no, sequence the app-hygiene work first, because this package will faithfully expose every latent assumption in our code.