digital-creative/nova-dashboard
A flexible dashboard package for Laravel Nova that lets you build custom dashboards and organize cards and metrics into tailored layouts, giving you more control over what appears on your Nova home screen.
Prerequisites to verify first: this package is a Nova add-on, not a standalone dashboard. Confirm three things before writing any code: the Nova major version in composer.json, the PHP/Laravel versions in the same file, and whether native Nova dashboards (4.x+) already cover the requirement. The last release was 2024-03-28, so treat declared Composer constraints as a claim to test, not a fact.
Minimal setup path:
composer require digital-creative/nova-dashboard and pin the exact version in composer.lock — do not use a floating constraint on a low-traffic package.php artisan vendor:publish --provider="DigitalCreative\NovaDashboard\..." — confirm the exact provider FQCN from the published README or composer show -a).config/app.php or NovaServiceProvider only if auto-discovery does not handle it. Run php artisan route:list | grep -i dashboard to confirm the route registered.Where to look first: the published config file, then vendor/digital-creative/nova-dashboard/src — the package is small, so reading the dashboard registration class directly is faster than hunting for docs. Cross-reference against NovaServiceProvider to see what is actually wired.
First use case to build: a single pilot dashboard ("Support" or "Ops") with two or three existing cards you already have. Do not build new card classes for the pilot — the whole value proposition is re-composing primitives you own. This gets you a working screen in half a day and validates routing, auth, and rendering before you invest in layout decisions.
Config-driven, one dashboard per job-to-be-done. The core pattern is: define a named dashboard, attach cards, done. Resist the urge to make one mega-dashboard with everything — the package's entire reason for existing is that each team gets a focused landing page. Name dashboards after audiences (support, finance, onboarding), not after content (metrics, reports).
Keep card classes in your application namespace. Define cards and metrics as you normally would under app/Nova/Cards and app/Nova/Metrics, then reference them in the dashboard config. This keeps the package as pure orchestration — swapping it out later means changing a config file, not rewriting widgets. Every widget you write should have an obvious native-Nova equivalent noted in a code comment or runbook.
Role-targeted views via your own gate, not the package's. Dashboard visibility is best handled by conditional registration in NovaServiceProvider (Nova::when(...) or a Gate check) rather than relying on the package's per-dashboard authorization. Nova's canSee on individual cards still applies, but be explicit: a dashboard's route existing is not the same as its contents being authorized.
Feature-flag the route during rollout. Run the package dashboard alongside the native Nova dashboard behind a config flag for one or two sprints. Compare with real users, then consolidate. Rollback should be "remove provider registration and route" — rehearse that before you ship.
Cache aggregate cards. Dashboard landing pages are the most-hit screen in an admin panel. Any ValueMetric or trend card that runs an aggregate query should be wrapped in Cache::remember with a short TTL, or backed by a summary table. Profile each card's query on production-like data volumes before launch, not after.
Compose with existing Nova primitives. Lens-backed tables, trend metrics, partition metrics, and custom cards all work as long as they are already registered. The pattern that ages best: dashboard config lists card class strings; cards stay thin; heavy lifting lives in the metric/card class the app already owns.
Nova major upgrades are the main breakage surface. Nova's unpublished-package conventions (tool registration, asset publishing, Blade override points) change between majors. Any Nova bump should be a deliberate, tested change with the package version pinned and a staging parity check. Do not float Nova's constraint.
Redundancy with native Nova is the real risk. If you are on Nova 4+, build the one-page comparison first: native dashboards vs. this package. If native already gives per-role views, adopting this is maintenance cost with no delta. This is the single decision that determines whether the rest of this assessment matters.
Authorization leaks are silent. Dashboard routing does not guarantee per-tenant or per-policy scoping. For each card, verify: does the underlying query respect Nova policies, lens filters, and tenant scoping? Write at least one test per card that asserts an unauthorized user sees no data — a missing scope here is both a data-exposure bug and a query-storm bug.
php artisan config:cache will bite you. Config-driven dashboards mean a stale config cache after deployment shows the wrong dashboards. Add config:clear/config:cache to your deploy script and verify the dashboard list post-deploy.
Published assets and Blade views can collide with your Nova customizations. If you publish views or brand assets, check for clashes with your nova theme overrides after every upgrade. Keep published files in version control so diffs are visible.
Debugging checklist when a dashboard goes blank: (1) is the provider registered? (2) does route:list show the dashboard route? (3) does the card class exist and is it registered in NovaServiceProvider? (4) is the config cached? (5) does the user pass the card's canSee? Work in that order — the first four cover most failures.
Treat the package as forkable, not supported. Zero dependents, 72 stars, last release March 2024, no vendor bench. The MIT license is your hedge: name an internal owner for the fork-or-fallback decision, keep a patch queue, and document the native-Nova equivalent of every widget so the exit is a configuration change rather than a rewrite. Do not let this land on a critical path.
How can I help you explore Laravel packages today?