- Can I use m6web/php-process-manager-bundle in a Laravel application?
- Practically speaking, no. Despite being requested as a Laravel/PHP package, m6web/php-process-manager-bundle is a Symfony bundle: its value comes from Symfony's Kernel, DependencyInjection compiler passes, Config component and EventDispatcher. It ships no service provider, no publishable config, no facade and no Laravel event mapping, so the bundle layer is inert inside a Laravel app. Only the small underlying core library is even nominally portable, and it is not maintained.
- How do I install m6web/php-process-manager-bundle?
- The original flow is a Composer require of m6web/php-process-manager-bundle, registering the bundle in a Symfony AppKernel, and declaring processes in Symfony YAML configuration. There is no artisan vendor:publish step and no config/*.php equivalent, because Laravel integration was never part of the design. The repository is archived and the last release dates to June 2016, so installation on a modern PHP runtime is not a realistic path.
- Which Laravel and PHP versions does this package support?
- None for Laravel, officially. The bundle targets the PHP 5.5 to 7.0 and Symfony 2.x to 3.x era, so a Laravel 10 or 11 application on PHP 8.2+ should expect untyped signature collisions with Symfony interfaces, removed functions and cache-layer drift. There is no version of this package written for modern PHP, and no upstream branch to upgrade to.
- Is m6web/php-process-manager-bundle still maintained?
- No. The repository is archived and explicitly marked DEPRECATED, with zero dependents and no releases since 2016. That means no security patches, no CVE response and no upstream pull-request path if you hit a bug. Any production incident traced to this package has no vendor answer.
- What is m6web/php-process-manager-bundle actually used for?
- It wraps a lightweight PHP process manager so you can declare long-running console commands as managed processes in YAML and control them from a single ProcessManager service. You get start, stop and restart operations, readable running state and exit codes, per-process stdout and stderr log files, and Symfony console and DI integration. It is process control for PHP workers, not a queue system and not a full supervisor.
- How do you configure a managed process with this bundle?
- Configuration lives in Symfony YAML, where each managed process is declared once with its command and its log file destinations for stdout and stderr. The ProcessManager service then reads that configuration to start, stop, restart and inspect the process. In a Laravel application there is no equivalent configuration tree, so you would be inventing a config/processes.php layer plus your own wiring anyway.
- How do I test long-running worker processes if I adopt this package?
- There is no Laravel testing story here: no Testbench service provider, no published config to assert against and no test suite you can trust on PHP 8. If you build your own process abstraction, test it behind an interface using Laravel's Process facade fakes so start, stop and restart calls are asserted without spawning real workers. Keep the archived bundle out of your test harness entirely.
- Does this bundle replace Supervisor or systemd?
- No, and that is the most important distinction. The bundle manages processes from inside your PHP application, so the process that would restart your crashed worker is itself a PHP process that can crash, which is the classic who-watches-the-watcher problem. Supervisor and systemd solve restart policy, backoff and boot persistence at the operating-system level for free.
- How does this compare to Laravel Horizon and queue:work?
- Horizon already handles worker lifecycle, scaling, balancing, metrics and graceful restarts for Redis queues, and queue:work covers the basic case. If your long-running PHP processes are queue workers, this bundle adds nothing that Horizon does not already do better and with active maintenance. Reach for it only if you have non-queue daemons, and even then Supervisor plus the Process facade is the stronger option.
- Is it safe to put an archived Composer package into production?
- Not by default. An archived 2016 dependency brings unmaintained transitive packages, no CVE response and likely PHP 8 incompatibilities, all for a capability Supervisor, Horizon and the Process facade already provide. If an exception is ever granted, define who owns the fork, pin it to your PHP version, add tests, and write down the exit plan before it reaches production.