Weave Code
Symfony Laravel Package
phpstreamserver/symfony
Runs Symfony applications on the PHP Stream Server, a high-performance application server with process management, PSR-7/PSR-15 support, and configurable worker pools. Provides Symfony integration, console commands, and configuration to replace PHP-FPM.
[READ ONLY] Symfony bundle for PHPStreamServer
Frequently asked questions about Symfony
- How do I install phpstreamserver/symfony?
- Install it with Composer, then register the bundle in your kernel and publish its configuration file. You then define your server settings such as worker pools, listeners, ports and static asset handling. Because the package is pre-1.0, pin the exact version rather than using a caret constraint and review each patch before upgrading.
- Is phpstreamserver/symfony compatible with Laravel, or is it Symfony only?
- It is a Symfony bundle for PHPStreamServer and is not a Laravel-native package. Laravel applications would typically reach for Laravel Octane with RoadRunner, FrankenPHP or Swoole instead of consuming this bundle through a bridge. Treat it as Symfony-first and evaluate Laravel equivalents if you are on the Laravel stack.
- Which PHP versions and extensions does PHPStreamServer require?
- The bundle targets modern PHP 8.1+ containerized stacks, but you should confirm the exact version matrix against your composer.lock before adopting it. Expect the process control and socket extensions such as pcntl and sockets to be required, with ext-event likely relevant for the event loop. Validate the full extension list inside a throwaway container in CI rather than assuming.
- How do worker pools and server configuration work in PHPStreamServer?
- Configuration is declarative: you define worker groups, HTTP listeners, ports and static asset rules in the bundle's config file. Workers are long-running PHP processes that handle requests, replacing the per-request model of PHP-FPM. This gives you process management and PSR-7/PSR-15 support, but it also means you must reason about state bleed and memory growth across requests.
- How does PHPStreamServer handle uploaded file cleanup compared to PHP-FPM?
- PHP-FPM implicitly cleans upload_tmp_dir artifacts at the end of a request, and this bundle takes ownership of that responsibility. Version 0.2.2 moved deletion of uploaded files out of the request path and into a kernel.terminate listener. That shift is mandatory under a long-running worker model, but it puts the bundle directly in the request teardown lifecycle.
- Does the upload cleanup listener run on fatal errors, timeouts or SIGKILL?
- Not reliably. The kernel.terminate listener depends on the kernel reaching its terminate phase, so a fatal error, OOM, request timeout or hard SIGKILL during shutdown can leave orphaned temp files behind. The release notes mention tests asserting deletion occurs, but those most likely cover the happy path. You should validate forced worker kills under load and add a sweep or reaper for orphaned files if you handle large uploads.
- Is a 0.2.x package safe to run in production?
- Treat it cautiously. Pre-1.0 semver means minor releases can break configuration or public API, and this project has already changed runtime behavior at patch level. Pin exact versions, treat every patch as a code review item, and pilot on a single low-traffic internal service behind your existing reverse proxy before widening adoption. Keep the PHP-FPM deployment path switchable for at least one release cycle.
- How does PHPStreamServer compare to Laravel Octane, RoadRunner or FrankenPHP?
- They occupy the same layer: an application or process server that replaces nginx plus PHP-FPM. Adopting PHPStreamServer means choosing it as your HTTP and process layer, not layering it on top of Octane or RoadRunner. Running two serving models in one service adds complexity for no benefit, so pick one per service. Benchmark against Octane, RoadRunner and FrankenPHP on your own workload shape before committing.
- Does PHPStreamServer support zero-downtime deploys and graceful reload?
- Graceful reload semantics exist through the worker model, but how in-flight requests are drained on deploy needs to be validated rather than assumed. Write an explicit runbook covering SIGTERM handling, worker drain timeouts and reverse proxy connection draining. Test it under real traffic in the pilot service before you rely on it for customer-facing deploys.
- Who maintains phpstreamserver/symfony and how actively is it developed?
- It is a single-maintainer project with a small community, which is the main bus-factor and CVE-response risk to weigh. Before adopting, check the license, security policy, release cadence and issue-response history on the repository. Also confirm what the added tests actually cover, since test coverage of teardown and failure paths is the key signal for a package that sits in the request lifecycle.
Weaver
How can I help you explore Laravel packages today?