cms-multi/filament-clear-cache
Filament Clear Cache adds a one-click cache-clearing button to your Filament admin panel toolbar. Install via Composer, register the plugin on your panel, and optionally publish the config or restrict it to specific environments. Supports Filament 2.x, 3.x, 4.x and 5.x.
Architecture fit. This is a narrow, single-purpose Filament panel plugin: a Livewire component registered through the panel's plugins() array that renders a header action button and shells out to Artisan commands (optimize:clear by default, plus any commands registered via the FilamentClearCache facade). Architecturally it is a thin presentation layer over Laravel's console kernel — no data models, no migrations, no persistence beyond a session counter that drives the badge. For a TPM this means the blast radius of adoption is limited to the admin panel surface, and the package sits entirely within conventions the Filament ecosystem already expects. The main architectural consideration is not whether it fits, but that it deliberately collapses an infrastructure operation (cache invalidation) into an authenticated HTTP request, which is the decision worth reviewing.
Integration feasibility. Very high. Composer install, optional vendor:publish of the config, and three lines in the panel provider. No dependency on queue workers, no external services, no schema changes. The version matrix is unusually broad — 1.x/Filament 2/PHP 8.0, 2.x/Filament 3/PHP 8.1, 3.x/Filament 4+5/PHP 8.2 — which means most teams will find a supported branch regardless of where they sit. The enabled() method added in 3.0.1 allows environment gating in the panel definition itself, and the README documents a visible config from earlier releases. The facade's addCommand() hook gives a clean extension point for app-specific clears (page cache, response cache, CDN purge wrappers) without forking.
Technical risk. Moderate, concentrated in three areas. First, privilege and authorization: the button clears the application cache for all users. Anyone who can reach the panel header can trigger it. There is no documented per-user gate, policy, or role check — only environment conditioning. On a panel shared with clients, read-only staffers, or support users, this is an availability lever in the wrong hands. Second, synchronous execution: cache clears run inline in the Livewire request. optimize:clear on a large app with many cached routes/config can take seconds, and the changelog history is a warning sign here — 2.1.0 explicitly notes fixing an optimize command freezing issue, and v1.0.6 mentions a full redirect to work around stale Livewire assets. Default behavior also shifted in 2.1.0 to clear config only, which suggests the maintainers walked back the more aggressive default after problems. Third, cache stampede: clearing the whole cache on a busy production tenant pushes all subsequent requests to recompute, which can spike DB and origin load. None of these are reasons to reject the package, but all three need a decision recorded before it ships to production.
Key questions.
max_execution_time or our load balancer's idle timeout?optimize:clear the right default for us, or should we narrow to cache:clear plus specific tagged clears to avoid config/route cache churn during business hours?Stack fit. Requires Laravel (11/12/13 supported per changelog) and a Filament panel (2.x–5.x). PHP 8.2+ for the current 3.x line. If the organization is standardizing on Filament 4 or 5, pin ^3.0; if any panels lag on Filament 3, the 2.x branch remains maintained. Because the package is Livewire-based, it inherits whatever Livewire version the host Filament install already pins — worth confirming, since the README documents divergent emit (v2) versus dispatch (v3+) syntax for the increment event. In practice the button works without any custom event wiring; that only matters if we build adjacent tooling.
Migration path. Essentially zero-migration. There is no data to move and no state to reconcile; removal is composer remove plus deleting the plugin registration line. The only persistent artifact is a session key used for the counter, configurable via the published config. This low switching cost is a genuine advantage — it can be piloted on a single non-critical panel and removed cleanly if it disappoints.
Compatibility. The published compatibility table is the operative document. Confirm the installed Filament major first, then select the branch. Watch for transitive drift: Filament majors move quickly, and the 3.0.0 release notes show the Filament 4/5 support landing in one PR, which means version 3.x is the forward path and older branches will likely receive only dependency bumps (as seen in 2.0.8 and 2.1.0, which are mostly Dependabot plus a Laravel 12/13 support commit). Budget for the possibility that a future Filament 6 requires waiting on a maintainer PR.
Sequencing. (1) Confirm Filament major version and cache driver per environment. (2) Install on local and staging first, with enabled(App::environment(['local', 'staging'])) as the initial gate. (3) Register app-specific commands via FilamentClearCache::addCommand() so the button does what operators actually need rather than a blunt optimize:clear. (4) Instrument command duration on staging against production-like data volume. (5) Define the authorization story — either a policy gate wrapper or acceptance of the panel-access-as-permission model — and document it. (6) Only then enable in production, ideally behind a feature flag and initially for a small admin cohort. (7) Add a runbook entry describing what the button clears and what it does not.
Maintenance. Low effort, non-trivial dependency exposure. The package's own logic is small and stable; most release activity is Dependabot bumps plus occasional Filament/Laravel compatibility PRs. The maintenance burden is therefore mostly tracking rather than fixing: someone must watch for Filament major releases and confirm a compatible plugin tag exists before upgrading the panel. With zero dependents recorded on Packagist and 54 stars, we should assume no vendor SLA and treat the code as auditable-in-an-afternoon. A vendored fork is a realistic fallback and cheap to execute given the surface area.
Support. The support surface for end users is genuinely small and positive: the whole point of the package is to remove the "can someone SSH in and clear the cache" ticket. That is a measurable reduction in tier-1 operational load. The support surface for platform engineers is a new question in the incident playbook — "did someone press the cache button?" becomes a candidate cause when investigating performance regressions or unexpected cache misses. Add it to the change/incident timeline: log an application event on cache clear so the action is attributable in observability tooling. Without that, a well-intentioned click becomes an unattributable variable during an incident review.
Scaling. Two scaling concerns. Horizontally, the button clears the cache on whichever node serves the request; if the cache store is shared (Redis/Memcached) this propagates correctly, but if any node uses a local file cache, the fleet is left inconsistent. Vertically, the clear is synchronous and unbounded — a large route/config cache set means a multi-second request, and concurrent clicks across a large admin team multiply the recompute cost. Mitigations are cheap: throttle the action, gate it to a small role, and prefer narrower commands than optimize:clear for routine use. For multi-tenant deployments, evaluate whether a global clear is acceptable or whether tenants need scoped invalidation — the package does not offer tenancy awareness, so that would require a custom command via addCommand().
Failure modes. (a) Authorization failure — unintended user triggers a production-wide clear; impact is performance degradation and cache-miss load, not data loss. (b) Timeout/freeze — long-running optimize:clear exceeds request limits, leaving the operator with an ambiguous result; this exact class of bug appears in the changelog history (2.1.0) and warrants a staging measurement before production exposure. (c) Collateral invalidation — if config or route cache is cleared while the app relies on it for bootstrapping across nodes, expect transient inconsistency; the shift to "config only" by default in 2.1.0 hints the maintainers hit this. (d) Shared-store side effects — clearing a Redis database co-tenanted with sessions or queues could evict live session data or job payloads; verify key prefixes and database separation first. (e) Maintainer abandonment — low probability of immediate breakage, but a Filament major could strand us; the fork contingency covers it. (f) Audit gap — no built-in logging of who cleared what, so add instrumentation.
Ramp-up. Near-zero for developers: one Composer command and one array entry. For operations and support staff, the ramp-up is a short runbook section — what the button does, when to use it, when not to use it (peak traffic, active incidents), and who to contact if the panel hangs afterward. Recommend a brief written policy alongside the rollout: which roles see the button, in which environments, and the expectation that it is a diagnostic tool rather than a routine hygiene action. Total organizational adoption cost is on the order of a day of engineering review plus a paragraph of documentation — a favorable ratio for the ticket-volume reduction it delivers, provided the authorization and instrumentation gaps are closed before production enablement.
How can I help you explore Laravel packages today?