Http Server Laravel Package

Technical Evaluation

Architecture fit. innmind/http-server is not a Laravel package — it is a server abstraction from the Innmind ecosystem that sits alongside PHP's PSR-7/PSR-15 world rather than inside it. It proposes an opinionated model (immutable request/response objects, decorator-based middleware, adapters that bind the same application to different runtimes) that overlaps directly with what Laravel Octane already owns. A Laravel application's HTTP entrypoint is Illuminate\Contracts\Http\Kernel::handle(SymfonyRequest): SymfonyResponse; this package expects the Innmind HTTP abstraction. There is no service provider, facade, config stub, or documented kernel bridge. Architecturally, adopting it means running Laravel outside its HTTP kernel contract and treating the framework as a library behind a foreign server loop — a meaningful inversion of the framework's design intent. Fit for a standard Laravel product: poor.

Integration feasibility. Technically possible, practically expensive. A working integration requires: (1) an inbound adapter translating the server's request object into a Symfony\Component\HttpFoundation\Request with correct superglobal/header/body population; (2) an outbound adapter mapping Response back, including streaming, file downloads, and binary responses; (3) a lifecycle owner that boots the container, resolves the kernel, and — critically — replicates the reset semantics Octane provides (container flush, singleton reset, Application re-binding, terminated-event dispatch). Steps 1 and 2 are a few days of work for a competent engineer; step 3 is where multi-week risk lives. We should assume 2–4 engineer-weeks to a credible spike, not a production path.

Technical risk. High, driven by adoption and ecosystem rather than code quality. Zero stars, zero dependents, and a single-maintainer project mean no downstream battle-testing to borrow confidence from. The API surface is idiomatic to Innmind's functional conventions (innmind/immutable, its own HTTP types), which are unfamiliar to most Laravel engineers and cannot be partially adopted — you either take the ecosystem's idioms or fight them. There is no visible Laravel or Symfony integration precedent to pattern-match against. The reported last release date (2026-08-16) is a future date relative to normal consumption and should be treated as a metadata anomaly until verified against the repository's tag history; that alone warrants a data-quality flag before any dependency decision.

Key questions.

• What concrete capability does this unlock that Octane + RoadRunner/Swoole/FrankenPHP does not already provide in a Laravel context?
• Does the package's own HTTP abstraction interoperate with PSR-7/PSR-15, or does it require full Innmind-native types end to end?
• Who is the maintainer, what is the release cadence, and is there a documented support/security channel?
• What is the runtime adapter story — which SAPI/event-loop backends are supported today, and are any production-proven?
• Is the future-dated release an artifact of the registry or the repository?

Integration Approach

Stack fit. Weak. Laravel's HTTP stack is Symfony HttpFoundation-centric; this package is Innmind-centric. The two share a language, not a contract. Any integration is an island of adapter code that the framework will never test for us and that will not be covered by Laravel's upgrade guides.

Migration path. There is no incremental path. Unlike a library you can adopt in one service, this replaces the request lifecycle. The only honest framing is a bounded spike in a throwaway service: stand up a minimal Laravel app behind the server, exercise routing, middleware, sessions, file uploads, and streaming, and measure how much of the framework's HTTP surface degrades. If the spike cannot cover sessions, cookies, file responses, and exception rendering cleanly, the evaluation ends there.

Compatibility. Verify PHP version constraints against our runtime, confirm the package's transitive Innmind dependencies do not conflict with our existing Composer graph, and check whether any adapter depends on extensions (Swoole, ext-sockets, event loops) we do not ship in our base images. MIT licensing is clean and imposes no procurement friction.

Sequencing. (1) Metadata verification — resolve the release-date anomaly, confirm tags and CI status. (2) One-week adapter spike scoped to a single trivial endpoint. (3) If viable, a second spike covering the hard 20% — file uploads, streaming, error rendering, container reset across requests. (4) Benchmark against Octane under identical load. (5) Decision gate with a written comparison. Do not sequence this ahead of any Octane tuning work; the incumbent is cheaper to improve.

Recommended position. Do not adopt for production Laravel services. Retain as a watch-list item for non-Laravel PHP services with functional-programming constraints, and revisit only if dependents grow into double digits or the project publishes a framework bridge.

Operational Impact

Maintenance. Effectively unmaintained from our perspective — one maintainer, no dependents, no organizational backing. We would own the adapters, the lifecycle reset logic, and the upgrade burden indefinitely. Every Laravel minor release becomes a manual compatibility audit because the integration layer is ours and untested by upstream.

Support. No commercial support, no vendor to escalate to, no community to search. Incident response for a server-loop bug becomes "read the source and patch it," with MIT permitting a fork but no promise of upstreaming.

Scaling. Unproven. Worker-mode serving requires disciplined state management; Octane's value is largely the accumulated hardening around that discipline. Reimplementing it invites the classic failure set: memory growth across requests, stale singletons, cross-request data leakage, connection pool exhaustion, and event-loop-blocking synchronous code paths.

Failure modes. Silent state bleed between requests is the dangerous one — it manifests as intermittent data leakage, not a crash, and is hard to attribute. Secondary modes: adapter-level response corruption on streaming/binary payloads, unhandled exceptions bypassing Laravel's error renderer and surfacing raw stack traces, and abandoned-dependency rot when a transitive Innmind package bumps a breaking major.

Ramp-up. Steep and non-transferable. Engineers would need to absorb Innmind's functional conventions — immutable collections, decorator composition, its own HTTP types — none of which appear elsewhere in our stack. That training investment buys knowledge applicable to exactly one unmaintained dependency. Budget it as pure cost, not capability building.

Bottom line. Low score reflects reality: interesting design, wrong ecosystem, no adoption signal. Decline for Laravel use; log the metadata anomaly and revisit only on evidence of a real integration layer and a multi-maintainer project.