- How do I install pierotto/supervisor in a Laravel application?
- Install it with Composer: composer require pierotto/supervisor. It is a Laravel package, so after installation you publish any shipped configuration with php artisan vendor:publish and define the programs you want generated. Check the repository README for the exact config file and key names before wiring it into your deploy pipeline, since the published config schema is the source of truth for program definitions.
- Does pierotto/supervisor work with Laravel queue workers and Horizon?
- Yes, that is the primary use case: the package generates Supervisor program stanzas so you can run Laravel queue:work processes, scheduler workers, Horizon, or websocket daemons under supervisord instead of hand-writing INI files. You describe each worker in configuration and the generator emits the corresponding program sections. Grouping, added in 3.1.0, lets you scope supervisorctl commands to just that application's workers on a shared supervisord host.
- What does the group feature in pierotto/supervisor 3.1.0 actually do?
- Version 3.1.0 adds an optional group key that makes the generator emit a [group:<name>] section alongside your program stanzas, mapping directly to Supervisor's native group primitive rather than inventing a new abstraction. It is additive: when no group is configured the value defaults to an empty string and the generated output is unchanged from 3.0.0. The $group argument is appended as the last constructor parameter of SupervisorConfigGenerator with a default, so positional callers and container autowiring keep working.
- What Supervisor version do I need for group-scoped commands like supervisorctl update <group>?
- Group-scoped commands such as supervisorctl update <group> require Supervisor 3.2 or newer. On older hosts the argument may be rejected or behave differently, and the 3.1.0 release note does not state which. Verify the daemon version on every host before you change a deploy script that passes a group name, because a half-applied deploy can leave workers stopped.
- Will upgrading to pierotto/supervisor 3.1.0 change my existing supervisord config?
- If you never set the group key, no. The new option defaults to an empty string, so generated output is byte-for-byte identical to 3.0.0 for existing configurations. Output only changes once you explicitly configure a group name.
- How do I migrate existing ungrouped supervisor programs to a group without running duplicate workers?
- Plan a one-off migration: stop the existing ungrouped programs, run supervisorctl reread and update so the daemon picks up the new grouped definitions, then start the grouped programs. Do not simply run a group-scoped update on a host that still has the old ungrouped programs, because those will not be removed and you will end up with duplicate queue consumption, duplicated scheduled jobs, and doubled memory use. Script the steps so they are idempotent and check the Supervisor version first.
- How is the group name configured, and can one project declare multiple groups?
- The generator accepts the group name as an optional final constructor argument, and in a Laravel app it is typically read from package configuration, so confirm the exact config key in the README since the release note does not document it. Treat the value as untrusted: it flows into an INI section header and into supervisorctl invocations, so keep it to a simple alphanumeric-with-hyphens token rather than anything needing quoting or escaping. Whether a single project can declare more than one group, and whether a group can be removed cleanly later, is not covered by the release note and should be tested before you depend on it.
- Does pierotto/supervisor ship artisan commands to reread, update, and restart workers?
- The release note only describes configuration generation, so it is unclear whether the package ships artisan commands that wrap supervisorctl reread, update, and restart or whether teams hand-roll those calls in deploy scripts. Run php artisan list after installing to see which commands are actually provided. If nothing wraps them, keep those steps in your deploy tooling where they can be gated on the Supervisor version.
- What are the alternatives to pierotto/supervisor for managing Supervisor in Laravel?
- The alternatives are hand-written supervisord INI files, templates rendered by a deploy tool such as Deployer or Envoyer, or Laravel Horizon if you only need Redis queue workers and are happy with its own process management. This package's value is centralizing program definitions in Laravel configuration so configs are regenerated rather than edited by hand, plus the 3.1.0 group support for shared daemons. If each application already has a dedicated supervisord instance, groups buy you naming symmetry rather than real isolation.
- Is pierotto/supervisor actively maintained and well tested?
- It is a single-author package with no prior technical assessment on record, so treat maintenance and test coverage as open questions and check recent commit activity, issue response times, and the test suite before adopting it. The 3.1.0 change itself is small and additive, which limits upgrade risk. If you depend on it in production, pin the version in composer.json and keep a checked-in copy of the generated Supervisor configs so you can fall back to hand-managed files.