Laravel Task Runner Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. Instead of building a bespoke "run this script on that server" admin feature—auth, parameter passing, output capture, remote transport—this package gives you a Laravel-native primitive for it. The decision it informs: do we invest engineering sprint time in an internal automation layer, or adopt a small MIT package and spend that time on product?
• Feature scope: exposing safe operational actions to non-engineers. Because tasks are defined in PHP/Blade with declared inputs rather than raw shell pasted into a terminal, you can decide whether to surface "Restart queue workers," "Rotate logs," "Run tenant export," or "Clear cache on staging" as buttons in an admin panel—with Laravel's existing authorization, validation, and audit hooks around them.
• Roadmap: local vs. remote execution parity. The local-or-remote capability is the differentiator. It supports the decision to keep one task definition that runs identically on a developer machine, a staging box, and production, rather than maintaining divergent bash scripts per environment.
• Use-case triage. Good fit: on-demand maintenance tasks, backup/restore, log and disk diagnostics, cache/queue operations, multi-tenant data fixes, environment sync, scheduled jobs that need SSH. Poor fit: anything requiring orchestration state, rollback semantics, or fleet-wide idempotency—those belong in Deployer/Ansible/CI.
• Deployment and provisioning strategy for small fleets. For teams with a handful of Laravel servers and no configuration-management investment, this is a credible "good enough" answer that avoids standing up Ansible or Terraform for what is really five scripts.
• Templating and parameterization decisions. Blade-style composition means scripts become reviewable, diffable, and reusable with variables—supporting a decision to standardize operational runbooks in the app repo rather than in tribal knowledge or wiki pages.

When to Consider This Package

Adopt when:

• You are a Laravel/PHP shop and the people writing and owning the scripts are PHP developers, not dedicated ops/SRE.
• The task surface is bounded: a handful of servers, a modest set of named tasks, human- or scheduler-triggered rather than continuous.
• You want tasks versioned alongside the application, code-reviewed in the same PR flow, and wrapped in Laravel auth, logging, notifications, and queues.
• You need the same task to run locally and over SSH without duplicating script logic.
• You are comfortable pinning a version and treating the package as a thin convenience layer over spatie/ssh / Symfony Process.

Look elsewhere when:

• You need real orchestration: rolling deploys, health checks, rollback, multi-host fan-out with ordering and idempotency. Use Laravel Envoy, Deployer, Ansible, or your CI/CD system.
• You need a hardened control plane with RBAC, approval workflows, full audit trails, and secrets management—shell execution is a security-sensitive surface and this package is a building block, not a governance layer.
• Your team is polyglot or ops-led; bash + CI is more transparent to them.
• Windows targets, complex exit-code/streaming semantics, or high-frequency execution are requirements.
• Supply-chain and longevity risk is unacceptable. 131 stars, 0 dependents, and a single-maintainer lineage are real signals. If the tasks you would run are production-critical, either accept the maintenance burden of vendoring/forking or choose a more established tool.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that lets us define operational scripts once—in code we already review and deploy—and run them on a laptop or a remote server. It replaces ad-hoc bash, wiki runbooks, and one-off admin screens with a consistent, auditable mechanism. Cost is near zero; the upside is faster incident response and less bespoke tooling. Recommended as a time-boxed pilot on non-critical, read-only or reversible tasks before any production commitment.

To engineering: It gives us Blade-style, parameterized task definitions with local and SSH execution, so scripts live in the repo, get code review, and can reuse Laravel's auth, logging, and queue infrastructure. Caveats to accept explicitly: single maintainer, negligible dependent base, and shell execution is an inherently dangerous primitive. Mitigations: pin the version, wrap every task in authorization and audit logging, forbid free-form user input from reaching the shell, keep destructive tasks behind explicit confirmation, and avoid making it a dependency of the deploy pipeline. If the pilot succeeds, the same abstraction is a natural home for future runbook automation; if it stalls, the escape hatch to spatie/ssh or Envoy is trivial because the task definitions are ours, not the package's.