Nova Multi Tenant Manager Laravel Package

Technical Evaluation

Architecture fit. The package is an operator-facing Nova admin surface, not a request-path component — which is what makes it usable at all. It gives Nova a tenant switcher, tenant-scoped resources, tenant/domain CRUD, and tenant-aware provisioning actions. It supplies no tenancy: no tenant resolution, no per-tenant database routing, no queue/cache separation. So the first TPM move is a scoping decision, not an evaluation: this is only leverageable if a real tenancy model already exists. If tenancy is unbuilt, this package is a UI over work still to be done, and build-vs-adopt collapses to "build." A second fit concern is ownership: if tenant provisioning already lives in a control plane (billing, onboarding, support tools), a Nova widget splits that workflow across two systems and creates a reconciliation problem a TPM will end up adjudicating.

Integration feasibility. Mechanically trivial — Composer install, service-provider auto-discovery, config publishing, middleware registration; a day to spike. The blocker is lifecycle, not engineering. The repo is archived with last release May 2024, ~20 stars, zero dependents, single-maintainer lineage, and a score of 0.29. The only documented release signal is "Laravel 11 compatibility." There is no adopter population to surface edge cases before we do, and no forward path to Laravel 12+ or any Nova major released after mid-2024.

Technical risk. Ranked by what a TPM actually has to manage:

• Terminal dependency risk (dominant). Archived mean no CVE response, no issue triage, no compatibility work. Ownership transfers to us on day one.
• Security surface misclassified as UI. Tenant switching is a privileged action and tenant scoping is an authorization boundary. A silent scope bypass is a cross-tenant exposure — contractual and possibly regulatory. The package does not ship audit logging, impersonation controls, or role boundaries around who may switch tenants.
• Paid-dependency mismatch. Nova is commercial and major-versioned aggressively; pairing it with an unmaintained extension guarantees half the stack moves and half cannot.
• Pre-1.0 with no forward path. 0.7.x carried no semver guarantee; archival removes both API stability and migration guidance.
• Unverified non-functional claims. No evidence of test coverage, Octane support, queue serialization handling, or scope-bypass hardening.

Key questions to get answered before committing.

1. Does the tenancy model already exist, or is this masking an unbuilt capability?
2. Is scope enforcement in this package or our models? If the former, who owns the code and the audit evidence?
3. Which Nova major are we on, and what is its upgrade horizon? Archived means the answer is "fork" or "stop upgrading Nova."
4. Can we lawfully fork and redistribute internally? Confirm license and trademark/branding constraints.
5. What is the replacement cost (native Nova tooling, maintained alternative, ~2–4 weeks internal build) versus owning a fork?
6. Who is the named internal owner, and what is the written exit trigger?

Integration Approach

Stack fit. Laravel 11, PHP 8.2+, current Nova major (verify against package constraints first). Confirm database, cache, queue, and Octane posture up front. Admin-only deployment makes load characteristics trivial; correctness characteristics are not.

Migration path — reframe this as a fork, not an adoption. The TPM's job is to stop a composer require from happening.

• Mirror the source into an internal repo under our namespace, or pin a Composer VCS/path repository to a specific commit SHA. Never point production at upstream.
• Record provenance in the dependency register: upstream URL, archival date, commit SHA, license, named owner. This is the artifact auditors and future maintainers will ask for.
• Pin explicitly (^0.7 or a commit hash). Never dev-main or * — an archived repo can still be force-pushed or deleted; a mirror kills that failure mode.
• Commit published config into the application repo so behaviour versions with the app, not with vendor code.

Compatibility. Build a CI matrix of Laravel 11 minor × Nova major × PHP 8.2/8.3 × database driver × queue driver. That matrix is the upgrade gate for every future framework bump, because there is no upstream to lean on. Explicitly test the paths the release note is silent on: queue serialization, model casting, cached config, and middleware ordering against Nova's own auth pipeline.

Sequencing.

1. Week 1 — spike. Throwaway branch, boot on Laravel 11, exercise the switcher and scoped resources, and inventory what the package owns versus what our models own. That inventory is the fork-cost estimate.
2. Decision gate. Choose (a) fork and own, (b) replace with maintained/ first-party Nova tooling, or (c) build the thin slice internally. Bring the inventory plus a three-release maintenance estimate.
3. Isolation. Wrap behind a thin application-level adapter (our facade delegating to it) — one file to change when the world moves.
4. Security review before GA. Prove scope cannot be bypassed via a resource missing a trait, a custom action, a lens, or a raw query. One regression test per Nova resource.
5. Internal-operators-only canary before any customer-facing exposure.
6. Schedule the sunset review now at the next Nova major or Laravel major, whichever lands first.

Operational Impact

Maintenance. The cost does not vanish on archival; it transfers to us. Budget roughly 1–3 engineer-days per framework or Nova minor upgrade, plus the cost of the first security finding. The decisive test: if no named owner can be assigned, that is the decision — do not adopt. Confirm the license permits internal forking and redistribution before building on it.

Support. No upstream path exists — no triage, no disclosure channel, no SLA. Our team becomes the escalation tier for every bug and every CVE scanner hit. Frame this for stakeholders explicitly: "open source" here means unsupported, not free. It should land as an ownership transfer, not a procurement saving.

Scaling. Operationally negligible — this is the admin panel, not customer traffic. The scaling risk is organisational: as tenant count grows, the switcher UI and tenant-scoped query patterns become the bottleneck. Watch for N+1s introduced by scoping, and for tenant-resolution middleware applied per-request rather than per-Nova-request — that would turn an admin tool into an unintended production dependency.

Failure modes to instrument.

• Cross-tenant data exposure — highest severity, lowest detectability. Mitigate with per-resource regression tests and an audit log on every tenant switch.
• Silent scope bypass — a new Nova resource or action that fails to opt in; fails open. Add a PR checklist item and a lint rule.
• Privilege escalation via tenant switching — insider-risk vector by definition; the package does not solve it.
• Nova/Laravel major breakage — guaranteed eventually, unplannable without the scheduled sunset review.
• Composer resolution conflicts with packages on older illuminate/* constraints — surfaces at upgrade time, when options are fewest.
• Drift between the package's tenant model and ours — catch with schema-contract tests.

Ramp-up. A Laravel-fluent engineer can spike it in about a day. A safe fork — adapter, security wrapper, regression tests, review — is realistically 1–2 weeks. On-call needs a short runbook covering how tenant context is switched, where the audit log lives, and who to page when scope looks wrong.