Nova Advanced Command Runner Laravel Package

Technical Evaluation

What is being evaluated. A Laravel Nova tool that adds a panel to the Nova admin dashboard for executing Artisan and shell/bash commands on the host serving the application. Mechanically it is thin: a Nova tool service provider, a Vue front-end, a controller that shells out, and output returned to the browser. MIT licensed, 18 stars, 0 dependents, last release 2020-08-14, composite score 2.16 with opportunity at 30.46.

Architecture fit. It plugs into a Laravel + Nova monolith cleanly — one entry in NovaServiceProvider::tools(), inheriting Nova's auth and middleware. But what it actually is architecturally is a remote command execution surface behind an admin panel. That runs against the direction mature Laravel estates move: queued jobs, signed deploy pipelines, CI/CD, Horizon-based observability. Treat it as an operator console bolted onto Nova, never as an application runtime component. The package's real public API is not code — it is the published config file that declares which commands the UI may expose.

Integration feasibility. Install effort is genuinely low (composer require, register, publish config/assets, edit the command list, run one benign command end-to-end). Three gates dominate feasibility:

1. Version compatibility. A 2020-era Nova tool predates Nova 4/5 tool registration and Laravel 9+ conventions. Expect friction in service provider signatures, asset publishing, route registration, and PHP 8.1+ deprecations. The first task is not integration, it is a compatibility spike against the actual composer.json constraints.
2. Host capability. It needs proc_open/shell_exec enabled and the PHP-FPM user to hold whatever privileges the target commands require — both commonly locked down in hardened images.
3. Output semantics. There is no true streaming; output lands when the command finishes. Long commands hold a web worker and hit max_execution_time or proxy timeouts.

Verdict: moderate feasibility on legacy Nova 2/3, poor on Nova 4/5 without an internal port.

Technical risk — the dominant factor.

• Security blast radius. Anyone who can see the tool can, by design, run commands as the web user. Nova authorization is coarse; one over-privileged or compromised admin account becomes host-level RCE. An empty or wildcard allowlist is equivalent to distributing a shell.
• Unmaintained dependency. Four years without a release, zero dependents, no upstream security response or compatibility patches. Adoption means "adopt and own," not "buy."
• Supply-chain hygiene. Low adoption means low review. Pin the commit, vendor the source, and read the process-execution layer line by line before it touches a credentialed environment.
• Auditability gap. Actor, command, timestamp, exit code, and output are unlikely to be first-class. That is a compliance blocker in any regulated or multi-tenant context.

Key questions to answer before committing:

1. Which Nova and Laravel majors are in the target app, and does the package's composer.json actually permit them?
2. Is there a command allowlist, or free-text shell input? Can it be constrained to named Artisan commands only?
3. Who can reach it — a dedicated gate/permission, or any Nova user?
4. Is every invocation logged with actor, command, exit code, and output?
5. Which environments are in scope, and is production explicitly excluded by default?
6. What can the PHP-FPM user reach — DB credentials, .env, cloud keys, other tenants' data?
7. Does a command hold a web worker for its duration, and what is the effective timeout ceiling?

Integration Approach

Stack fit. Target a Laravel + Nova admin application, a small trusted admin/ops group, and a non-production or hardened internal pilot. Use it as a curated operations console — a named command catalog for cache/config clears, queue restarts, scheduler checks, migration status, storage:link, log tailing, staging resets, and support diagnostics. It is not a fit for customer-facing access, free-form bash in production, multi-tenant isolation, or anything requiring an SLA.

Migration path. Start in a disposable container or local environment with exactly one benign Artisan command. Confirm the full loop — config entry → UI selection → executed output → exit status — plus that Vue assets load after php artisan nova:publish. Only then widen the catalog. Do not touch shared infrastructure until the loop is proven and the process-execution code has been read.

Compatibility work, in order.

