Supervisor Laravel Package

Product Decisions This Supports

• Deployment isolation as a product capability. 3.1.0 adds an optional group option that emits a [group:<name>] section into the generated supervisor config, so processes become addressable as myapp:worker. This turns "can we safely run several of our apps on one box?" from an infrastructure gamble into a supported configuration.
• Hosting tier / cost-per-tenant decisions. Group-scoped restarts replace machine-wide supervisorctl stop all / supervisorctl reload. That means deploys no longer bounce every project sharing a supervisord. For a PM, this is the difference between "one VM per customer/app" (expensive, simple) and "N apps per VM with scoped deploys" (cheaper, previously risky). The release is what makes the cheaper tier defensible.
• Deploy pipeline design. The documented workflow — stop myapp:* → deploy → reread → update myapp → start myapp:* — is a concrete, reviewable contract for the deploy runbook and CI scripts. Note the release explicitly calls out that reload restarts the daemon and therefore every project; that is a policy decision to write into the runbook, not just a code change.
• Build vs. buy for config generation. This is a small, deterministic config generator: your program definitions live in app config, the package emits .ini you can commit and diff. Adopt rather than hand-roll a template layer — but scope it honestly, since it generates configuration and does not supervise processes.
• Roadmap sequencing. Two gating items belong on the roadmap before this becomes a shipped feature: (1) confirm supervisor >= 3.2 in base images, since group-targeted update requires it; (2) schedule the one-off migration for existing projects, because adding a group renames processes and a group-scoped update will not remove the old ungrouped ones. New projects can adopt group immediately; existing ones need a planned cutover, not a drive-by config commit.
• Risk posture. 3.1.0 is additive and backward compatible — group defaults to an empty string, output is byte-for-byte identical to 3.0.0 when unset, and $group is the last constructor argument with a default. The upgrade itself is a no-decision; the adoption of the option is the decision.

When to Consider This Package

Consider it when:

• You run supervisor-managed long-lived processes (queue workers, websocket/daemon loops, scheduled consumers) and want their definitions in version-controlled app config rather than hand-edited .ini files on servers.
• You share a supervisord daemon or a host across multiple projects and need deploys to touch only the deploying project. This release is the specific reason to look now.
• You value reproducible output: deterministic, diffable config means config changes show up in code review and CI instead of appearing on a box at 2am.
• You are standardizing deploy scripts and want a documented, testable supervisorctl sequence rather than tribal knowledge.

Look elsewhere when:

• Your process management is already owned by Kubernetes, systemd, Laravel Forge/Envoyer, Vapor, or a PaaS. Groups solve a problem those platforms already solve at a different layer.
• You need runtime supervision, health checking, or log rotation management — this generates configuration; it does not supervise.
• You are pinned below supervisor 3.2 and cannot upgrade. Group-targeted update will not work; you can still emit grouped config, but you would be adopting the file format without the operational benefit.
• You run exactly one app per daemon. Groups add naming surface (myapp:worker) with no isolation payoff; leave group unset and keep the byte-for-byte 3.0.0 behavior.

How to Pitch It (Stakeholders)

For executives: This release lets us safely pack more applications onto each server without deploys interfering with each other. Today a config reload can restart every project on a machine; with process groups, a deploy restarts only its own processes. That directly supports a lower cost-per-app hosting tier and reduces the blast radius of a routine deploy — fewer cross-team incidents, shorter and more predictable deploy windows. The upgrade costs nothing: no code changes, no breaking changes, identical output unless we opt in.

For engineering: 3.1.0 is a purely additive patch. group defaults to an empty string and $group is the trailing constructor argument with a default, so an untouched project generates byte-for-byte the same config as 3.0.0. Setting group emits a [group:<name>] section and lets us address processes as myapp:worker, so we replace stop all / reload with stop myapp:* → update myapp → start myapp:*. Two constraints to plan around: group-targeted update needs supervisor 3.2+, and migrating an existing project renames its processes — the old ungrouped ones survive a group-scoped update, so the README's one-off migration must be executed deliberately rather than folded into a routine deploy.

The ask: adopt group for all new projects immediately; verify supervisor 3.2+ across base images; and schedule the documented migration for existing projects as tracked work rather than an opportunistic config edit.