Filament Command Center Laravel Package

Product Decisions This Supports

• Build vs. buy for internal ops tooling. The realistic alternative to this package is a bespoke "admin can run X" page: a controller, a form, a Process::run() call, an authorization check, and a history table — then the same again for the next command. That's roughly a sprint of work per team, repeated per product, usually written without an argv model, a CI guard against fromShellCommandline(), or per-command gates. This package replaces that recurring build with a config array plus three gate definitions. The buy case is strong specifically because the naive build is the insecure build, and shipping the insecure version is the default outcome when a PM doesn't fund the secure one.
• Feature decision: self-serve operations for non-engineers. It converts a class of "can someone with SSH run cache:clear / queue:restart / migrate:status for me" requests into a UI action with a gate. That is a support-load decision, not a technical one: if your roadmap has a persistent tail of small operational favours landing on one or two senior engineers, this is a candidate fix.
• Roadmap input: audit trail as a compliance feature. The database history driver turns "who ran migrate in production at 14:02, and did they have the right to" into a queryable record. If a SOC 2 / ISO 27001 / customer-security-questionnaire workstream is on the roadmap, that requirement exists whether or not this package does; the cache driver (default, TTL-bounded, erased by cache:clear) does not satisfy it and must be explicitly upgraded.
• Prioritising "dangerous button" work. The config's ability to attach a per-command gate, a confirmation prompt, and a timeout lets you decide as product policy which operations are one-click, which are two-click, and which are engineer-only. That is a policy artefact you can point auditors and incident reviewers at, rather than a convention held in someone's head.
• Onboarding and runbook consolidation. The catalogue plus starter set doubles as living documentation of what operational actions exist and who may take them. Runbooks rot in wikis; an allow-list that CI validates (command-center:check fails on unknown tokens and undefined abilities) does not silently drift.
• A negative decision worth recording. The absence of a browser test suite, a 4-star/0-dependent install base, and a single maintainer should be logged as an accepted risk in whatever ADR you write — not left implicit — because the package's own guarantees are unusually well-specified while its bus factor is unusually thin.

When to Consider This Package

Adopt when most of these hold:

• You are on Laravel 12 or 13 with Filament 5 and PHP 8.3+, and your admin panel is already the place operators live. The integration cost is one composer require, one ->plugin(...) call, and three gate definitions — this is a days-not-weeks evaluation.
• Your operational needs are a bounded, enumerable list of known-safe commands: cache clears, optimizer, queue restart, failed-job retry, migrate:status, storage:link, deploy hooks. If you can write the list on one page, the allow-list model fits perfectly.
• You want argv-based execution with no shell string construction and are prepared to say so in a security review. The src/-wide CI script asserting no shell-execution primitive exists is the single most valuable thing here, and it's the thing a homegrown tool will not have.
• Production runs on Linux or macOS, which is the stated and tested contract.
• Your team can accept or absorb the vendor risk: MIT license means forkable, the core has no Filament import (portable), and 442 tests across PHP 8.3/8.4/8.5 × Laravel 12/13 is a real bar for a 4-star package. But there is one maintainer, zero dependents, and no browser test suite — budget for pinning the version and reviewing it before upgrades.
• You can define the gates on day one. Until command-center:access exists, nobody sees the module. That is a correct and slightly annoying default; plan for it rather than discovering it during a demo.
• You will use the database history driver if the trail matters. If audit is a real requirement, the cache driver is not a decision, it's a placeholder.

Look elsewhere, or build, when:

• Windows is in scope. Untested and explicitly not claimed, because Symfony converts argv to an escaped command string there. That is a different security guarantee, and this package won't give it to you.
• You need free-form command execution, an arbitrary shell for debugging, or an interactive terminal. The allow-list is the product; if you want a web shell, this is the wrong tool and you should be having a different conversation about bastions.
• You need the database editor to manage variables. It doesn't yet. Commands with variables must live in config, which means a deploy to add one — if the whole point of the DB source was avoiding deploys, this is a real gap.
• Cancellation is on your critical path. Cancel only lands between output chunks, and for synchronous runs it barely works at all because the flag-setting request and the process-running request are different PHP processes. Queued runs are the supported story; treat sync cancel as decorative.
• Multi-tenant isolation is a hard requirement. Model variables re-resolve through a scoped query, which is genuinely good, but anyone who can write the allow-list — config or the commands table — can run anything the PHP process can. That's deploy-level privilege. If your tenancy model can't guarantee nobody writes that table, don't enable the database source.
• You need sandboxing. The package controls which commands and with what arguments. It explicitly does not sandbox what the command does. Resource limits, network isolation, and filesystem confinement are your platform's job.
• You need secret handling. redact hides a value from history, not from ps. Secrets must go through environment variables; if the product decision is "operators paste the API key into a text field," stop.
• Your risk tolerance for a new, single-maintainer dependency in the deploy path is low. Reasonable. Fork it — the license and the Filament-free core make that cheap — and own it.

How to Pitch It (Stakeholders)

For executives — the one-paragraph version. This is a small, MIT-licensed component that lets trusted administrators run a fixed, pre-approved list of server maintenance commands from the admin panel they already use, instead of asking an engineer to SSH in. It removes a recurring tax on senior engineers, shortens the loop on routine operational work from "find someone with access" to "click the button you're authorised for," and — if we switch on the database history driver — produces an audit record of who ran what, when, and under which permission. Cost to evaluate is a day; cost to adopt is a config entry and three permission definitions.

For engineering — why this one and not the obvious alternative. The security model is the argument. Execution is always an argv array through Process; Process::fromShellCommandline() appears nowhere in src/ and a CI script enforces that. The HTTP payload carries a command key, never a command string, so a value containing ; rm -rf / stays one argument. A token can't become an option or the binary. Authorization is re-checked server-side in the run action, in the dispatcher, and again inside the queued job, because a gate can be revoked between dispatch and execution. command-center:check fails CI on unknown tokens, orphaned variables, undefined abilities, and an unguarded database editor. That is a materially better posture than the panel page we would write in a sprint, and the maintainer has been honest about the limits in a way that usually only comes from having thought hard about them.

For security and compliance — what to ask before sign-off. Three things, in order. First, who can write the allow-list? Config write access and the commands table are both equivalent to deploy access, and the database source is the highest-privilege surface in the package — it needs a named owner and the command-center:manage-commands gate defined. Second, do we need the database history driver? The default cache driver is capped, TTL-bounded, and erased by cache:clear; if audit is in scope, it does not qualify. Third, accept explicitly that this cannot sandbox a running command and cannot hide a secret from ps — those stay platform and process concerns.

For the product team — what it doesn't do, so we don't oversell it. It doesn't give you a web terminal. It doesn't let the database editor define variables yet, so variable-bearing commands need a deploy. Cancelling a synchronous run is unreliable by design; cancel is a queued-run feature. Windows isn't supported or claimed. And it is a young package — 4 stars, no dependents, one maintainer, no browser test suite — so we pin the version, fork if we need to, and don't put it anywhere we can't own for a year.