Httpkernel Adapter Laravel Package

Technical Evaluation

• Architecture fit: php-pm/httpkernel-adapter is a thin bridge between PHP-PM’s persistent-worker model and Symfony/Laravel’s HttpKernel. It fits only when PHP-PM is already a deliberate architectural choice or when the team is explicitly evaluating boot-once/request-many PHP serving. It is not a general Laravel performance package and not a drop-in replacement for PHP-FPM; it changes process lifecycle, request isolation, and deployment topology.
• Integration feasibility: Feasible as a Composer dependency alongside PHP-PM, but requires PHP-PM configuration, a reverse proxy, and process supervision. The host must support required PHP extensions such as pcntl, posix, and sockets. Because the last release is June 2023, Laravel/PHP/Symfony compatibility must be validated rather than assumed.
• Technical risk: Medium-high. Persistent workers expose Laravel state leakage: container singletons, config, auth, sessions, database connections, static caches, and request-scoped services can survive across requests. The adapter is small, but Laravel-specific lifecycle reset behavior may be incomplete. Low Packagist dependents, modest stars, and niche PHP-PM adoption weaken production evidence.
• Key questions: Which Laravel, Symfony HttpKernel, PHP, and PHP-PM versions are supported? Does the adapter reset scoped instances, DB connections, auth/session state, filesystem state, and exception handlers per request? How are file uploads, streaming, SSE, and long-running requests handled? What is the graceful reload and worker-recycling story? Is PHP-PM actively maintained? Are there production references and benchmarks against Laravel Octane and PHP-FPM? What is the security-patching path for this dependency chain?

Integration Approach

• Stack fit: Best for stateless Laravel applications using the standard HTTP kernel and no FPM-specific assumptions. Poor fit for applications relying on Apache/mod_php, per-request globals, local mutable state, in-process caches, or heavy singleton side effects. If the team already uses Laravel Octane, this adapter is usually not the right path because Octane is first-party and better supported.
• Migration path: Do not big-bang migrate. Run a time-boxed proof of concept in non-production behind Nginx or another reverse proxy to PHP-PM. Pin PHP-PM, adapter, Laravel, Symfony, and PHP versions. Compare latency, memory growth, error rates, and operational complexity against the existing PHP-FPM or Octane baseline. Keep PHP-FPM as a rollback path.
• Compatibility: Validate the full dependency matrix: PHP runtime, PHP-PM release, adapter release, Laravel version, Symfony HttpKernel version, and required extensions. Confirm that queue workers, schedulers, and CLI commands remain separate from HTTP serving. Avoid running PHP-PM and Octane as competing HTTP runtimes on the same application without a clear reason.
• Sequencing: 1) Inventory stateful code, globals, singleton assumptions, and long-lived connections. 2) Build a single-route PoC. 3) Add health checks, worker recycling, and request-correlation logging. 4) Test auth, sessions, uploads, streaming, DB reconnects, and exception rendering. 5) Run soak and load tests. 6) Canary a small traffic slice. 7) Formalize rollback, runbooks, and ownership. If the PoC exposes unresolved state leakage or compatibility gaps, stop and treat the package as a reference implementation rather than a production dependency.

Operational Impact

• Maintenance: The adapter is MIT-licensed and small, but maintenance risk sits in the surrounding stack: PHP-PM activity, Laravel compatibility drift, and PHP runtime updates. With 245 stars, zero listed dependents, and a 2023 release, the package has limited ecosystem validation. A TPM should require an internal owner, pinned versions, a fork policy, and a dependency/security review cadence.
• Support: Community-only support is likely. There is no evident commercial SLA. Troubleshooting will require source-level understanding of PHP-PM, the adapter, Laravel’s kernel lifecycle, and the event loop. Budget engineering time for debugging and upstream contribution if the package becomes production-critical.
• Scaling: Scale by adding PHP-PM workers/processes and CPU/memory, not by assuming FPM-style horizontal behavior. Persistent workers reduce bootstrap overhead but increase per-worker memory and make leaks more visible. Monitor memory growth, DB connection health, opcache/preload behavior, and log buffering. Autoscaling should consider memory and worker health, not just request rate.
• Failure modes: Likely failure modes include memory leaks, stale container state, request bleed between users, DB connection drops, stuck event loops, worker crashes, graceful reload failures, upload/streaming incompatibilities, and harder tracing. Operationally, this requires supervisor management, health endpoints, worker recycling, structured logs with request IDs, and clear alerts.
• Ramp-up: Medium-high. Developers must understand persistent-worker lifecycle and stateless application design; SRE must own reload, drain, crash, and memory-growth runbooks. Training and observability are prerequisites, not follow-up work.
• TPM recommendation: Leverage this package only after PHP-PM is a strategic requirement or as a time-boxed performance experiment. For most Laravel organizations, Laravel Octane or PHP-FPM is the lower-risk path. If adopted, gate it with a PoC, compatibility matrix, canary rollout, rollback plan, and named internal owner.