Product Decisions This Supports
- Build vs. buy for operational guardrails. Instead of writing bespoke service-provider checks or shell wrappers to disable dangerous Artisan commands (
migrate:fresh, db:wipe, queue:clear, tinker) in production, this package gives you a config-driven blocklist for a few lines of integration. That's a small, reversible bet — worth a spike rather than a design doc.
- Roadmap input for production safety / incident prevention. A recurring class of incidents is "someone ran the wrong command against prod." This package is a cheap control you can slot into an existing reliability or change-management epic without new infrastructure, permissions, or runbooks.
- Feature decisions around self-service prod access. If your roadmap includes letting more engineers or contractors touch production consoles, an explicit command blocklist is a prerequisite. It converts "we trust people to be careful" into an enforced, reviewable policy.
- Environment parity and blast-radius decisions. Blocking is configurable per environment, so you can keep full command access in local/staging while restricting production — supporting decisions to ship faster in lower environments.
- v1.0.1 specifically: control reliability. The fix — "errors when some commands missing" — means the guardrail no longer assumes every command it inspects is registered. This matters for heterogeneous fleets where packages differ between deployments (workers without queue packages, read replicas without migration tooling). A control that can break bootstrapping is worse than no control; this patch makes the guardrail safe to leave on by default. It's a minor patch with no API or config breaks, so it doesn't change an adoption verdict — it removes a known objection.
When to Consider This Package
Consider it when:
- You're on Laravel and want a declarative, config-file blocklist for a handful of destructive console commands in production.
- You want a guardrail that is console-only and effectively zero-cost at request time.
- Your need is narrow and static: "these N commands must never run in
production."
- You want a fast, low-ceremony layer while a broader access-control or audit initiative is still being scoped.
Look elsewhere (or use the framework) when:
- You're on Laravel 11+, where destructive commands ship a
Prohibitable trait — calling DB::prohibitDestructiveCommands() in a service provider gets you most of this for free. Evaluate native support before adding a dependency.
- You need audit logging, RBAC, approval workflows, or alerting on attempted commands. This blocks; it doesn't record or route.
- You need policy enforcement across non-Laravel CLIs, shell access, or Kubernetes exec — that's a platform/IAM problem, not a package problem.
- You're in a regulated environment requiring vendor support, SLA, or a security review of every dependency. Note the project is at v1.0.x with a single maintainer — acceptable for a thin, readable guardrail; risky as a load-bearing compliance control.
- You need dynamic, data-driven policies (per-tenant, per-user, time-boxed unlocks). Prefer a policy layer you own.
How to Pitch It (Stakeholders)
To executives: A very small dependency that prevents a very expensive category of accident — one wrong command against production destroying data. It costs a single config file, adds no infrastructure, and has no performance impact on customer traffic. Cheap insurance, easily removed if we change direction.
To engineering: One service provider registration plus a config block listing blocked commands per environment. Console-only, no runtime overhead, no database changes. v1.0.1 hardens it so it tolerates environments where certain commands aren't installed — it won't break deploys across our app/worker/replica topology. Before merging, confirm whether our Laravel version's built-in destructive-command prohibition already covers our blocklist; if it does, we skip the dependency.
Caveats to state up front: v1.0.x, single maintainer, and it prevents rather than audits. Position it as one layer of defense-in-depth — it complements, and does not replace, restricted production credentials, change approval, and logging.