Supervisor Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for process-control tooling. The core answer is unchanged: the package wraps Supervisor's XML-RPC verbs (list, start, stop, restart, tail) that sit behind any "manage my queue workers" admin screen. v2.0.0 does not widen the verb set beyond adding restart as a first-class, documented operation — it remains a thin client, so the buy-side value is still "a day of writing avoided," not "a capability we can't build."
• Roadmap for an internal ops/admin panel. v2.0.0's per-server authentication is the one feature that materially changes scope: a single panel can now target multiple supervisord endpoints (staging vs. prod, or several worker hosts) with distinct credentials instead of one global credential. That makes a multi-environment "restart the stuck worker" screen a more realistic milestone than it was under v1's single-endpoint model.
• Automated remediation features. Unchanged and slightly reinforced: start/stop/restart remain the API surface behind a "self-healing" epic (detect dead worker → restart → page a human on repeat failure). Nothing in v2 adds health-check or backoff logic; we still own the policy layer.
• hidden_processes as a product-scoping lever. New in v2.0.0, this lets us curate which Supervisor programs are visible to the panel. For a developer-facing dashboard this is a genuine product decision: it turns "expose everything supervisord knows about" into "expose the programs this audience should see," which reduces accidental blast radius and simplifies the UI.
• Deployment and release tooling. Per-server auth makes post-deploy worker restarts across environments more tractable — credentials per target rather than one shared secret in a hook — but we would still be shipping a Symfony bundle's worth of surface area for a supervisorctl restart call.
• Framework strategy decision (worse, not better). v2.0.0 raises the floor to Symfony 6.4/7/8 and PHP 8.2+. It is still a Symfony bundle, not a framework-agnostic library. For a Laravel codebase this is now a harder sell than before: more Symfony contracts to carry, and any Laravel service still on PHP 8.1 cannot use it at all.
• Upgrade decision for any v1 spike. v2.0.0 is a major version bump with an elevated platform floor and a changed configuration shape (per-server auth). If anyone prototyped v1.0.6, that work needs re-validation against v2, not a dependency bump. A v1→v2 migration path is not worth planning for a package we have not adopted.
• Observability/log-tailing scope. Still unchanged: tail plus hidden_processes points at curated developer dashboards, not log aggregation. Retention, search, and alerting stay with our existing logging stack.

When to Consider This Package

Consider it only when all of the following hold:

• The application is Symfony 6.4, 7, or 8 on PHP 8.2+ (or you are willing to extract and vendor the XML-RPC client layer). In a Laravel codebase, treat it as reference material, not a dependency.
• You already run Supervisor with the XML-RPC/inet_http_server endpoint enabled — the package adds nothing on systemd, Kubernetes, or a platform queue runner.
• You need multiple Supervisor endpoints under distinct credentials; per-server auth is the strongest new reason to pick this up rather than write your own client, since it is the part a quick in-house wrapper usually gets wrong first.
• You want a curated subset of programs exposed to a UI, which hidden_processes now gives you without a custom allowlist.
• You accept still-significant supply-chain and support risk: zero stars, zero dependents, effectively single-maintainer, no downstream validation, and no third-party security review. v2.0.0 is a mild positive signal — a major release plus a first outside contributor — but a second contributor on one PR is not a maintenance guarantee.
• The blast radius is contained: these APIs stop production workers. Admin-gate, audit, and ship read-mostly in v1 of any internal build.

Look elsewhere when:

• You want first-class queue management in Laravel — Horizon (Redis) or a small custom supervisorctl wrapper remains lower risk and framework-native.
• Your runtime is PHP 8.1 or Symfony ≤ 6.3 — you would be pinning an older major of an unproven package, which is the worst of both worlds.
• You need real process supervision guarantees; use supervisorctl, Supervisor's own web UI, or a maintained monitoring tool rather than an unvetted client.
• You need log search, retention, or alerting — tailing is not an observability strategy.
• Your policy requires dependency provenance, active maintainers, or a security review trail. Zero dependents and zero stars still means nobody has stress-tested this against our threat model.

How to Pitch It (Stakeholders)

For executives (30 seconds): This is a small, MIT-licensed utility that lets an application start, stop, restart, and read logs from Supervisor-managed background workers through Supervisor's own API. The new v2.0.0 adds two things that matter to us: support for multiple servers with separate credentials, and a way to hide programs we don't want shown in an admin screen — both of which make an in-app "restart the stuck worker" button for on-call engineers more plausible without SSH. It is still early-stage and unproven — zero stars, zero downstream users, one outside contributor — so my recommendation is unchanged in shape: treat it as a spike, not a commitment. Cost is near zero; the risk is operational and contained by keeping the first release read-only and admin-gated.

For engineering (the honest version): v2.0.0 is a major: Symfony 6.4/7/8 and PHP 8.2+ only, a reworked config for per-server auth, an added hidden_processes filter, and restart promoted to a documented operation. The genuinely useful additions are per-server credentials (multi-environment targeting) and program filtering (UI scoping). Everything else is table stakes we could write ourselves. It is still a Symfony bundle — it does not drop into Laravel, and v2 raises the platform floor, so the "carry Symfony contracts for an XML-RPC client" objection is stronger, not weaker. Recommendation: prototype against a staging supervisord, start on v2.0.0 if we prototype at all (do not plan a v1→v2 path), gate every mutating call behind an admin permission plus an audit log, ship read-only list + tail first, and only then decide whether start/stop/restart earns a place in the runbook.