Symfony Laravel Package

Technical Evaluation

Architecture fit. luzrain/phpstreamserver-bundle wires PHPStreamServer — a PHP application/process server with a worker model and HTTP server — into a framework kernel. The v0.2.2 note is more architecturally significant than a typical patch: it moves deletion of uploaded files out of the request path and into a kernel.terminate listener, and adds tests asserting deletion occurs. That tells us the bundle has taken ownership of a responsibility PHP-FPM normally handles implicitly (cleaning upload_tmp_dir artifacts at request end). Under a long-running worker model, that ownership is mandatory — but it also means the bundle now sits in the request lifecycle's teardown path, which is a sensitive place for a pre-1.0 package to be.

Integration feasibility. Standard Composer install plus bundle/service-provider registration and server config (workers, listeners, ports, static assets). Feasible for a small platform team. The blocker is not install effort, it is that 0.2.x implies an unsettled public API and that this release changes runtime behavior at patch level.

Technical risk.

• Pre-1.0 semver: minor releases may break config/API; patch releases may change behavior (as this one does).
• Single-maintainer project with a small community — bus-factor and CVE-response risk.
• Cleanup correctness depends on kernel.terminate firing. On fatal error, OOM, timeout, or hard SIGKILL during shutdown, the listener may not run, leaving orphaned temp files. "Added tests" is a positive signal but tests presumably cover the happy path.
• Long-running workers introduce state bleed and memory growth that FPM masks; the bundle does not remove that class of risk.
• Overlap with Laravel Octane / RoadRunner / FrankenPHP — adopting this means choosing it as the HTTP/process layer, not layering it on top.

Key questions.

1. Does the kernel.terminate listener run on fatal error, request timeout, and SIGTERM during graceful shutdown — and is there a sweep/reaper for orphans?
2. What is the temp directory, retention policy, and max upload size story under workers?
3. Is this genuinely Laravel-native or a Symfony bundle consumed via a bridge? Which Laravel/PHP versions are supported, and which extensions (pcntl, sockets, event) are required? Windows support?
4. Benchmarks and resource profile versus Octane/RoadRunner/FrankenPHP on our workload shape.
5. License, security policy, release cadence, and issue-response history.
6. Zero-downtime reload semantics: how are in-flight requests drained on deploy?

Given the evidence base is a single patch note on a 0.2.x package, confidence in this assessment is low; treat it as a screening, not a recommendation.

Integration Approach

Stack fit. Fits a Laravel 10/11 + PHP 8.1+ containerized stack as a replacement for nginx + PHP-FPM, or as a process supervisor only. Because it overlaps functionally with Octane, pick one HTTP serving model per service — do not run both.

Migration path. Pilot-first, not fleet-first:

1. Run on one low-traffic internal service in a container, behind the existing reverse proxy.
2. Keep the FPM deployment path intact and switchable (feature flag / separate deployment target) for at least one release cycle.
3. Move upload- and download-heavy endpoints last, after explicitly validating the new kernel.terminate cleanup behavior under load and under induced failures.

Compatibility. Verify PHP version matrix and required extensions in CI before anything else; confirm framework version constraints resolve against our composer.lock. Pin exact versions (0.2.2, not ^0.2) and treat every patch as a code review item.

Sequencing.

1. Vendor/legal/security review and maintainer-health check.
2. Extension + PHP matrix validation in a throwaway container.
3. Spike on one service: worker config, static assets, logging.
4. Upload lifecycle validation, including forced worker kill and disk-usage assertions.
5. Graceful shutdown and deploy/reload runbook.
6. Observability (metrics, structured logs, worker health) before any widening.
7. Expand to additional services only after two clean release cycles.

Operational Impact

Maintenance. Highest ongoing cost is version discipline: pre-1.0 plus patch-level behavior changes means a named owner must read every changelog and re-run the upload-cleanup test suite on each bump. Keep a fork-or-replace contingency documented; the exit path back to FPM should remain exercised, not theoretical.

Support. Community support will be thin. Assume internal ownership: runbooks for worker restart, port conflicts, and disk pressure. Budget platform-engineering time for the first two sprints, tapering to steady-state maintenance.

Scaling. Scale by worker pool size and replica count; watch per-worker memory as requests accumulate and plan scheduled worker recycling. Zero-downtime deploys depend on graceful drain semantics, which must be verified rather than assumed. Temporary upload storage becomes a capacity-planning concern with a real I/O profile — treat the temp volume as a monitored resource with alerts, not an afterthought.

Failure modes.

• Temp upload files not deleted when kernel.terminate does not fire (fatal error, OOM, timeout, SIGKILL) → gradual disk exhaustion, then cascading write failures. Mitigate with an independent periodic reaper and disk alerts.
• Memory growth / state bleed in long-running workers → 5xx under sustained load.
• Workers failing to bind or release ports on restart → failed deploys.
• Log/telemetry gaps if output is not piped correctly from worker processes.
• Upstream patch releases changing request-teardown behavior without a minor version bump.

Ramp-up. Roughly one to two sprints for a platform engineer to reach production comfort, plus SRE training on the process/worker model (a genuine mental-model shift from FPM's request-per-process assumption). The v0.2.2 change is a good training case: it is exactly the kind of implicit runtime contract a team must now own explicitly.