Nova Command Runner Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. If your team already runs Laravel Nova for back-office administration, this package turns "we should build a small admin screen to run Artisan commands" into a same-day evaluation instead of a sprint. That directly informs whether to allocate engineering time to a custom ops console or defer it.
• Reducing operational dependence on engineers. It supports a roadmap decision to move routine runbook steps (cache clears, queue restarts, index rebuilds, scheduled job triggers, one-off data fixes wrapped in commands) out of SSH sessions and into a permissioned UI that support/ops staff can use.
• Incident response and MTTR. A decision to standardize "safe commands" behind an admin surface shortens the path from "something is stale" to "the right command ran," provided access is gated and audited. This is a lever for support-tier autonomy without granting shell access.
• Feature scoping for an internal admin surface. It clarifies requirements early: if the package covers command discovery and execution, your remaining product scope is authorization, auditing, confirmation UX, and output capture — the parts that actually determine risk.
• Platform standardization. Choosing whether Nova remains your single internal admin plane, versus adding separate tools (Forge/Envoyer, Horizon dashboards, custom consoles), is a consolidation decision this package feeds into.
• Deprioritization signal. With ~43 stars and low opportunity score, this is a candidate for "prototype and validate," not "commit to in the platform roadmap." That distinction itself is a product decision worth recording.

When to Consider This Package

Consider it when:

• You are already on Laravel + Nova, on a supported Nova version, and want command execution inside the admin panel rather than a second tool.
• The audience is internal only — engineers, ops, or a tightly scoped support group — not customers or tenant admins.
• You have (or can add) a strict Nova gate/authorization policy, plus audit logging of who ran what and when. Treat this as a prerequisite, not a follow-up.
• You need short-running, idempotent commands and can accept synchronous execution with visible output.
• You want a cheap experiment: MIT license, no procurement, removable in an afternoon if it disappoints.
• You can pin and review the dependency — verify Nova version compatibility, recent commit activity, and open issues before merging.

Look elsewhere when:

• You are not on Nova, or you are mid-migration away from it — building on a tool you plan to leave is negative ROI.
• You need durable audit trails, approvals, RBAC granularity, or compliance evidence out of the box; you will be building that yourself, and a plain controller calling Artisan::call() may be simpler to secure and own.
• Commands are long-running or resource-heavy — you want queue-backed jobs, timeouts, cancellation, and persisted logs, not a request-bound runner.
• Multi-tenant or externally exposed admin surfaces are in scope; command execution is effectively remote code execution and should not sit near untrusted users.
• Maintenance risk is unacceptable. Low star count and a single maintainer mean you should assume you may fork or vendor it; if your team cannot absorb that, prefer a thin in-house wrapper.
• You already have a stronger operational surface (Horizon, Forge/Envoyer, a mature custom console, or a runbook automation tool) that covers the same job with better observability.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, MIT-licensed add-on for the Laravel admin panel we already run. It lets a tightly permissioned group of internal staff trigger routine maintenance commands from a UI instead of asking an engineer to open a terminal — which shortens incident response and reduces shell-access sprawl. Cost is effectively zero and it is easy to remove, so the downside is bounded. The real work is not the package; it is the guardrails around it (who can run what, and a log of every execution). Recommendation: approve a short, time-boxed internal pilot behind a super-admin gate, with audit logging, and decide on broader rollout based on that.

For engineering (summary): Thin Nova tool that exposes Artisan command discovery and execution. Treat it as a UX layer over Artisan::call() — not a security boundary. Before adoption: confirm Nova version compatibility and maintenance activity, wrap it in an explicit authorization gate, log command, arguments, actor, and output, restrict to an allowlist of safe commands rather than the full Artisan surface, disable destructive/interactive commands, and confirm behavior for long-running tasks. If any of those become heavy lifts, a small in-house controller will likely be cheaper to own than a low-adoption third-party dependency.