Nova Multi Tenant Manager Laravel Package

Product Decisions This Supports

• Build-vs-buy: this package is evidence for "build," not "buy." It is archived, has ~20 stars, zero dependents, and last shipped in May 2024 (a compatibility-only Laravel 11 bump). The real decision it frames is narrower than adoption: fork the source as internal tooling, build a thin Nova slice ourselves, or descope tenant admin for this cycle.
• A ready-made feature spec for the tenant admin surface. Use it to pin the minimum useful UX — tenant CRUD, domain/hostname management, user-to-tenant assignment, tenant-aware resource listings, and a tenant switcher. That gives PM, design, and engineering concrete acceptance criteria without committing to the implementation.
• Separating the two "multi-tenancy" layers — the highest-value insight here. The expensive, risk-bearing layer is data isolation: tenant resolution, query scoping, per-tenant migrations, queue/cache separation. This package only ever addressed the cheap layer — the Nova admin surface. Keep roadmap investment on the isolation layer and treat admin UX as a bounded internal build.
• A vendor/lifecycle risk register entry. Nova is a paid, actively major-versioned first-party product; pairing it with an unmaintained extension that hooks Nova internals is a fragility multiplier. The supporting principle: minimize custom Nova internals and never depend on abandoned admin extensions.
• Shortcut prevention in grooming. Zero dependents after two-plus years plus an archive flag is near-zero ecosystem validation. A PM can use this to kill a "just install the Nova multi-tenant package" suggestion before it consumes a sprint.
• Security scoping for a privileged surface. A tenant switcher is not neutral UI — it needs authorization boundaries, audit logging, impersonation controls, and regression tests proving scope cannot be bypassed. None of that ships with the package, so the PM must make it explicit scope rather than assume it.

When to Consider This Package

• Only as source material or a fork candidate. Consider reading or forking it if you already run Laravel Nova, need a tenant switcher in an internal admin panel, and a small bounded build costs more than using this as a UX/feature reference. Budget for permanent team ownership: no upstream fixes, no security patches, no future Laravel/Nova compatibility work.
• Only for internal, low-blast-radius tooling. Acceptable where the surface sits behind SSO and role checks, and where a bug means a confused support agent — not cross-tenant data exposure.
• Only with a simple tenant model. Single database, session-driven tenant context, an existing tenancy implementation. If you need per-tenant databases, subdomain/domain routing, queue and cache separation, or background-job tenancy, this is not the layer you need anyway — and if tenancy itself is unbuilt, the build-vs-adopt question collapses to "build."
• Look elsewhere — or build — if any of these are true: tenant isolation sits on a security or compliance boundary; you need a maintenance commitment, SLA, or CVE response path; you are on Laravel 12+ or a Nova major released after May 2024; you need audit trails or impersonation controls around who may switch tenants; no engineer can be named as owner; or license/provenance for internal redistribution is unclear.
• Do not consider it merely because it is already on Packagist. An archived package with zero dependents is not a safe default, least of all for a privileged admin surface.

How to Pitch It (Stakeholders)

• Executives: This is abandoned open source, not a supplier relationship — archived, negligible adoption (~20 stars, no dependents), last shipped May 2024. Recommendation: do not adopt it as a dependency. Either fund a small internal build for the Nova tenant-admin surface or descope it this cycle. The build cost is bounded and known; the cost of owning an unmaintained privileged admin tool is neither.
• Engineering: Treat the repository as a specification, not a dependency. If we proceed, fork it, mirror it internally, pin a commit SHA, record provenance and license, and assign a named owner. Two risks dominate: (1) it hooks Nova internals while Nova is commercial and major-versioned, so every Nova upgrade becomes our migration; (2) a tenant switcher is a privilege-escalation surface, requiring an authorization model, audit log, and tests we write ourselves. Separately confirm the real tenancy layer — data isolation, queue/cache scoping, per-tenant migrations — is handled by a well-adopted package or our own code; this package never solved that.
• Ask: approve a one-week spike to fork, wire the switcher behind SSO and role checks, and validate against our current Laravel and Nova versions — with the fork-vs-replace-vs-build decision gate at the end — or descope to next quarter. What we should not do is composer require it and move on.