Weave Code
Speedfony Bundle Laravel Package
phpfastcgi/speedfony-bundle
Speedfony Bundle integrates PHP FastCGI with Symfony, enabling internal requests to be dispatched directly to PHP-FPM for faster subrequests, parallel processing, and reduced response times. It provides a simple service-based API for adding FastCGI-powered workflows to Symfony apps.
A bundle to integrate a FastCGI daemon with the symfony2 framework
Frequently asked questions about Speedfony Bundle
- Is phpfastcgi/speedfony-bundle a Laravel package or a Symfony bundle?
- It is a Symfony bundle, not a Laravel package. Laravel has no bundles.php, no Kernel::registerBundles(), and no bundle lifecycle, so the advertised drop-in registration surface simply does not exist in a Laravel application. You cannot install it into a Laravel project and expect it to do anything. For Laravel, the equivalent value proposition is Laravel Octane, which is first-party, maintained, and has Laravel-aware lifecycle hooks.
- Which PHP and Symfony versions does Speedfony Bundle support?
- The last release was 2016-12-01, which puts it in the PHP 5.6 and 7.0 era with Symfony 2.8/3.x conventions. Expect incompatibilities with PHP 8.x and Composer 2 resolution failures against modern symfony/* constraints. There are no published releases targeting Symfony 5, 6, or 7, and the bundle predates Flex-era conventions. Verify anything you read about it against the actual composer.json before planning around it.
- How do I install and register Speedfony Bundle with Composer?
- In principle you would require phpfastcgi/speedfony-bundle, register it in AppKernel::registerBundles() or bundles.php, and start the FastCGI worker via the bundled CLI tooling. In practice Composer 2 will likely refuse the dependency graph against a modern Symfony install, forcing you to pin the entire framework and PHP runtime to match. That turns a bundle install into a platform-wide decision. Treat it as a vendored fork rather than a normal Composer dependency.
- What does Speedfony Bundle actually do, and will it make my app faster?
- It boots the Symfony kernel once inside a persistent FastCGI worker and reuses the compiled container and services across many requests, removing a large share of PHP's per-request bootstrap overhead. That is a real optimization, but only if bootstrap is genuinely your bottleneck. Baseline and profile your application first, and exhaust cheaper wins such as OPcache, preloading, JIT, and horizontal scaling before adding a second serving model to production. On most applications the measured gain will be smaller than the operational cost.
- What are the maintained alternatives to Speedfony Bundle?
- For Laravel, use Laravel Octane; for Symfony, use Symfony Runtime with FrankenPHP or RoadRunner. All three are actively maintained, documented, and cover the same kernel-reuse and worker-amortization idea with proper lifecycle hooks. They also ship request-boundary handling, sandboxing, and supervision tooling that this bundle leaves to you. Choosing any of them means you are not owning a nine-year-old fork.
- Is it safe to reuse a booted Symfony kernel across many requests?
- Not automatically. Process-per-request isolation is what the framework assumes, so persistent workers expose leaking static and global state, stale compiled containers after deploy, Doctrine EntityManagers accumulating managed entities, unbounded memory growth, and superglobal or session bleed between requests. A defect in the request boundary is a cross-user data leak, not just a performance regression. You need explicit reset logic and a hard blast-radius limit before this touches real traffic.
- Does Speedfony Bundle replace PHP-FPM or run alongside it?
- It runs alongside PHP-FPM rather than replacing it, which means two serving models in production. That creates behavioral drift between the two paths and no single source of truth for request semantics. You also inherit FastCGI process management as an operational surface: socket ownership, port allocation, supervision, drain behavior, timeouts, and nginx upstream configuration. Budget for that work explicitly, because the bundle exposes it rather than abstracting it.
- How do I test a persistent-worker app for state leaking between requests?
- Drive the worker with repeated sequential requests that deliberately exercise services holding state, then assert that no user, session, or entity data survives into the next request. Run long soak tests with memory profiling to catch unbounded growth, and force a container rebuild mid-run to simulate a deploy. Your existing PHPUnit and PHPStan setup should run against the new runtime before any code freeze discussion. If you cannot write that test suite, you cannot safely ship this.
- Is phpfastcgi/speedfony-bundle still maintained and secure?
- No. It has been unmaintained for roughly nine years, which means no CVE response, no security advisories, and no PHP 8 patches. Total ownership cost lands on your team: fork, vendor, patch, and re-audit on every PHP or Symfony upgrade. Only consider it for a frozen Symfony 2.8/3.x service that cannot move frameworks, and only with a named engineer and a named budget owning it.
- What does running the Speedfony FastCGI worker in production involve?
- Beyond starting the worker with the bundled CLI tooling, you own process supervision, restarts on deploy, draining connections, timeout tuning, and monitoring for memory growth. You also need a rollback path and a traffic split so a bad release does not take the whole service down. Because there is no incremental migration path, plan a timeboxed spike on one non-critical service with a written go/no-go gate rather than a rollout on the monolith.
Weaver
How can I help you explore Laravel packages today?