1. Diff the package's composer.json constraints against the pinned Laravel/Nova/PHP versions; decide port vs. abandon before writing config.
2. If ports are needed, fork and vendor the source — do not depend on upstream fixes that will not arrive.
3. Verify config caching behaviour: after any command-list edit, config:clear, or the UI silently shows stale commands.
4. Reproduce any command manually as the web user (sudo -u www-data php artisan …) before blaming the tool — PATH, env vars, .env loading, and file permissions all differ from an SSH shell.

Sequencing (each step is a gate, not a task):

1. Compatibility spike — does it even load on our stack? No → stop, evaluate building thin.
2. Fork, pin, vendor — accept ownership formally, with a named internal owner and a maintenance budget.
3. Add audit logging — wrapper or listener capturing actor, command key, full command string, timestamp, exit code, and output snippet. Nothing ships before this.
4. Add access control — a Nova gate plus an explicit environment flag; disabled unless set, production out of scope by default.
5. Build the command catalog — stable keys, human labels, one intent per entry, argument-free variants preferred (migrate --status, migrate --force) over one configurable shell input. Environment-branched lists: narrow for production, broader for staging/local.
6. Staging rollout with the runbook documented and on-call trained, then decide on permanence.
7. Re-evaluate build vs. buy. At roughly 200 lines of equivalent internal tooling, a thin in-house Nova tool with allowlists, RBAC, and audit baked in is a legitimate lower-ownership-risk alternative — especially if steps 2–4 consume more than a sprint.

Extension discipline. Extend via the config file, not by forking behaviour into the package. When more logic is needed, wrap it in a custom Artisan command and expose the wrapper — complexity stays in code we own, and the tool stays a predictable launcher.

Operational Impact

Maintenance. This is adopt-and-own. There is no upstream maintenance signal — no releases since August 2020, no dependents, no security response — so the internal team absorbs compatibility patches and security review. The config file must be treated as reviewed application code: every command addition goes through the same PR and review path, and misconfiguration is a production incident vector (a migrate:fresh entry is catastrophic). Budget a small fork-and-port line item rather than assuming zero carrying cost.

Support. No vendor, no SLA, no ecosystem validation. Support means an internal runbook plus a named owner. Document exactly which commands exist, what each does, who may run them, and what to do when output is empty. Publish the "web user is not you" debugging step as the first line of the runbook. Escalation for a broken tool is an internal engineer, so the tool's blast radius and its support burden land on the same small team.

Scaling. Two distinct problems. Vertically, each invocation occupies a web worker for its full duration — no streaming, so migrations and imports will hit max_execution_time or a proxy timeout and should be queued jobs or CLI runs instead. Horizontally, the command runs on whichever node serves the request, which means non-deterministic targets in a load-balanced fleet; either pin the tool to a designated node or accept that it is unsuitable for multi-node operational tasks. Neither limitation has a configuration fix.

Failure modes to plan for.

• Silent staleness — cached config hides newly added commands; engineers chase a bug that is not there.
• Empty output — command may have run fine, failed silently, or never executed; check storage/logs/laravel.log and the tool's network response before retrying.
• Interactive commands hang — anything prompting for input will block or fail; exclude them from the catalog.
• Permission and environment drift — the web user cannot read/write what the operator's shell can; failures look like package bugs.
• Timeout mid-command — the browser gives up while the process continues, leaving an unknown state; any command that is not idempotent is risky.
• Compromised or over-privileged admin account — becomes host-level RCE; mitigated only by tight gating, environment exclusion, and audit logs.

Ramp-up. Installation ramp is trivial; operational ramp is not. The real onboarding is teaching operators to pick from the catalog rather than type commands, training reviewers to treat config diffs as production changes, and establishing audit review. Keep the catalog small and boring at first — idempotent, Laravel-native commands (cache:clear, queue:restart, config:clear, storage:link) before anything touching data.

How to measure whether it was worth it. Instrument from day one: command runs per week by key, support tickets resolved without SSH, mean time to recovery on routine ops incidents, and audit-log completeness. If usage concentrates on two or three commands and MTTR does not move, the durable answer is a thin in-house tool or simply better CI/CD — and the pilot has done its job cheaply. If usage is broad and ticket volume drops, that is the evidence needed to fund the hardened internal build rather than extend this package's life.