- Does brickx/laravel-filament-maintenance support Filament v3 and v4?
- The last release was June 2023, so the package predates current Filament majors and almost certainly targets Filament v2. It is archived and unmaintained, so no v3 or v4 compatibility fixes are being issued. Pin your Filament major in composer.json and re-test the toggle page whenever you upgrade Filament.
- How do I install brickx/laravel-filament-maintenance in a Laravel app?
- Run composer require brickx/laravel-filament-maintenance, then register the plugin in your Filament PanelProvider. Optionally publish the config and views if the package ships them. There are no database migrations or service overrides, so removal is clean.
- Is brickx/laravel-filament-maintenance safe to use in production?
- Treat it as a reference implementation rather than a production dependency. It is archived with 15 stars, zero dependents, and effectively no production validation, so any edge cases become yours to discover. There are no security patches or issue triage. If you need a maintained toggle, rebuild it in-house or fork it under your own maintenance.
- Does the package use Artisan::call or write the maintenance files directly?
- The package is a thin UI over Laravel's native php artisan down and up commands, but the public metadata does not confirm whether it calls Artisan::call or manipulates storage/framework files directly. Read the source before trusting it. Direct file manipulation is riskier because it bypasses the flags and options the Artisan command validates.
- How does the secret bypass token work and is it secure?
- The package advertises a secret bypass token, which maps to Laravel's signed bypass for maintenance mode. It is unclear from the metadata how the secret is stored or displayed, so verify it is not exposed in the UI or logs in plain text. Treat the token as a credential and rotate it if it leaks.
- How do I restrict who can toggle maintenance mode in Filament?
- It is unclear whether the package gates the toggle behind a Filament policy or permission, and audit logging is not documented. A maintenance toggle is effectively a denial-of-service button, so any panel user with page access can take the app offline. Wrap the action in a gate, add a confirmation modal, and log who toggled it and when.
- Does the maintenance toggle work across multiple servers or containers?
- No. Laravel's native maintenance mode writes node-local files under storage/framework, so on multi-node, containerized, or ephemeral filesystems the toggle appears to work while only one node goes down. Use a shared cache flag or a custom state mechanism if you run more than one node. The package does not appear to handle this.
- Can I schedule downtime and set retry, status, or redirect options?
- The overview mentions scheduling downtime, but the metadata does not confirm support for Laravel's retry, status, redirect, and render options. Check the source to see whether it exposes the full down command flags or only a boolean toggle. If you need those options, a small first-party page calling Artisan::call('down', [...]) is usually simpler.
- What are the alternatives to this package for a Filament maintenance toggle?
- The recommended alternative is to absorb the idea and rebuild it as first-party code: one Filament page that calls Artisan::call('down') and Artisan::call('up') behind a gate and confirmation step. That takes hours, removes an unmaintained dependency, and lets you add audit logging and multi-node handling. For teams not using Filament, plain artisan down and up is the right tool.
- Can I fork the package or should I rebuild it myself?
- The MIT license permits forking, but you inherit the maintenance burden either way. Given the archived status and tiny code surface, rebuilding in-house is usually better than adopting or forking. If you want to evaluate it first, install it in a disposable panel and read the source as a reference.