Speedfony Bundle Laravel Package

Product Decisions This Supports

• Prior-art validation, not dependency adoption. The package's core thesis—keep the application booted and reuse the compiled container across requests to eliminate per-request bootstrap cost—is now the industry-standard performance story (Laravel Octane, FrankenPHP, RoadRunner, Swoole). Use it as a reference implementation when writing an RFC, not as a library you ship.
• Build vs. buy vs. "already solved." If the roadmap item is "reduce p95 latency / raise throughput without re-architecting," the decision this package informs is: don't build custom persistent-worker plumbing, and don't buy this—adopt a maintained runtime (Octane/FrankenPHP) that ships the same idea with active security support.
• Framework-fit triage. This is a Symfony bundle, not a Laravel package. Laravel applications cannot register it in bundles.php or consume its CLI commands. The decision it directly supports is whether a Symfony shop on legacy 2.x/3.x should consider it versus migrating to a supported Symfony version and using runtime-native workers.
• Capacity/infra planning inputs. Persistent workers change the capacity model: memory becomes a long-lived per-worker budget rather than a per-request ceiling, worker count replaces PHP-FPM pm.max_children, and deployment requires graceful worker restarts. This package's "start/stop/inspect worker" CLI surface is a useful checklist for what your deploy pipeline must handle (rolling restarts, health checks, draining).
• Risk-register line item. If any team proposes it, this supports an explicit "reject with rationale" record: last release 2016-12-01, ~90 stars, no evidence of maintenance against modern PHP/Symfony.
• Use cases where the idea still matters: high-request-rate, bootstrap-heavy endpoints (large DI graphs, heavy config compilation), internal services with stable traffic, and cost-optimization efforts to reduce instance count at fixed latency SLOs.

When to Consider This Package

Consider it only under a narrow, unlikely set of conditions:

• You run Symfony 2.x/3.x (matching the 2016 release era) and are deliberately frozen on that stack—and even then, only as a spike, not a production dependency.
• You need a read-only, short-lived proof of concept to measure how much of your p95 is bootstrap time before committing engineering effort to a real runtime migration.
• You want a compact reference for the FastCGI worker protocol and how to wire worker lifecycle commands into a Symfony console.

Look elsewhere—decisively—when any of the following is true:

• You are on Laravel. This package is architecturally inapplicable. The correct evaluation target is Laravel Octane (Swoole/FrankenPHP/RoadRunner drivers), which is maintained, documented, and framework-native.
• You need security patches or PHP 8.x / Symfony 6–7 support. A package with no release since 2016 should be assumed incompatible and unpatched until proven otherwise; verify composer.json constraints and CI before spending any time on it.
• Persistent state is a concern. Long-lived workers retain static properties, container singletons, and per-request state by design. Without disciplined request-scoped resets, you get cross-request data leakage—a correctness and compliance problem, not just a bug. Modern runtimes ship sandbox/reset semantics and documented caveats; this package predates that hardening.
• You need observability, memory-leak recycling, graceful draining, or autoscaling hooks. Not present here; Octane/FrankenPHP/RoadRunner cover all four.
• You need vendor support or an SLA. Single-maintainer, dormant, MIT.

Practical guidance for the team: treat the repo as a 30-minute read, not a dependency decision. If you do spike it, bound it to one service, one afternoon, and a written comparison of measured bootstrap savings against the migration cost of a supported runtime.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated phpfastcgi/speedfony-bundle, which keeps a PHP application resident in memory between requests to skip repeated startup work and improve throughput. The underlying idea is sound and is now standard practice across the PHP ecosystem. However, this specific package is a Symfony component last released in 2016, with modest adoption (~90 stars) and no maintenance signal—so it is not a viable production dependency, and it does not apply to our Laravel codebase at all. Recommendation: do not adopt. If we pursue the performance goal, we should do it through a maintained, framework-native runtime (Laravel Octane or FrankenPHP), which delivers the same bootstrap savings with security support, observability, and graceful-deployment tooling.

For engineering (the short version):

• The value is the architecture pattern (persistent workers + reused compiled container), not the code. Use it as prior art in the Octane/FrankenPHP RFC.
• Do not add this as a dependency. Unmaintained since 2016; assume no PHP 8.x / modern Symfony compatibility and no CVE response.
• Framework mismatch is disqualifying for us: it's a Symfony bundle registered in bundles.php; our app cannot consume it.
• If we ever revisit, the spike must answer: (1) measured bootstrap share of p95, (2) memory-per-worker over 24h under load, (3) proof of request-scoped state isolation, (4) deploy story for graceful worker restarts.
• Ask: allocate the equivalent effort to Octane/FrankenPHP evaluation instead—same upside, materially lower long-term risk.