Laravel Filament Maintenance Laravel Package

Product Decisions This Supports

• Feature scoping: “operator self-service” for release and incident workflows. The package turns php artisan down / up into a Filament panel button. The product decision it informs is whether routine downtime should require an engineer with shell access or whether it belongs in the admin surface your support/ops staff already use. That's a recurring capacity question, not a one-off.
• Build vs. buy vs. borrow for platform-ops controls. The capability is small enough that this repo is best read as a reference implementation, not a dependency. If it's on your roadmap, the decision is usually “vendor ~200 lines into our own Filament plugin” versus “add a third-party package.” The 1.1.2 release shows the maintainer is still shipping small improvements (a refresh control for the panel widget), which softens — but does not remove — the maintenance concern: it remains a single-maintainer project with a short release history and no stated support matrix for current Laravel/Filament majors. Internalizing still wins on maintenance risk in most cases.
• Roadmap: point solution vs. an internal ops toolkit. This package is a strong signal that admins expect a consolidated “Platform Status” area. The adjacent asks almost always follow: cache clear, queue restart, feature-flag overrides, scheduled-window announcements, per-tenant downtime. Deciding whether maintenance mode ships alone or as the first module of an internal ops panel is the higher-leverage call. Note that 1.1.2's refresh option is pure UI convenience — it makes the toggle feel more like a live status surface, but adds no scheduling, scoping, or governance.
• Use cases to validate against: planned deploys and migrations, live incident response (fast “we're working on it” page), scheduled maintenance windows communicated in advance, demo/staging environment control, and per-tenant downtime in multi-tenant products.
• Risk posture decision. Exposing a global availability switch to a broad admin role is a product risk question — blast radius, who can trigger it, whether the bypass secret and allowlisted IPs are managed, and whether actions are audited. The package provides the switch but not the governance, so adopting it forces an explicit answer. Nothing in 1.1.2 changes this; a refresh button is not an audit trail.

When to Consider This Package

Consider it when:

• You're already on a Filament panel (v3-era) plus a Laravel version contemporary with the package's release line, and you want a working reference for Artisan::call('down'/'up') wiring, form options, and Filament action/page patterns. Patch releases are still landing (1.1.2), so the code is at least being looked at — but check the changelog and repo activity yourself rather than assuming ongoing support.
• You're a small team without dedicated DevOps and non-engineers need to take the app offline without a deploy or a terminal.
• You want a deliberately minimal surface: one switch, no scheduling engine, no per-tenant logic. The refresh option added in 1.1.2 is a good fit for this philosophy — small, visible, low-risk polish.
• It's a staging or internal tool where a thin permission model is acceptable and you can tolerate a small, single-maintainer dependency.

Look elsewhere — or build in-house — when:

• You need per-tenant, per-region, or per-service maintenance scoping. This is a global toggle; multi-tenant isolation would have to be layered on.
• You need scheduled maintenance windows, pre-announcement banners, or automatic expiry. Still not in scope as of 1.1.2.
• You need durable authorization, audit trails, approval flows, and IP-allowlist/secret lifecycle management. Plan to add these regardless of vendor.
• Your stack is on current Laravel or Filament majors. A patch release is not a compatibility guarantee — verify version constraints against your install before spending more than an hour, and expect to fork.
• You're weighing this against your own admin toolkit roadmap. Copy the pattern, keep the license notice (MIT), and own the code.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost capability with a clear operational payoff: it lets authorized non-engineers put the product into maintenance mode from the admin panel instead of waking an engineer to run a command. That shortens the loop on planned deploys and shrinks time-to-“we're aware and working on it” during incidents — the window where customers lose confidence. It's not a strategic investment; treat it as a cheap workflow improvement and a template. The project is still effectively a one-maintainer effort — the latest release (1.1.2) is a minor UI refresh control, not a sign of a support commitment. So the recommendation is unchanged: absorb the pattern into our own code rather than take a dependency, keeping ongoing cost near zero and risk fully under our control.

For engineering: It's a thin Filament wrapper over Laravel's built-in maintenance mode — a toggle, a few options, and a status indicator. Release 1.1.2 adds a refresh option (a manual re-poll of maintenance state on the panel, PR #6) — cosmetic, no API or behavior change for the core toggle. Don't add it as a long-lived composer dependency: single maintainer, short release history, and no stated support for current Laravel/Filament majors. Instead, use it as a starting point (MIT-licensed) and vendor a small internal plugin — and fold the refresh affordance in while you're there, since it's a few lines and genuinely improves the operator experience. What we must add beyond what the package gives us: a policy/gate for who can toggle (this is a high-blast-radius action), audit logging of who changed state and when, management of the bypass secret and IP allowlist, a branded maintenance page, and a test that asserts the panel still behaves correctly while the app is down. Estimate: well under a sprint, most of it in authorization and tests rather than the toggle itself.