Symfony Spawn Laravel Package

Product Decisions This Supports

• Concurrency roadmap decisions: v0.2.3 makes the multi-threaded runner functional (thread closures + cache warmup) and wires the worker pool through HttpServerConfig::setWorkers(). This means you can now realistically evaluate replacing external process managers (Supervisor + multiple php-fpm/Octane instances) with an in-process worker pool for long-running or parallel workloads — relevant to any roadmap item touching queue throughput, background jobs, report generation, or fan-out API aggregation.
• Build vs buy: If your product needs parallel task execution inside a Laravel app, this package is an emerging alternative to building a bespoke worker pool or adding Horizon/Supervisor/Octane infrastructure. The setWorkers() refactor signals intent to align with Symfony's HTTP server config conventions, which lowers the cost of standardizing on one config surface across services.
• Platform/infra cost reduction: A working thread pool lets a single container saturate its CPU allocation instead of scaling horizontally with more processes — a direct lever on hosting spend for bursty, CPU-bound workloads.
• Architecture decisions: Adopting this ties worker concurrency to an HTTP-server-style config, which implies the package expects to sit alongside (or replace) your HTTP serving layer. That informs whether your next service should be designed around a persistent-worker runtime rather than classic request-per-process.
• Feature scoping: Multi-threaded execution unlocks features that were previously impractical (parallel PDF/invoice generation, concurrent third-party API calls, bulk imports with per-item progress) — worth revisiting deferred backlog items now that the runner actually works.
• Risk/contingency planning: A pre-1.0 package with single-maintainer activity informs the decision to prototype behind an interface rather than adopt wholesale.

When to Consider This Package

Consider it when all of the following hold:

• You are on Symfony or Laravel and need in-process parallel execution (thread-based) rather than queue-and-worker offloading, and you accept PHP's threading constraints (ext/parallel or equivalent runtime support — verify prerequisites on your PHP build).
• You want concurrency governed by a single config surface (HttpServerConfig::setWorkers()), matching how you already configure your HTTP server/FrankenPHP/RoadRunner setup.
• You are comfortable integrating a v0.x package and pinning versions; you have tests and a rollback path.
• Your workload benefits from cache warmup semantics — i.e., you want workers primed before traffic/jobs hit, reducing cold-start latency on the first requests.
• You are explicitly exploring replacing Supervisor-managed worker fleets or multiple Octane instances.

Look elsewhere when:

• You need production-grade guarantees today — no 1.x stability promise, no documented long-term support, and the changelog shows a core feature ("multi-threaded runner") only now becoming functional in v0.2.3.
• Your PHP runtime lacks threading extensions, or your hosting environment (shared hosting, locked-down managed PHP, serverless with strict memory/thread limits) cannot support persistent threaded workers.
• Your concurrency needs are already met by Laravel Horizon / Symfony Messenger + Supervisor — mature, observable, well-documented, and with large community support.
• You require vendor support, SLAs, or security disclosure processes — none visible here.
• You depend on broad ecosystem integrations (metrics exporters, APM auto-instrumentation, tracing) that expect a standard request cycle.

Recommendation: treat v0.2.3 as an evaluation-grade candidate. Pilot behind an internal abstraction, benchmark against your current Supervisor/Octane baseline, and avoid committing a public roadmap until at least a v0.5 or 1.0 with sustained release cadence.

How to Pitch It (Stakeholders)

For executives (one paragraph): We're tracking an open-source PHP package, symfony-spawn, that lets our Laravel/Symfony services run work in parallel inside a single process instead of paying for extra containers and process managers. Version 0.2.3 fixed its core multi-threading capability and standardized how worker count is configured — the two things that previously made it unusable. It's early-stage (pre-1.0, small maintainer base), so the right move is a time-boxed pilot on one CPU-bound workload to measure throughput-per-container and cost-per-job against our current setup. If the pilot shows savings, we get a cheaper scaling story; if not, we lose a few engineering days. Recommended decision: approve a scoped pilot, not adoption.

For engineering leadership: The notable change is that the multi-threaded runner now actually works (thread closure handling plus cache warmup), and the worker pool is driven by HttpServerConfig::setWorkers() — meaning concurrency becomes a single, familiar config knob rather than bespoke process orchestration. This is the first release where a real benchmark is meaningful. Risks: v0.x API churn (a refactor already landed in this release), dependency on PHP threading extensions, observability gaps versus Horizon/Supervisor, and bus-factor risk with first-time contributor activity. Mitigation: implement behind an internal TaskRunner interface, pin 0.2.3, and require a documented fallback to our existing worker fleet.

For the engineering team: Don't wire this into production paths yet. Build a spike that exercises the worker pool with setWorkers() against a representative CPU-bound job, measure latency percentiles and memory under sustained load, and confirm your PHP build supports the threading model. Capture cold-start improvement from cache warmup separately — that number alone may justify further investigation even if parallelism doesn't.

Ask: Two engineer-days for the spike plus a benchmark write-up, decision review at the next platform sync.