Product Decisions This Supports
- Runtime/infrastructure roadmap. This package is the decision-enabling layer for the question "do we stay on PHP-FPM or move to a persistent-worker runtime (RoadRunner, Swoole, FrankenPHP, ReactPHP)?" It boots the Laravel HTTP kernel once and exposes it as a PSR-15 handler, so a runtime swap becomes a configuration and ops change rather than an application rewrite. That makes benchmarking and feasibility work cheap enough to actually do.
- Build vs. buy for portability. Three options exist: (a) PHP-FPM, do nothing; (b) Laravel Octane, the first-party opinionated path; (c) a runtime-agnostic adapter like this one. Choosing (c) is a bet that runtime portability itself has value — useful when the runtime is dictated by hosting, on-prem, or regulatory constraints rather than chosen by us.
- Use cases that justify the evaluation: cold-start and cost-per-request reduction, container density, connection pooling, and de-risking a platform team's "standardize on FrankenPHP/Swoole" proposal with our own numbers instead of vendor benchmarks.
- Feature roadmap ceiling. Adoption implicitly commits us to owning the abstraction. It also sets expectations: this package handles bootstrapping, not Octane-style warm-up, request listeners, concurrency helpers, or tickers. Any roadmap item depending on those is out of scope and must be built or sourced separately.
- Migration sequencing. Because the adapter is small and removable, it supports a staged plan: spike on one non-critical service → measure → expand or revert. That is a materially different risk profile from adopting a runtime SDK directly.
When to Consider This Package
Consider it when:
- You are already standardizing on the php-runtime family and want one consistent bootstrap across Laravel, Symfony, and PSR-15 services.
- You need to compare two or more runtimes and want a comparable harness with minimal per-runtime code.
- Platform engineering can own the operational delta: worker lifecycle, graceful shutdown/reload, readiness probes, log/APM correlation across long-lived processes, and container-state-leak auditing (singletons, static caches, mutated config surviving between requests).
- You want the smallest possible dependency surface — MIT, a thin wiring layer, readable in an afternoon — rather than a framework.
- The service is moderate-complexity HTTP with no exotic per-request global state assumptions.
Look elsewhere when:
- PHP-FPM already meets latency and cost targets. The operational complexity is not repaid by theory.
- You want the mature, supported path for persistent workers in Laravel: Laravel Octane covers Swoole, RoadRunner, and FrankenPHP with warm-up, listeners, concurrency primitives, and a real support story. That is the default recommendation and the correct "buy" answer for most teams.
- You need vendor-specific capabilities (Swoole coroutines, RoadRunner plugins, FrankenPHP worker-mode extras). Use the native integration directly instead of hiding it behind a generic adapter.
- You require an LTS-backed dependency, vendor indemnity, or a large adoption base. With 18 stars and 0 dependents, assume you are an early adopter and price the support cost in explicitly; a small maintainer pool is a real continuity risk.
- Nobody on the team has debugged a long-lived PHP process before. This package does not smooth that learning curve — it exposes it.
How to Pitch It (Stakeholders)
30-second version: runtime/laravel is a thin, MIT-licensed adapter that lets our Laravel application run under modern persistent-worker runtimes instead of PHP-FPM, using one consistent bootstrap regardless of which runtime we pick. It is cheap to trial, easy to remove, and lets us answer "should we move off FPM, and to what?" with our own measurements rather than vendor benchmarks.
For executives: treat this as an option, not a platform bet. Cost is a time-boxed spike on one non-critical service; the payoff is a defensible infrastructure decision — cost per request, cold start, container density — with a reversible exit. The risk is support maturity: near-zero adoption and a small maintainer pool mean it should not sit on the critical path without a fallback. The fallback is comfortable, because Octane and FPM are both already viable. The package scores modestly on ecosystem signals, which is exactly why the recommendation is "evaluate," not "adopt."
For engineering: the package itself is roughly one runtime class wiring Laravel's HTTP kernel into a PSR-15 handler — do not budget for integration, budget for the real work: auditing the service container for request-scoped state leaks, defining worker lifecycle and graceful reload, and making observability work across long-lived workers. Proposed next step: a two-week spike on one internal service, benchmarked against both FPM and Octane on p50/p95 latency, memory per worker, and requests per container, with a written go/no-go. Adopt only if the numbers beat Octane and we have a named owner for the runtime abstraction.