- What does limedeck/nova-cashier-overview actually do?
- It is a Laravel Nova card that surfaces Cashier and Stripe subscription metrics inside the Nova admin panel, including active, trialing, and canceled counts, MRR, churn and growth trends, and plan distribution. It is a read-mostly visibility surface, not a billing engine. It does not own, store, or mutate your billing records.
- How do I install limedeck/nova-cashier-overview in Laravel Nova?
- Install the package with Composer, register the card or tool in your NovaServiceProvider, optionally publish config, and clear caches. This assumes you already have Laravel, Nova, Cashier, and Stripe in place. Because the last tagged release is from 2022, resolve Composer constraints in a sandbox before touching production.
- Does this package support current Laravel and Nova versions?
- Compatibility is unknown until tested: the last tagged release was 2022-09-03, which predates multiple Nova majors, Cashier schema evolution, and Stripe API version changes. Expect narrow composer.json constraints and possible runtime breakage on current stacks. Treat a sandbox proof-of-concept as mandatory and be prepared to fork with widened constraints.
- Does it read local Cashier tables or call the Stripe API?
- The overview does not specify this, so source review is required before commitment. If it calls Stripe directly, caching strategy, rate-limit exposure, API version pinning, and failure behavior all matter. If it reads local Cashier tables, schema drift and stale data are the main concerns.
- Can I use this card with multi-tenant or multi-billable-model Cashier setups?
- Nova authorization, role gating, and tenant scoping must be verified rather than assumed. Multi-billable-model selection is not documented in the package overview. Test with representative tenants and roles before exposing customer names, emails, plan data, or revenue figures. Do not deploy until you have confirmed data cannot leak across tenants.
- Does the card include write actions like canceling or resuming subscriptions?
- The overview describes it as read-mostly visibility, but source review must confirm whether any cancel, resume, or mutate actions exist. If mutating actions are present, they require policy gating, audit logging, and explicit approval before production. Also verify which Stripe key and mode each environment uses.
- How should I test this package before deploying to production?
- Run a time-boxed sandbox proof-of-concept using test-mode Stripe data. Resolve Composer constraints, render the card against seeded Cashier subscriptions, and confirm the displayed metrics match Stripe and local Cashier records. Test Nova authorization, tenant scoping, caching behavior, and upgrade safety. Keep a feature flag or fork-and-patch fallback ready for the next Nova upgrade.
- Is caching configurable, and why does it matter for MRR accuracy?
- Configurable caching is not confirmed in the overview, and it matters because stale MRR or churn figures shown to finance are a credibility problem. If the card calls Stripe directly, caching also reduces rate-limit exposure and slows failure propagation. Verify cache TTL, invalidation behavior, and whether stale data is visibly indicated.
- What are the alternatives to this package for a Cashier and Stripe dashboard?
- Alternatives include Stripe's own dashboard and revenue reporting, custom Nova cards or dashboards, direct queries against local Cashier tables, and third-party SaaS analytics tools. Adopt this package only when Nova is already your internal admin standard and Cashier with Stripe is the billing source of truth. Do not introduce a Nova license just to obtain one dashboard card.
- Is limedeck/nova-cashier-overview actively maintained?
- The project has roughly 30 stars, zero dependents, no vendor SLA, a single maintainer, and about three years without a release as of the assessment. That makes it unsuitable as a strategic platform dependency. It is acceptable only as an internal convenience tool with a named owner and a documented exit path, and you should assume fork ownership from day one.