Product Decisions This Supports
- Deployment/rollout automation: the package exists to let the application (not just an operator on a box) trigger a Horizon restart — useful when deploys are driven by CI/CD, Forge/Vapor deploy scripts, Kubernetes jobs, or admin UI actions.
- Build vs. buy on ops glue: replaces a hand-rolled artisan command or shell wrapper. The decision is cheap either way; treat this as "buy the 50 lines" rather than a strategic dependency.
- Roadmap signal — framework currency: v3.1.0 adds Laravel 12.x and PHP 8.4 support with no breaking changes. That is the main thing a PM needs from this release: it removes a blocker if your platform-standardization roadmap targets L12/PHP 8.4.
- Deployment runbook / incident response: relevant to "restart workers after config or code change" steps in the runbook — an argument for standardizing that step in code rather than ad-hoc SSH.
- Not a monitoring or queue-health decision. If a roadmap item is "visibility into failed jobs / queue throughput," this package does not address it (Horizon's dashboard, Pulse, or an APM integration do).
When to Consider This Package
Consider it when:
- You run Laravel Horizon in production (or plan to) and need restarts triggered from application code, a deploy pipeline, or an admin surface rather than an operator shell.
- You are standardizing on Laravel 12 / PHP 8.4 and want your ops dependencies to declare support rather than be pinned to older minors.
- You want the restart step expressed in PHP — testable, environment-agnostic, no SSH credentials in CI — instead of a bash one-liner in a deploy script.
- The team's tolerance for a small, single-maintainer utility is acceptable and you're willing to pin the version and own a trivial fallback.
Look elsewhere (or write the ~20 lines yourself) when:
- You do not use Horizon — plain
php artisan queue:restart covers you, and adding a Horizon dependency is pure overhead.
- You need guaranteed support, an SLA, or security review of every dependency — a micro-package with one primary maintainer will not clear that bar. Vendor it or reimplement.
- You need graceful draining guarantees, job-level control, or rollout orchestration (e.g., blue/green worker pools, per-queue supervision). This package is a trigger, not an orchestrator; use your platform's deploy tooling.
- Dependency hygiene is strict and the package has not had a release in a long stretch — check commit cadence before adopting, and re-check at each Laravel major.
Adoption conditions: pin to ^3.1, confirm the constraint resolves against your Laravel/PHP matrix, and keep a one-line fallback (Artisan::call('horizon:terminate')) documented in the runbook so removal is a non-event.
How to Pitch It (Stakeholders)
To executives: This is a small maintenance release for a small utility, not a platform change. It buys us one thing: our deployment tooling stays compatible as we move to Laravel 12 and PHP 8.4. No new features, no breaking changes, no migration work, no added operational risk beyond carrying one more low-impact dependency — which we cap by pinning the version and keeping a documented one-line replacement.
To engineering: v3.1.0 is a compatibility release — Laravel 12.x support and PHP 8.4 compatibility, no API changes, no deprecations. The surface area is one command; the value is that restarting Horizon becomes a first-class call from deploy scripts, CI, or an admin action instead of an SSH-and-pray step. Recommended handling: bump the constraint, confirm it resolves on our matrix, add a smoke test that the restart path is invoked during deploy, and record the fallback (horizon:terminate) in the runbook so we are never blocked by this dependency. Also flag the single-maintainer profile in our dependency review — we accept it because the cost of replacing it is an afternoon, not a sprint.