Supervisor Bundle Laravel Package

Technical Evaluation

Verdict up front (updated for v2.0.0): The verdict does not change. This remains a Symfony bundle with zero ecosystem traction, and it remains a poor dependency for a Laravel product. The v2.0.0 release is meaningful for one reason — per-server auth — and marginal for the rest (Symfony 8 / PHP 8.2+, hidden_processes, restart). It also introduces a hard major-version break on a package that had no prior API stability to speak of. Recommendation stands: do not adopt as-is; treat it as a build-vs-buy input, and if we port, pin the fork before the next major lands.

What actually changed in v2.0.0

• Per-server auth (material): the connection layer now models credentials per configured server. This partially answers the biggest open question from the prior assessment (Q4, auth story). It is the single feature that could justify re-running the spike rather than writing the client from scratch.
• PHP 8.2+ / Symfony 6.4, 7, 8 (constraint change): raises the runtime floor and widens framework support. Good hygiene, but it is also a compatibility cliff for anyone on 8.1 — and a signal that minor-to-major jumps happen here.
• hidden_processes (presentation concern): a filtering layer for excluding internal programs (e.g. sshd, cron wrappers) from listings. Useful for a UI, but it is exactly the kind of opinionated logic we would rather own than inherit.
• Restart by: listed as a feature, but restart was already within the XML-RPC surface described previously. Confirm whether this is a new API method, a UI action, or a fix — the release note is ambiguous.
• New contributor: one external contributor, one PR, first contribution. Marginally better than a pure single-source package; nowhere near "community-maintained."
• Metadata anomaly resolved: the previously flagged future-dated release entry is superseded by an attributable, PR-linked tag. Recency is now a verified signal — it is the health signals that remain unverified.

Architecture fit

• Unchanged: Bundle registration, DI Extension, Configuration tree, Symfony HTTP client/event-dispatcher conventions. None of that is consumed by Laravel's container. Laravel's shared Symfony components (http-foundation, console, process, finder) do not include framework-bundle, which is where the bundle's assumptions live.
• The porting thesis is slightly improved by v2.0.0: per-server auth implies a connection/config value object that is closer to framework-agnostic than v1's shape. That is a hypothesis to validate in the spike, not an assumption to plan around.
• hidden_processes cuts the other way: the package now carries opinions about what to display, not just transport. That is logic we would port and then immediately diverge from, since our UI's notion of "internal" is our own.
• Scope mismatch persists: this is ops tooling for arbitrary Supervisor programs, not Laravel queue worker management. Horizon remains the answer for the latter.

Integration feasibility

• Same two paths, same trade-off: (a) depend on the bundle and instantiate non-bundle service classes in a Laravel provider; (b) vendor/port the XML-RPC client. v2.0.0's per-server auth makes (a) marginally more attractive for the spike, because credential handling is the fiddly part we'd otherwise write. It does not make (a) attractive for production — we'd still be coupled to a zero-adoption package's internal class layout across a major-version boundary.
• Per-server auth is only as good as the endpoint. Supervisor's XML-RPC auth story depends on [inet_http_server] basic auth (or a reverse proxy in front of it). Verify explicitly whether the package's auth maps to standard HTTP basic auth against inet_http_server, or to something custom. If it is real basic auth, our threat model improves from "unauthenticated process-execution path" to "single shared secret, no transport security unless TLS is terminated in front" — better, still not solved.
• Unix sockets remain preferable to TCP even with auth. Auth does not fix the "RCE-adjacent surface" characterization; it narrows it.

Technical risk

• Adoption risk (high, unchanged): no evidence of dependents, third-party validation, or downstream bug reports. Every defect is still ours.
• Maintainer risk (high, marginally improved): one external contributor and a shipped major. Forward-looking, but the bus factor is effectively 1–2 and there is no support channel.
• API churn risk (new, medium-high): 1.0.6 → 2.0.0 on a package with ~no users. Major bumps at this adoption level usually mean the API is still being discovered, not stabilized. Any port must pin an exact tag and treat upstream upgrades as deliberate, reviewed events — not composer update.
• Runtime floor (new, low-medium): PHP 8.2+ and Symfony 6.4+ minimums. Fine for us if all target hosts are on 8.2; needs confirming against the base image and any legacy service hosts before the spike is scheduled.
• Protocol risk (medium, unchanged): XML-RPC is stable but legacy, and synchronous calls block a PHP-FPM worker.
• Log tailing risk (medium, unchanged): still a polling primitive. v2.0.0 does not advertise cursor/offset improvements. Verify before building any UI on it.
• License (low, unchanged): MIT, clean for commercial use and forking. Forking is the intended end state if we adopt.

Key questions

1. (Unchanged, still the gating question) Are we solving queue-worker supervision (Horizon) or arbitrary process control on managed hosts? If the former, stop here.
2. (New) Does "per-server auth" mean HTTP basic auth against Supervisor's [inet_http_server], a reverse-proxy header, or a custom scheme? Does it support unix sockets with no auth?
3. (New) What breaks between 1.0.6 and 2.0.0 — namespace changes, config key renames, dropped Symfony/PHP support only? This determines whether a port built on v1 snippets is salvageable.
4. (New) Is hidden_processes config-only filtering, or does it alter the returned program list? Filtering belongs to us, not the transport.
5. (Updated) Now that a connection/config object exists with per-server credentials, is the XML-RPC core more cleanly separable from the Symfony bundle classes — or does the config tree now pull DI deeper into the client?
6. (New) Is this an actively maintained package with a roadmap, or a one-off modernization PR? Watch for v2.0.1/v2.1 within 90 days as the tell.
7. Is there a test suite runnable against a containerized Supervisor to establish a baseline before we depend on it?
8. How is log tailing implemented — cursor offsets or full reads — and does it block the request worker?

