Nova Cache Card Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin tooling. This card is a useful cost anchor for a recurring question: do we build cache management into our admin surface, or adopt something off the shelf? The honest answer here is that the "buy" side is thin — MIT license and zero acquisition cost, but no maintainer, no support, no upgrade path, no release since February 2019, and 26 stars with zero dependents. Even so, seeing the capability scoped at roughly one card class, one route, and a handful of Cache facade calls gives us a realistic denominator for the in-house build. That denominator is roughly a day of engineering against the native Nova scaffolding command. Framing the decision this way usually resolves it: the "buy" option costs a day of spike plus indefinite ownership, and the "build" option costs a day and gives us the confirmation modal, audit log, and environment guards we actually need.

• Ops self-service roadmap prioritization. "Can someone clear the cache?" is a top-tier request from support, QA, and non-engineering staff. Individually it is cheap; collectively it is expensive because every instance routes through a Slack ping to an engineer with shell access, who then context-switches, runs php artisan cache:clear, and returns to what they were doing. This package quantifies the cheap version of that capability — driver visibility plus a one-click flush — so we can decide whether it earns a sprint slot or stays a one-off Artisan command executed by whoever is on call. The decision input is interrupts per sprint, not developer satisfaction.

• Reducing engineering interruption load. Every "please clear staging cache" message is a context switch with a real cost that never appears on a roadmap. A dashboard card converts a recurring, unbounded interrupt into a permissioned, visible UI action. That reframes the investment as a support-cost decision with a measurable input rather than a developer-experience nicety. Set the metric before shipping: reduction in cache-related engineering interrupts per sprint, with zero unauthorized flushes. If we can't measure the first half, the card is a novelty; if we can't guarantee the second, it is a liability.

• Deepening or exiting a Nova investment. If we already pay for Laravel Nova, this is a low-marginal-cost capability added to a panel we are already funding. It also forces the strategic question of whether to keep deepening the Nova admin surface or begin migrating admin functionality elsewhere. A 2019-era card is a weak signal in either direction, but it surfaces the conversation, and that conversation is worth having on its own schedule rather than during an incident.

• Scope calibration for a privileged action. The package demonstrates the minimum viable surface — driver name, one-click clear — against what a production-grade version actually needs: authorization gating, a confirmation step, an audit trail, environment guards, rate limiting, and multi-store awareness so a flush hits the application cache store and not sessions, queues, and rate-limit counters sharing a Redis database. That gap is a product-scoping input, not just an engineering detail, and it generalizes to every privileged action we put in an admin panel.

• Use case fit: internal and staging environments; demo and QA environments where non-engineers need to bust config, route, or view cache after a deploy; small Laravel teams without a dedicated platform or DevOps function. It is explicitly not a production incident tool — the automated cache clear belongs in the deploy pipeline (php artisan optimize:clear or targeted view:clear/route:clear), and the card's job is the exception path: "something smells stale and I need to fix it now."

When to Consider This Package

Consider it — as a fork or reference implementation, not a dependency — only if all of these are true:

• You run Laravel Nova and intend to keep it for the next 18–24 months. The package has zero value outside Nova; a dashboard card is meaningless without the host panel, and adopting it drags Nova licensing and its private Composer repository into every build, container image, and onboarding path. An expired Nova license breaking CI for reasons unrelated to the card is a real operational cost.
• Your Nova installation is legacy (1.x/2.x era), or you have explicitly budgeted a port. The last release was February 2019 and almost certainly constrains Laravel to 5.7/5.8 and PHP to 7.1–7.3. Nova 4 moved cards to Vue 3 and Vite and changed the scaffolding; this component will not mount. Treat current-version compatibility as unproven until spiked, and budget a fork plus a version-bump pass — not a composer require.
• You need internal, low-blast-radius cache operations — view/config/route cache clearing and basic driver visibility — not tagging, key-level eviction, hit-rate analytics, or warmup orchestration. None of those are in scope, and the package is deliberately minimal with little to extend beyond subclassing the card and overriding withMeta().
• You have authorization sorted. Cache flushing is privileged and potentially outage-inducing. Verify the package's own route middleware rather than assuming the default nova group is sufficient — if it is only Nova-authenticated, any Nova user can flush production. Wrap or replace that middleware in a fork, and treat the card's canSee as cosmetic UX while the route gate does the real work.
• You accept owning the code. With 26 stars, zero dependents, no releases in seven years, and no security-response process, this is a vendored fork on day one: pin the exact version, copy it into a repo we control, name an owner, and carry a test suite that catches silent breakage on the next Nova bump. If we are not prepared to own it, we should not take the dependency.

