Laravel Nova Contexts Laravel Package

Product Decisions This Supports

The real decision is "Nova vs. an alternative admin stack," not "adopt this package." novius/laravel-nova-contexts is only useful once you have already bought into Laravel Nova (a paid, first-party admin panel) and are running more than one site, store, or brand off a shared codebase. Frame it that way in any roadmap conversation — it is an enabler inside a larger platform bet, not a standalone line item.

• Multi-context admin consolidation (build vs. buy). The core use case is one admin panel serving N contexts (sites, stores, brands, regions) with resources automatically scoped to the active context and a header switcher for operations staff. The build alternative is either (a) separate deployments/admin panels per brand — cheap to start, expensive to maintain and impossible to staff with one ops team, or (b) bespoke scoping in Nova resource queries, filters, and policies — roughly a sprint of work, plus permanent ownership. This package is the "buy" option worth pricing against that sprint.
• Roadmap: launching brand/site #2 through #N. The decision it most directly supports is whether the next market launch is a configuration exercise or a fork. If context scoping works, each new site is a contexts row plus content, not an engineering project — that changes launch cost curves and is a legitimate board-level story.
• Admin surface scoping, not data tenancy. It answers "how do operators see only their context's data," which is a UX/productivity problem. It does not answer "how do we guarantee tenant data isolation" — that is a database/architecture decision. Conflating the two is the single most expensive mistake available here.
• Sequencing decision: this depends on a second internal package. It integrates with the Novius Contexts ecosystem (context-aware models and middleware). So the product decision is really a bundle decision — adopting this implies adopting or already owning Novius Contexts. Treat the two as one dependency, one evaluation, one upgrade liability.
• Explicitly not supported: customer-facing multi-tenancy, per-tenant provisioning/billing, or isolation guarantees. If a roadmap item needs those, this package is not the mechanism and should not be cited as one.

When to Consider This Package

Adopt the evaluation, not the package, when all of these hold:

• You are already committed to Laravel Nova. The license is already paid and the team is fluent. If Nova is still an open question, evaluate Filament (which ships first-party tenancy) before spending time here.
• You are on, or can pin to, Laravel 9. The last release (1.1.0, July 2022) exists solely to add Laravel 9 support. On Laravel 10+ this is stale by default; on Laravel 8 this release may have dropped you. Resolve your framework version before anything else.
• You already use, or will adopt, Novius Contexts. This is a UI/scoping layer over that ecosystem, not a self-contained tenancy solution.
• Context count is modest and schema is shared. Say 2–20 contexts with broadly the same models and fields. If contexts need divergent schemas or per-context databases, the abstraction is the wrong shape.
• The surface is internal admin only. Nothing on the customer request path should depend on it. That keeps the blast radius of a stale or abandoned dependency contained.
• You can absorb ownership. Zero stars, one release note in three years, small vendor. Adopt only if you have someone who can read the source, fork it, and patch it — or budget for a support arrangement. Assume no upstream SLA.
• You can afford a one-to-two-week spike to validate context switching, filter correctness, and policy behaviour against your real models before committing.

Look elsewhere when:

• You need active maintenance, a support contract, or a documented Laravel 10/11/12 path. Ask for the maintainer's roadmap in writing; "no answer" is the answer.
• You need hard tenant isolation (row-level security, separate databases, per-tenant encryption keys) — that is a platform architecture job, not a Nova tool.
• You are greenfield and Nova is not yet bought — the incumbent alternative has more momentum and a larger hiring pool.
• Multiple teams will depend on the scoping contract. A 0-star dependency becoming a cross-team interface is a governance problem waiting to happen.

How to Pitch It (Stakeholders)

To the executive / budget holder. "Our admin panel is one panel for all our brands, and the tooling to make that work already exists and is free — but it's a small, unmaintained open-source add-on, and it sits on top of a paid Nova license. The prize is real: each new brand or site becomes a configuration task instead of an engineering project, and one ops team can serve all of them. The cost is that we'd own the maintenance. I'm recommending a two-week, time-boxed spike rather than a commitment: one engineer proves context switching and data scoping work on our actual models, and comes back with a go/no-go plus a maintenance estimate. If it's a no-go, the fallback is a sprint of custom scoping in Nova — so the downside is bounded and we learn the same thing either way."

To engineering. "This is a thin scoping layer, not a tenancy framework — do not let anyone describe it as one. It gives us a context switcher in the Nova header, automatic resource scoping, and context-aware fields and filters, and it depends on the Novius Contexts package for the underlying models and middleware. Two things to verify in the spike: first, whether the composer constraints actually resolve on our Laravel version, since the only shipped release note is 'Laravel 9 compatibility' with no changelog; second, whether its scoping story satisfies the isolation bar our security review will set, or whether we still need per-context guards underneath. Assume we may fork it — assess how invasive that would be before we build on top of it. Capture the config keys and any published migrations in the integration ticket while the change is fresh; that's the knowledge we'll need at the next framework upgrade."

To the ops / content team (the actual users). "The pitch to you is a dropdown in the admin header: pick your site or brand, and every list, filter, and form shows only that context's data. No second login, no second URL. The thing we need from you in the spike is a realistic walkthrough — the tasks you do weekly, in the order you do them — so we find out early whether context switching holds up under real usage or only in a demo."

The one-line framing for any steering update: low-cost, bounded experiment to convert a per-brand launch cost into a configuration cost; conditional on a framework version we control and a maintenance owner we name.