Nova Multiple Dashboard Laravel Package

Technical Evaluation

Architecture fit

alexbowers/nova-multiple-dashboard is a Laravel Nova tool — a package that registers a service provider, extends Nova's dashboard controller/route/menu wiring, and lets you register more than one Dashboard class against Nova's single-dashboard UI. Architecturally it is a thin override layer sitting on top of Nova's internals rather than an independent subsystem, which means it inherits the coupling profile of Nova itself: any change to Nova's route names, menu registration, or Dashboard base class is a breaking change for this package.

For our stack this is a narrow but deep fit. It only makes sense if we are on Laravel Nova and specifically on a Nova major version that lacks native multi-dashboard support. Nova 4 introduced first-class, artisan-generated custom dashboards (php artisan nova:dashboard), which is the same capability delivered by the vendor. That materially changes the evaluation: the package's core value proposition has been absorbed upstream.

Integration feasibility

Low-to-moderate effort, conditional on our Nova version:

The hard blockers are not line-of-code volume (the package is small) but the dependency floor: an archived 2019 package pins an old Laravel/Nova/PHP triangle. Adopting it means either freezing part of our platform on end-of-life versions, or forking and forward-porting the override logic ourselves.

Technical risk

• Abandonment risk: high. Archived, deprecated in its own description, last release 2019-05-31. No security patching, no Nova compatibility fixes, no maintainer.
• Upgrade fragility: high. The package works by hooking Nova's dashboard routes and menu; that is exactly the surface Nova has churned across majors.
• Adoption/support risk: high. 33 stars, single author, no ecosystem. We are the maintainer on day one of any production use.
• Functional risk: moderate. Multi-dashboard introduces authorization questions (which roles see which dashboard) that this package does not clearly answer for us; we would be building policy around an unmaintained layer.
• Supply-chain risk: low. MIT-licensed, small, vendorable and auditable — forkability is the main mitigant.

Key questions

1. Which Laravel Nova major version are we on today, and is an upgrade to Nova 4+ already on the roadmap? (If yes, this package is a non-starter.)
2. What does the current need actually look like — distinct dashboards per role/team, or just card-level visibility rules? If the latter, Nova's native card canSee / authorization may solve it without any package.
3. Is there existing production usage of this package in our codebase? If so, what is the deadline and who owns the exit?
4. Do we have a hard constraint (paid Nova license version lock, legacy app) that prevents moving to Nova 4+?
5. If we fork, who is the named owner and what is the maintenance budget?

TPM read: the "opportunity" signal (0.8) reflects genuine demand for multi-dashboard capability — but that demand is now served by the platform. The correct product move is to not adopt, and to treat this package as migration debt if it is already present.

Integration Approach

Stack fit

Assumes Laravel + a licensed Nova install. The package is not usable outside Nova. It brings no database migrations of consequence, no queue workers, no external services — it is request-path glue. That makes it cheap to install and cheap to remove, which is the one genuinely favorable integration property.

Migration path

Two paths, and the decision gate is our Nova version.

Path A — we are on Nova 4 or can upgrade: do not install. Use native dashboards:

1. php artisan nova:dashboard {Name} to generate first-class dashboard classes.
2. Recreate each intended dashboard as a native Dashboard subclass with its own cards() method.
3. Move card authorization into Nova's native per-card visibility/canSee and Nova policies rather than a bespoke menu override.
4. Register menu visibility via Nova::mainMenu() / custom menu entries if role-based menu differentiation is required.

Path B — we are pinned to Nova 1.x/2.x and cannot move: fork, don't depend.

1. Vendor the package into packages/ or a private VCS repo; remove the upstream constraint.
2. Pin exact versions in composer.json and lock the Nova/PHP/Laravel triangle.
3. Add a compatibility test that asserts Nova's dashboard route and menu registration behave as the override expects — this is our canary for any future Nova patch.
4. Document the fork as an explicitly temporary shim with a target removal date tied to the Nova 4 upgrade.

Compatibility

Treat Nova's own versioning as the real compatibility contract, not the package's. Before any Nova or Laravel minor bump, run the canary test in staging; the failure mode is usually route/menu registration, which surfaces as a 404 or a missing dashboard rather than an exception.

Sequencing

1. Inventory (1–2 days): enumerate current dashboards, cards, and who is entitled to see each. Confirm whether requirements are dashboard-level or card-level.
2. Version decision (1 day): confirm Nova major version and upgrade appetite. This is a go/no-go gate.
3. Prototype on native (2–4 days): rebuild the highest-value dashboard as a Nova 4 native dashboard to prove parity and surface any capability the native path lacks.
4. Migrate / fork (1–2 weeks): either migrate remaining dashboards to native, or vendor the fork with tests and an owner.
5. Decommission: remove the package, delete fork, record the decision.

If we have no current usage, steps 1 and 3 collapse to a short spike and the answer is "no."

Operational Impact

Maintenance

Ownership transfers entirely to us. There is no upstream to patch, so the maintenance model is "we own this code the day it ships." For a fork, budget a recurring, low-but-nonzero cost: a review at every Nova/Laravel upgrade plus a canary test. For an unmodified dependency, the cost is unbounded — we cannot fix breakage without forking anyway, so the unmodified-dependency option is strictly worse than forking.

Support

Community-only and effectively nonexistent: 33 stars, archived, single author, no issue triage. Internal escalation path must be a named engineer who understands Nova's dashboard internals. Set expectations accordingly — this is not a "raise a ticket" component; it is a "read the source" component. The source is small enough that this is survivable, which is the main argument in its favor if we are truly stuck.

Scaling

Negligible runtime footprint — the package participates in request routing and menu construction, not in data loading. Card query cost, not the package, dominates dashboard latency; that is a pre-existing Nova concern and should be managed with caching, eager loading, and card-level pagination. Horizontal scaling is unaffected because there is no state.

The real scaling concern is organizational: every new dashboard request becomes a code change owned by us, with no vendor documentation or community patterns to lean on.

Failure modes

• Silent menu/route loss after a Nova patch — dashboard 404s or disappears from the sidebar; highest-probability failure and hardest to notice in tests that don't assert on routes.
• Upgrade dead-end — an intended Nova 4 upgrade is blocked because the override no longer applies; forces an unplanned migration project under time pressure.
• Authorization gaps — a bespoke multi-dashboard layer can bypass Nova's native policy checks, exposing a dashboard to the wrong role. Validate every dashboard against Nova policies explicitly.
• PHP/Laravel EOL exposure — the pinned dependency floor prevents routine security upgrades across the whole app, not just the dashboard.
• Bus-factor of one — the engineer who understood the override leaves; the code becomes untouchable and the upgrade freeze becomes permanent.

Ramp-up

Low for anyone already fluent in Laravel Nova (days), moderate for a general Laravel engineer unfamiliar with Nova internals (1–2 weeks of reading Nova's dashboard controller and menu registration). The mitigant is documentation: write a short ADR recording why the fork exists, what it overrides, and what the removal condition is. Without that, this component will quietly outlive its usefulness and its owner.