Artisan Tool Laravel Package

Product Decisions This Supports

• Internal ops tooling investment, not roadmap differentiation. This is a Nova admin panel that lets a trusted operator run a narrow set of Artisan commands from the browser instead of SSH. Fund it (or don't) out of maintenance/operational efficiency budget, not out of customer-facing feature capacity. It will never show up in a release note.
• Build vs. buy, framed honestly. The "buy" here is really "borrow." With ~34 stars, zero dependents, and generic documentation, the package is an accelerator and a reference implementation, not a platform bet. The real decision is whether to spend a few days piloting it behind guardrails versus a weekend building a ~200-line custom Nova tool that wraps your own allowlisted app: commands. Pilot only if Nova is already in place and the guardrails (gate, allowlist, audit log, environment gating, timeout handling) are cheap for you to add.
• Scope decision for the pilot. Lock the command set to safe, idempotent operations first: cache:clear, view:clear, queue:restart, migrate:status, route:list, queue:failed, model:show, schedule:list. Explicitly exclude free-form command input, migrate --force, db:wipe, queue workers, and anything with an interactive prompt. The pilot's purpose is to validate the guardrails, not to prove commands can execute — that part is trivial.
• Risk posture and dependency classification. Treat this as a low-confidence third-party dependency with no community pressure on fixes. That means: pin the Composer constraint, record the commit validated, assign an internal owner, and plan a review at every Nova and Laravel major bump. Budget the option to fork.
• Exit strategy as a first-class decision. The replacement — a small Nova tool over your own app: commands with your own auth, logging, and queue dispatch — is a weekend of work and delivers clearer authorization and better progress reporting. Make the build-vs-buy call now, in writing, rather than discovering it during a Nova upgrade. Design your curated commands and runbook so a swap is invisible to operators.
• Success metrics that justify continuation. Fewer SSH/support requests for routine Laravel maintenance; 100% of executions with user ID, command, arguments, result, and duration logged; zero privilege-escalation incidents; acceptable timeout and output-truncation behavior validated on staging; a documented one-config-change rollback. If those don't move, kill it.
• Non-goal to state explicitly. This must not become the only path for any operation. Every covered task needs a CI job, deploy script, or controlled SSH fallback, or a Nova upgrade becomes an operational outage.

When to Consider This Package

Consider it when:

• Laravel Nova is already deployed and you have an established admin access model you can reuse rather than reinvent.
• A small, named, trusted operator group genuinely needs browser access to a curated set of Artisan commands — support engineers, on-call, or a team without reliable shell access (pairing, mobile, remote sessions).
• You can enforce a narrow allowlist and block destructive, environment-sensitive, and long-running commands at the config or app:-namespace level.
• You can wrap it with strong authorization (a dedicated run-artisan gate against a role or allowlist — "is a Nova user" is far too broad), environment gating, audit logging, execution timeouts, and explicit exit-code / stderr handling.
• You have engineering capacity to read src/ end to end before enabling it, pin the version, and own Nova compatibility going forward.
• You want a short internal spike or a reference implementation to inform a custom build.

Look elsewhere when:

• Nova is not in the stack. There is nothing to evaluate — this is a Nova tool, not a general Laravel package.
• You need this in production as a privileged control plane without an incident-response process to match.
• Nobody can commit to reviewing the source and owning the dependency. Low adoption plus sparse documentation means you are the maintainer in practice.
• The package executes in-process via Artisan::call() and you need isolation, hard timeouts, or reliable exit-code surfacing — a subprocess-based or queued custom runner will serve you better.
• Your actual need is deploy automation or recurring maintenance. That belongs in CI, not behind a button.
• You'd be exposing it to a broad admin population. A visible-but-unauthorized console is a much worse failure mode than a missing sidebar item, and a broad audience makes that failure likely.

How to Pitch It (Stakeholders)

To executives — one paragraph: Routine Laravel maintenance currently requires an engineer with SSH access, which creates a support bottleneck and an audit gap. This package is a low-cost experiment to put a small, permissioned set of those operations behind our existing Nova admin login, with a full audit trail of who ran what and when. It is not customer-facing and it is not a platform commitment: the vendor package is small and thinly adopted, so we'd pilot it for a sprint behind a role gate and a curated command list, measure whether SSH requests actually drop, and keep a documented one-step switch to turn it off. The realistic alternative is a small in-house tool that does the same thing with our own authorization and logging; the pilot tells us which is cheaper to own.

To engineering — the honest framing: This is a thin wrapper that runs Artisan commands from a Nova tool. Before anyone enables it, read src/ and answer three questions: does it call Artisan::call() in-process or spawn a subprocess, how does it capture stdout/stderr and exit codes, and does it accept free-form input or a fixed list. Then register the tool behind a Gate::allows('run-artisan') check in NovaServiceProvider::tools() so unauthorized users see nothing at all, not a disabled button. Assume commands run as www-data with that user's grants and filesystem permissions — test the allowlist as that user on staging, including a deliberately failing command to confirm non-zero exit codes actually surface. Prefer exposing purpose-built app: commands with baked-in logging and sane defaults over raw console commands. Queue anything over a few seconds; a slow migrate should not hold an FPM worker. Block config:cache and route:cache from the UI and keep them in the deploy pipeline. Log every invocation ourselves inside the command, so the audit trail survives a package swap. Pin the version, note the validated commit, and assume we own compatibility at every Nova bump — if the package fights our Nova version or security review, the custom runner is a weekend of work and operators won't notice the difference.