Httpkernel Adapter Laravel Package

Product Decisions This Supports

• Runtime architecture / build-vs-buy on serving infrastructure. This adapter is the glue that lets an existing Symfony or Laravel HttpKernel app run inside PHP-PM's persistent worker processes instead of per-request PHP-FPM bootstrap. It is an enabler for the decision "do we move off FPM to a resident-worker runtime?" — not a feature in itself.
• Latency and unit-cost roadmap targets. Keeping the framework bootstrapped across requests attacks a real cost line: per-request container boot, config load, and autoloader warmup. If your roadmap has throughput or p95 latency commitments, this is one lever to model against alternatives (Octane, FrankenPHP worker mode, Swoole/RoadRunner).
• Infrastructure investment sequencing. Because adoption is effectively zero-dependent (245 stars, no dependents, last release mid-2023), this is best treated as a prototype-grade spike input, not a platform commitment. It informs whether a performance workstream is worth funding, not which specific package to standardize on.
• Risk register input for stateful-request work. Adopting any persistent-worker model forces an audit of singletons, static state, service-container assumptions, and request-scoped data. That audit is a real product decision (engineering roadmap allocation), and evaluating this package surfaces it early and cheaply.
• Use cases where it fits: internal high-volume APIs, queue-adjacent or webhook endpoints with predictable request shapes, cost-sensitive batch-facing services. Poor fit: anything where correctness under long-lived processes is unproven, or where vendor support windows matter.

When to Consider This Package

Consider it when:

• You have measured bootstrap overhead as a meaningful share of request time or infra spend, not assumed it.
• You are already evaluating PHP-PM specifically (e.g., existing team familiarity, an ops stack built around it), because this adapter only has value paired with that process manager.
• You are running a time-boxed spike and want to prove the delta on your own workload before committing engineering time.
• Your team can absorb an audit of global/static state and request lifecycle assumptions in the app.

Look elsewhere when:

• You are on Laravel and have not yet evaluated Octane — it is the first-party, actively maintained answer to the same problem and carries far lower organizational risk.
• You need vendor backing, security patch guarantees, or an SLA. Sparse dependents and a 2023 last release are warning signs for a component sitting directly in your request path.
• Your traffic is modest or already latency-compliant. The complexity of resident workers (memory growth, deploy semantics, debug tooling, per-worker failure modes) is not justified.
• You need strong ecosystem alignment or hiring-market familiarity — PHP-PM's practitioner pool is small relative to FPM or Octane.
• The app is not a clean HttpKernel consumer, or relies heavily on request-teardown semantics.

How to Pitch It (Stakeholders)

To executives: This is a low-cost, low-commitment experiment that tests whether we can serve the same traffic with fewer PHP processes, which directly maps to lower compute spend and better latency. It is not a recommendation to adopt — it is a de-risked way to quantify the upside before we fund a runtime migration. The package itself is niche and thinly maintained, so we would treat the spike as a measurement exercise and, if the numbers justify it, standardize on a well-supported runtime (likely Octane or FrankenPHP) rather than this adapter.

To engineering: The adapter is a thin HttpKernel bridge that lets Symfony/Laravel boot once and serve many requests under PHP-PM. It requires no application rewrite to try, which makes it a cheap probe — but it also exposes every hidden piece of singleton and static state in the app. Plan the spike as: baseline FPM metrics → adapter under PHP-PM on a representative endpoint → targeted audit of stateful services → decision memo. Budget for the audit, not just the benchmark; the audit is the durable output regardless of which runtime we pick.