Integration Approach

Stack fit

• Unchanged: poor as a drop-in Laravel dependency, acceptable as a logic donor. v2.0.0 adds one genuinely reusable piece (per-server credential handling) and one piece we'd discard (hidden_processes presentation filtering).
• Recommended shape stands: internal acme/supervisor-client with a typed API (listPrograms(), startProgram(), stopProgram(), restartProgram(), tailLog()), a SupervisorManager resolving named connections from config, socket and http transports, per-connection credentials.

Migration path

1. Re-run the spike (1–2 days, unchanged budget): stand up Supervisor in Docker, install v2.0.0 pinned exactly, and drive the non-bundle classes from a bare PHP script. The new acceptance criterion: confirm per-server auth works end-to-end against a real [inet_http_server], over both socket and HTTP.
2. Decision gate: if the core is still not separable, or if per-server auth only works via the Symfony Configuration tree, stop and vendor the XML-RPC calls directly. The RPC vocabulary is small and documented; auth via basic headers is a few lines.
3. Port: Laravel service provider + config/supervisor.php (per-host: transport, endpoint, credentials, timeout) + facade. Timeouts: connect 1s, read 5–10s.
4. Surfacing: Artisan commands first (supervisor:status, supervisor:restart {program}), then a read-only UI. Writes behind authorization gates and audit logging from day one — auth at the RPC layer does not substitute for auth in our app.
5. Pin and isolate: exact version, lockfile committed, composer audit in CI, and a conflict rule against the next major so an unattended update cannot re-break us.
6. Replace-or-keep review at 90 days: if the ported client is under ~500 LOC (still likely), drop the upstream dependency entirely and own the code.

Compatibility

• New hard constraints: PHP 8.2+, Symfony 6.4/7/8. Verify our runtime and base image before scheduling; a PHP 8.1 host anywhere in the fleet blocks the spike.
• Transitive symfony/framework-bundle risk is unchanged and now spans a wider declared range — pin carefully or isolate.
• ext-xmlrpc is absent on modern PHP; confirm v2.0.0 uses a userland XML-RPC library rather than the removed extension. The PHP 8.2 floor makes the extension route impossible, which is mildly reassuring but worth asserting.
• TLS: if per-server auth uses basic auth over TCP, terminate TLS in front of the RPC endpoint. Do not send credentials over a plaintext listener beyond loopback.

Sequencing

• Phase 1: read-only (status/list, log tail) with auth wired in from the start — this is the phase the release validates.
• Phase 2: lifecycle writes (start/stop/restart) on non-production hosts.
• Phase 3: production enablement with RBAC, rate limiting, and confirmation on destructive actions.
• Do not block any roadmap item on this. It remains an internal tooling enabler.

Operational Impact

Maintenance

• Owning a fork remains the realistic steady state; v2.0.0 does not change the arithmetic. ~2–4 hours/month for bumps and fixes, plus a one-off review whenever upstream ships a major.
• Pin exact versions without exception. A package that jumped 1.x → 2.0 with essentially no user base is a package whose API is still moving; ^ ranges here are a self-inflicted outage.
• Record the upstream tag the port was derived from (v2.0.0) and the XML-RPC methods consumed, so a future migration to supervisorctl subprocess calls is mechanical.

Support

• Still no upstream SLA, no CVE history, no support channel. The new contributor is a positive signal, not a support contract. On-call absorbs incidents.
• The added hidden_processes and auth layers are behavior we did not write. Anything opaque in the credential path (retries, header shaping, fallback to anonymous) is a security-relevant unknown — read that code before shipping, not after.

Scaling

• Unchanged: per-host, not per-cluster. N hosts → N connections, N credential sets, N failure domains. The UI must model hosts explicitly.
• Synchronous XML-RPC consumes a worker. Auth adds a negligible cost; polling every few seconds across 20 hosts does not. Cache status reads (5–10s TTL); push log tailing to a queue + websocket if it goes interactive.
• Credential distribution now becomes an operational concern: per-server secrets need a store and rotation story. That is new surface introduced by the release, not eliminated by it.

Failure modes

1. Supervisor unreachable → per-host "unavailable" state, never a 500 into the UI.
2. Silent partial failure — startProcess on a running program returns a fault; ensure it surfaces rather than lying about state.
3. Auth misconfiguration (new) — wrong or missing credentials now yield a distinct failure class from "endpoint down." The UI must distinguish 401 from timeout, or operators will chase the wrong problem.
4. Blocking calls under load — hard timeouts plus a per-host circuit breaker.
5. Exposure — even with per-server auth, an authenticated RPC endpoint is a process-execution path. Prefer unix sockets; if TCP, loopback-only, TLS in front, staff-only middleware on our routes.
6. Log read races — offset handling under rotation; tolerate gaps and duplicates.
7. Version drift — pin Supervisor in the base image alongside the pinned client; a Supervisor upgrade can change fault responses and log semantics.

Ramp-up

• Still ~half a day to understand a ported client, ~1 day to productive on the Artisan commands, for a Laravel-fluent developer.
• Slightly higher than before: per-server credential handling plus a major-version diff to read is maybe a half-day more, but only for whoever owns the port.
• The real cost remains Supervisor domain knowledge — program groups, autorestart, numprocs, log rotation, supervisorctl vs. RPC semantics. Budget an internal writeup; the package does not teach this.
• Net assessment: v2.0.0 strengthens the case for a 1–2 day spike and does not move the needle on adopting it as a direct Composer dependency in a Laravel app. The answer there is still no.