Multitenancy Nova Tool Laravel Package

Technical Evaluation

Architecture fit: The package remains a Laravel Nova admin UI for managing multitenancy, not a tenancy engine. Release 4.0.0 materially improves fit: it now targets Nova 4, Laravel 10, and PHP 8.1+, which removes the previous "archived and stack-mismatched" blocker for teams on that generation of the stack. It is still only appropriate where the platform already runs Laravel Nova plus a compatible multitenancy package and needs an admin surface for tenant lifecycle operations. It remains a poor fit for greenfield platforms, API-only products, and teams already on Laravel 11/12 or Nova 5. Treat it as a UI reference implementation or a fork candidate, not a strategic dependency.

Integration feasibility: Improved but still conditional. Installation is a normal Composer package plus Nova tool registration, and the dependency constraints are now plausible for a Laravel 10/Nova 4 environment. Two caveats: (1) the release notes confirm modernization but do not indicate the repository has been unarchived, so upstream maintenance is still not assumed; (2) vyuldashev/nova-permission was replaced with kiritokatklian/nova-permission, which trades one third-party dependency for another smaller-maintainer fork — supply-chain and longevity diligence is still required. The tool's assumptions about tenant models, domain routing, database-per-tenant provisioning, cache/queue separation, and Nova authorization still must be verified against the existing tenancy implementation before any spike. Zero dependents and low stars mean ecosystem validation is still absent.

Technical risk: Medium-high (down from high). The primary risk has shifted from "will not run at all" to "runs, but on a stack generation that is already one major version behind current Laravel and Nova." Laravel 10 and Nova 4 are supported-but-aging; the next Laravel/Nova upgrade cycle will land on this fork again. The permission package swap is a breaking change for anyone on 3.x and may require role/permission data migration and authorization-path changes. The most serious risk is unchanged: silent cross-tenant data leakage if the UI triggers incomplete provisioning or connection switching. The opportunity score stays high, and the modernization narrows the gap, but archived status and lack of dependents still argue against adoption without a fork.

Key questions:

• Which multitenancy package and version does 4.0.0 target: stancl/tenancy, spatie/laravel-multitenancy, or custom?
• Is the repository still archived, and is there any stated intent to support Laravel 11/12 or Nova 5?
• What breaking changes ship in 4.0.0 beyond the platform bumps — particularly role/permission schema changes from the nova-permission swap?
• Does kiritokatklian/nova-permission have an active maintainer, compatible license, and a migration path off vyuldashev/nova-permission?
• Does the tool enforce tenant isolation server-side, or is it only an admin convenience layer?
• How are tenant databases, domains, caches, queues, and filesystems provisioned and rolled back?
• Is the license compatible with an internal fork and redistribution?
• What is the exit plan if the fork becomes unmaintainable?

Integration Approach

Stack fit: Now acceptable for a Laravel 10 / Nova 4 / PHP 8.1+ stack with a matching tenancy implementation — a meaningful change from the prior assessment. For Laravel 11/12 or Nova 5 environments, still do not adopt as-is; use the package as a pattern library for tenant CRUD, domain management, and provisioning workflows, then build an internal Nova tool against the current tenancy API. Teams on the frozen legacy stack should still prefer the fork-and-harden path over direct Composer adoption.

Migration path: Fork the repository into the organization, pin all dependencies, and add a compatibility matrix anchored on 4.0.0. If the current stack matches Laravel 10/Nova 4, run a non-production spike covering tenant creation, domain binding, database provisioning, cache/queue isolation, deletion/rollback, and the new permission package's role/permission behavior. If migrating from 3.0.0, treat this as a breaking upgrade: plan a data migration for roles/permissions, re-verify Nova tool registration and asset publishing, and re-test all destructive tenant actions. If the stack does not match, extract the UI and workflow ideas and reimplement. Do not expose the tool to production admins until isolation tests and authorization checks pass.

Compatibility: Constraints should now resolve cleanly against Laravel 10, PHP 8.1+, and Nova 4 — verify rather than assume. Confirm the tenancy package's supported version range, since 4.0.0's modernization may or may not track that package's current migration and bootstrap APIs. Confirm kiritokatklian/nova-permission resolves and that no transitive dependency still pulls the abandoned vyuldashev package. Note explicitly that Laravel 11/12 and Nova 5 are out of scope.

Sequencing:

1. Confirm tenancy package, version, and tenant isolation model.
2. Confirm repository archival status and secure an internal fork with a tagged 4.0.0 baseline.
3. Audit the permission package swap: license, maintainer activity, schema changes, and data migration steps.
4. Add CI and automated tests for provisioning, rollback, domain conflicts, cross-tenant access, and role/permission enforcement.
5. Run the staging spike on synthetic tenants.
6. Add RBAC hardening, audit logging, and approval gates for destructive tenant actions.
7. Roll out to production admins with monitoring and a documented rollback plan.
8. Schedule the next Laravel/Nova upgrade as explicit fork work.

Operational Impact

Maintenance: High, though lower than before. Archived status still means internal ownership forever; the modernization merely resets the clock. Assign a maintainer, budget quarterly dependency reviews, and plan for the Laravel 11/12 and Nova 5 upgrade work that will arrive shortly. The package cannot rely on upstream fixes, and the new permission dependency is itself a fork-of-a-fork that may need to be replaced again.

Support: No vendor or active community support. Support will be internal runbooks, tests, and a fork. Document tenant provisioning steps, permission migration from 3.x, failure recovery, and escalation paths.

Scaling: The admin UI itself is low-scale, but tenant provisioning can be heavy. Provisioning must be queued and idempotent. Avoid synchronous database creation in Nova requests. The tool should not sit on the runtime request path for tenant resolution.

Failure modes: Partial tenant creation, orphaned databases, domain collisions, cache/queue cross-tenant leakage, failed rollback, permission-regression after the nova-permission swap (admins losing or over-gaining tenant access), and Nova UI errors blocking admin operations. Destructive actions need soft-delete, audit trails, and two-step confirmation. Monitor provisioning jobs and tenant health separately from the Nova UI.

Ramp-up: Engineers need familiarity with Laravel Nova 4, the chosen tenancy package, and the fork's internals. Estimate one week for the technical spike now that stack compatibility is no longer the gating unknown, and three to five weeks for a hardened internal fork, plus additional time if migrating from 3.0.0 with permission data. Include security review and tenant-isolation testing in the estimate.