m6web/php-process-manager-bundle
A Symfony bundle for managing long-running PHP background processes and workers. Configure commands, start and stop them, monitor status, and handle graceful restarts with logging, so daemons and queue workers stay supervised without custom glue code.
Architecture fit. Low. Despite the ticket framing this as a "Laravel/PHP package," it is not a Laravel package at all — it is a Symfony bundle (m6web/php-process-manager-bundle) that provides dependency-injection wiring, configuration trees, and console commands around the m6web/php-process-manager core library. It assumes Symfony's Kernel, DependencyInjection, EventDispatcher, and Config components. Laravel's service container is PSR-11-ish but not Symfony's compiler-pass model, so the bundle's actual value-add (the bundle) is inert in a Laravel app; only the underlying library is even nominally portable.
Integration feasibility. The functional domain is "supervise long-running PHP worker processes: start/stop/restart, PID tracking, timeouts, event hooks." That capability is already covered in our stack by three cheaper, maintained layers: Supervisor or systemd (process supervision, restart policy, backoff), Laravel Horizon / queue:work (worker lifecycle, scaling, metrics), and Symfony\Process via Laravel's Process facade (spawning and per-command control). Adopting this bundle would mean reimplementing a bespoke supervision daemon in PHP that we then have to keep alive — the classic "who watches the watcher" problem, solved for free by Supervisor.
Technical risk. High, and concentrated in lifecycle rather than code quality. Repo is archived, explicitly marked DEPRECATED, last release 2016-06-23, zero dependents. It targets the PHP 5.5–7.0 / Symfony 2.x–3.x era; a Laravel 10/11 codebase on PHP 8.2+ will hit signature incompatibilities, removed functions, and unmaintained transitive dependencies. There will be no security patches, no CVE response, and no upstream PR path. Any production incident traced to this package has no vendor answer.
Key questions.
Stack fit. Poor for Laravel. There is no service provider, no config publishing, no facade, no Laravel-idiomatic event mapping. The bundle's EventDispatcher hooks would need an adapter to Laravel's dispatcher; its configuration schema is Symfony YAML/XML, not config/*.php. The core library's PID-cache abstraction (Doctrine Cache era) has no cache backend we'd want to keep.
Migration path. None from upstream — there is no upgrade path from the archived 2016 release, only a fork. If the underlying capability is genuinely required, the realistic path is: (a) document current worker supervision needs, (b) implement on Supervisor + Horizon + Process facade, (c) only if a gap remains, port the ~small surface of the core library into an internal app/Support/ProcessManager namespace, pinned to our PHP version, with tests.
Compatibility. Assume breakage on PHP 8+: each()-era iteration, untyped signatures colliding with Symfony 5/6 interfaces, Serializable misuse, and PSR-6/PSR-16 drift in the cache layer. The bundle also expects Symfony's kernel.project_dir-style parameters that Laravel does not expose.
Sequencing (if pursued at all). 1) Requirements spike: enumerate every worker and its restart/timeout/backoff semantics. 2) Baseline on Supervisor + Horizon and measure whether anything is actually missing. 3) If a gap exists, prototype the internal port behind an interface, with a Supervisor-based implementation as the default and the port as a fallback. 4) Load-test failure modes (SIGKILL, OOM, worker wedged on I/O) before any rollout. 5) Ship behind a feature flag, never as the sole supervision mechanism.
Maintenance. Effectively total. Abandoned upstream, zero dependents, no release cadence to track — but also no maintainer to inherit from. Every fix becomes our fork's responsibility, including PHP minor-version compatibility, which for a supervision layer means touching the thing that keeps production workers alive.
Support. None. No upstream issue triage, no security advisories, no community to escalate to. Internal on-call would be the sole escalation path for a component whose failure mode is "workers stop being restarted."
Scaling. The supervision model is single-host, PID-file and local-cache based. It does not understand containers, ephemeral PIDs, pod restarts, or horizontal worker fleets — the exact environments we run. In Kubernetes, a PID file from a prior container generation is meaningless and actively misleading. It would need replacement the moment we scale past one box, which we already have.
Failure modes. PID reuse causing a healthy process to be killed (or a dead one to be reported alive); stale cache entries after unclean shutdown causing duplicate workers; the manager process itself dying and taking supervision with it (no external watchdog); timeouts misfiring under PHP 8 timing/runtime changes; silent no-restart after an unhandled exception in the event subscriber. Each of these is a production availability incident with no vendor remedy.
Ramp-up. The conceptual model is learnable in a day, but there is no current documentation, no maintained examples, and no internal precedent. Real ramp-up cost is not learning the tool — it's the archaeology of a 2016 Symfony 2 bundle and the institutional knowledge required to own a fork indefinitely.
Recommendation. Do not adopt. The 0.53 score reflects star count from a past era, not present fitness; the opportunity score of 0.27 is the more honest signal. Treat the repository as reference material for how process supervision was modeled in PHP a decade ago, and standardize on Supervisor/systemd + Horizon + Process for the underlying need. If a specific gap emerges, scope it explicitly and build a thin internal abstraction rather than inheriting an archived dependency.
How can I help you explore Laravel packages today?