Symfony Spawn Laravel Package

Technical Evaluation

Architecture fit. Despite the "Laravel/PHP" framing in the brief, this is symfony-spawn — a Symfony HttpKernel-based package that runs an application behind an in-process worker pool rather than PHP-FPM. For a Symfony service it is architecturally coherent: it reuses the framework's own kernel and HTTP abstractions, so application code does not need to be rewritten. For a Laravel estate the fit is weak: Laravel does not use Symfony's HttpKernel request loop in the same way, so this is not a drop-in alternative to Octane, RoadRunner, FrankenPHP, or Swoole. The realistic use case is a standalone Symfony service or an internal daemon, not Laravel app serving.

Integration feasibility. Composer-installable and low-ceremony, but the release history tells the important story: v0.2.3 contains "make multi-threaded runner actually work," which is a correctness fix, not an incremental improvement. Any prior evaluation of v0.2.2 throughput or stability should be treated as invalid. The second change moves worker-count control into HttpServerConfig::setWorkers(), which is a configuration-surface change shipped in a patch release.

Technical risk.

• Pre-1.0 semver. At 0.2.x, patch releases may change behavior and configuration. Pinning is mandatory, not optional.
• Exotic runtime. Multi-threaded PHP implies a ZTS build plus parallel/pthreads (or an equivalent). This constrains base images, complicates CI, and is unfamiliar to most PHP engineers.
• Cache warmup across threads. Warming caches before/around thread startup introduces shared-state questions: opcache duplication, container/DI reuse across threads, and race conditions on first request.
• Bus factor. One primary author plus one new contributor on their first PR. No evidence of an LTS or support commitment.
• Verification debt. "Actually work" fixes without published benchmarks or a test matrix leave us dependent on our own load tests to establish a baseline.

Key questions.

1. What runtime does it require — ZTS PHP + ext-parallel, or a fork/process model? Does that work in our base images?
2. Is setWorkers() a breaking change to how worker count was previously configured (env var, CLI flag, config file)? What is the precedence order?
3. Is the Symfony DI container shared across threads, and is it safe to be?
4. How does cache warmup interact with opcache preloading and per-thread memory?
5. Where does the project sit relative to RoadRunner/FrankenPHP — is it a general-purpose server or a niche experiment?
6. Is there any published performance or stability data, or is the only evidence the changelog?

Integration Approach

Stack fit. Treat as Symfony-only. If the target application is Laravel, this package is out of scope and the correct comparison set is Octane, FrankenPHP, and RoadRunner. If the target is a Symfony service with a narrow HTTP surface, it is a plausible spike candidate — the win being no extra runtime binary and no Swoole extension.

Migration path. Not a migration target. There is no path from FPM to this package that preserves operational assumptions, so adopt only greenfield or as an isolated experiment in a single service. Whatever we build on it must sit behind a clean service boundary (HTTP contract, no package-specific types leaking into application code) so swapping back to FPM or onto FrankenPHP is a container change, not a rewrite.

Compatibility.

• PHP version and ZTS requirement must be confirmed against our standard base image before any work starts.
• Container orchestration: setWorkers() must be driven by our CPU limits, not hardcoded. Worker counts tuned to a developer laptop will thrash in Kubernetes.
• Signal handling and graceful shutdown semantics under Kubernetes pod termination need explicit validation.
• Opcache/preloading configuration per worker/thread needs a documented baseline.

Sequencing.

1. Pin to an exact tag (0.2.3), never a floating ^0.2.
2. Confirm runtime prerequisites against our image build — this is a go/no-go gate, cheap to check.
3. Spike in one non-critical Symfony service with a real traffic shape.
4. Validate thread-safe DI/container behavior and cache warmup under concurrency.
5. Benchmark against FPM and against FrankenPHP as the incumbent-alternative; pick on operational simplicity, not raw RPS.
6. Only then consider broader use, and only with an internal owner assigned.

Operational Impact

Maintenance. Effectively "vendor at your own risk." The package is young, has a single dominant author, and is still reshaping its configuration API in patch releases. Budget a review of every upstream release rather than accepting automated dependency bumps. If the service becomes important, plan for the possibility of maintaining a fork.

Support. No commercial support, no LTS branch, community-only issue triage. An internal owner with PHP-internals literacy is a hard prerequisite — this is not a package an application team can adopt and forget.

Scaling. Centralizing worker count in HttpServerConfig::setWorkers() is the right direction: it gives one knob that maps cleanly to CPU requests/limits. But the scaling model is vertical-per-pod by default — thread-per-worker multiplies memory footprint and opcache duplication, and cache warmup adds a cold-start cost per pod. Prefer horizontal scaling with modest worker counts over large per-pod pools. Note that a misconfigured worker count degrades throughput quietly rather than failing loudly, which is a capacity-planning hazard.

Failure modes.

• Thread hangs with no preemptive timeout — one stuck worker can silently reduce capacity.
• Cache warmup races producing partially-warm workers and inconsistent latency at rollout.
• Build-time incompatibility (non-ZTS image) that only surfaces at deploy.
• Silent misconfiguration of setWorkers() producing under-provisioned pods.
• Partial pool failure where the process stays up but serves degraded throughput, defeating liveness checks.
• Upstream patch release changing semantics between deploys.

Ramp-up. Non-trivial. Engineers need working knowledge of PHP's threading model, process signal handling, and the Symfony HttpKernel request lifecycle — areas most application developers never touch. Budget a spike, a load-test harness, and a written runbook (worker sizing, drain behavior, observed failure signatures) before this goes near production traffic. Realistically 1–2 engineer-weeks to reach a defensible go/no-go, and the expected outcome for a Laravel-centric estate is no-go on stack fit alone.