Look elsewhere — or build it ourselves — if any of these are true:

• The requirement is production cache management with audit requirements. The card records neither who clicked it nor when, and the destructive action may not even prompt. For a privileged action, "who flushed production and when" is table stakes, not a nice-to-have. A fork or an in-house card with an explicit log line and a confirmation modal is the only defensible answer.
• We are on a modern Nova or planning to upgrade. The port is roughly a one-day job against php artisan nova:card acme/cache-card, which gives Vite, Vue 3, and correct asset registration — and we own the result. Once the honest cost of the fork is on the table, the build-versus-adopt gap closes almost entirely, and the build wins on maintainability.
• The need is actually observability rather than action. If the underlying question is "is the cache healthy, what is the hit rate, are we evicting too early," this package answers none of it. That is a different evaluation against a different set of tools.
• The team has no Nova at all. Then the entire premise collapses; the equivalent capability is a protected route and a button in whatever admin surface we already operate.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, free, MIT-licensed dashboard widget that lets a non-engineer see which cache driver is active and click one button to clear it, instead of pinging an engineer to run a terminal command. The capability is genuinely useful for staging and QA, and it costs nothing to acquire. The catch is that it was last updated in February 2019, has no maintainer, no security process, and will not run on a current Nova installation without a rewrite. So the honest recommendation is not to adopt it as a dependency — it is to treat it as a scoped reference design and spend roughly one engineering day building the equivalent ourselves, with the authorization, confirmation step, and audit logging that a privileged production-adjacent action requires. That framing turns a "free tool" into a one-day, fully-owned capability with a measurable return: fewer cache-related engineering interrupts per sprint, and a recorded answer to "who cleared it and when."

For engineering — the framing to agree on before any code is written:

• The integration surface is trivial and that is the point: one card class registered in NovaServiceProvider::cards(), one route, one Vue component. Anyone estimating this at more than a day is estimating the hardening, not the feature.
• The hardening is the actual work. The route must sit behind an explicit gate (can:flush-cache), not merely the nova middleware group. It must be rate-limited — throttle:5,1 is plenty for a human-driven action. It must log the actor, store, and environment. It should carry a confirmation step. And it must bind to a named cache store rather than config('cache.default'), because Cache::flush() on a shared Redis database will also wipe sessions, queued jobs, Horizon metrics, and rate-limit counters — that is the outage scenario, and an environment check belongs in the route handler, not just in the UI.
• Environment-scoped registration is the default posture: the card is present on local and staging, absent from production. If stakeholders want production visibility with the clear button disabled, say upfront that this requires the fork, because the shipped component is a single-action card, not a configurable one.
• Automated cache clearing stays in the deploy script. The card is the human exception path, not a pipeline component, and we should not let it drift into one.
• Success metric, agreed before launch: reduction in cache-related engineering interrupts per sprint, with zero unauthorized flushes. Both halves are testable. The first is a support-ticket count; the second is a test suite covering the forbidden-user case and asserting the flush is scoped to the intended store.
• Risk to name explicitly: unmaintained code, Nova 4/5 will not mount it, the asset pipeline is the usual failure point, and there is no audit trail out of the box. None of these are blockers for the build-it-ourselves path, and all of them are blockers for the take-the-dependency path.

Bottom line for the decision log: decline the dependency; approve a one-day in-house card scoped to staging and QA, gated, logged, rate-limited, and bound to a dedicated application cache store, with the interrupt-rate metric reviewed one sprint after launch.