Product Decisions This Supports
- Feature scoping for operational self-service. This package answers a narrow but recurring product question: who is allowed to take the application offline, and how fast can they do it? It surfaces Laravel's
php artisan down / up toggle inside Nova's admin UI, turning a server-access task into a permissioned UI action. That supports a decision to let Support, On-Call, or Marketing Ops trigger downtime without an engineer on a terminal.
- Build vs. buy (vs. copy) for admin tooling. Weighing a ~1-file Nova tool against a hand-rolled card, the honest read is that this is a weekend-scope feature. The real decision is not "buy this" but "adopt-and-fork vs. build our own," since the package is MIT and tiny enough that vendoring it is cheaper than a dependency-management conversation.
- Incident response & MTTR roadmap. A one-click kill switch shortens the loop between "we see an incident" and "we stop making it worse." That is a measurable reliability lever, so it belongs in an ops/reliability roadmap item rather than a product backlog.
- Deploy and migration runbook design. Supports the decision to standardize how deploys announce downtime (toggle on → migrate → toggle off) instead of ad-hoc SSH sessions, which reduces the "who ran
artisan down and forgot to bring it up?" failure class.
- Permissioning and RBAC decisions. Because it lives in Nova, it inherits Nova's authorization gates, which forces an explicit decision about which roles can cause a customer-facing outage — a useful forcing function for policy design.
- Buy-vs-build signal for the broader admin surface. At 33 stars and a last release in January 2019, this is a data point that Nova operational tooling is under-served and largely community-maintained. That informs whether we invest in an internal Nova toolkit owned by our own team.
When to Consider This Package
Adopt (or fork) when all of the following hold:
- You are on a legacy Nova 1.x–3.x installation. The package predates Nova 4 and has had no release since Jan 2019, so treat Nova 4/5 compatibility as unproven until you verify it — the Nova tool/card APIs and front-end stack changed materially.
- Your team is small and you want the toggle today, accepting MIT-licensed, effectively unmaintained code that you will own.
- Non-engineers genuinely need the ability: if only two engineers ever take the site down,
php artisan down in CI or a console command is a better answer than adding an admin dependency.
- You can tolerate the feature set as-is: no
--secret bypass token, no scheduled/auto-expiring maintenance windows, no custom maintenance page messaging from the UI, no audit log of who toggled what, no multi-app or multi-tenant scoping.
- You are prepared to vendor or fork it rather than track upstream, and to add your own logging and authorization gates.
Look elsewhere (or build in-house) when:
- You are on Nova 4+ — assume incompatibility and budget for a rewrite of the tool wrapper; the maintenance-mode concept is trivial to reimplement.
- You need compliance or auditability (who took the site down, when, why, for how long). This package provides none; you would be bolting logging onto abandoned code.
- You need graceful degradation — a friendly custom page, allowlisted IPs/secret URL for stakeholders to preview during maintenance, or automated expiry so nobody forgets to restore service.
- You have a modern deployment pipeline. Laravel's native
down/up, health-check gates, or feature-flag-driven "read-only mode" (often a better product experience than a hard 503) may remove the need entirely.
- Dependency governance is strict: an unmaintained 2019 package in the admin path is a supply-chain and upgrade liability disproportionate to the value it delivers.
- Your real need is partial degradation (disable checkout, pause signups) rather than whole-app maintenance — that is a feature-flag problem this tool cannot solve.
How to Pitch It (Stakeholders)
For executives: This is a small, free, MIT-licensed add-on that puts a "take the site down / bring it back up" switch inside our existing admin panel. Its value is operational: it lets support and on-call staff respond to incidents in seconds instead of waiting for an engineer with server access, which shortens outages and reduces 2 a.m. escalations. The catch is age — the package was last released in 2019 and has a small community (roughly 30 GitHub stars), so it is best understood as a starting point we own and maintain, not a supported vendor product. Recommendation: a low-cost pilot on our current Nova version, with engineering time budgeted to fork, patch, and add audit logging — or, if we are on Nova 4+, to reproduce the same switch internally in a day or two.
For engineering: It is a thin Nova tool wrapping artisan down / artisan up. Practically no code to review, but also no maintenance since January 2019 — expect to verify it against your Nova major version, lock or vendor the dependency, add authorization gates and an audit trail, and consider extending it with a secret bypass token and auto-expiry. Treat the concept as the deliverable, not the dependency.