Multitenancy Nova Tool Laravel Package

Product Decisions This Supports

• Admin UX for tenancy operations: Informs whether to provide Nova-based screens for creating, switching, and managing tenants, domains, and tenant-scoped resources instead of relying on raw database operations or custom dashboards.
• Build vs. buy vs. borrow: The 4.0.0 release materially improves the borrow/fork case — it now targets Nova 4, Laravel 10, and PHP 8.1+, and swaps an abandoned permissions dependency (vyuldashev/nova-permission) for a maintained one (kiritokatklian/nova-permission). Adoption as a pinned internal dependency is now more defensible than before, but it still isn't a strategic "buy."
• Roadmap sequencing for multitenancy: Helps decide whether tenant administration is a near-term internal-operations need or a later self-service capability. This package remains best suited to internal/admin tooling, not tenant-facing provisioning.
• Operational readiness: Supports decisions around onboarding tenants, support impersonation/tenant switching, access boundaries, and auditability in a Laravel Nova admin surface.
• Risk and maintenance planning: The dependency swap removes a known abandoned transitive dependency, which lowers supply-chain and upgrade risk. However, a single release after a period of dormancy is one data point, not proof of sustained maintenance — plan for fork ownership and pinning regardless.
• Stack-fit gating: The release sharpens the compatibility decision: teams on Nova 4 / Laravel 10 are now covered out of the box; teams already on Nova 5 / Laravel 11+ must budget for upgrade work or treat the package as reference only.
• Use-case validation: Useful as a lightweight prototype or pattern reference for Laravel/Nova teams evaluating how much tenancy management belongs in the admin panel versus the core application.

When to Consider This Package

Consider it when:

• You already run Laravel Nova 4 and have an existing multitenant Laravel application on Laravel 10 / PHP 8.1+.
• You need a small internal admin tool for tenant management, tenant switching, or tenant-scoped Nova resources.
• You are willing to pin, own, and maintain the package (fork or internal fork-lite) — 4.0.0 makes this cheaper but does not remove the need.
• Your Nova/Laravel versions match the release, or you can budget for upgrade work to Nova 5 / Laravel 11+.
• The feature is internal and low-risk: no direct tenant-facing exposure, no security-critical authorization logic delegated to the package.
• You want to use it as a reference implementation or a fork base rather than an unpinned dependency.

Look elsewhere when:

• You are starting a new project on Laravel 11/12 or Nova 5 and need current-stack compatibility out of the box.
• You require vendor support, SLAs, or a credible multi-release maintenance track record.
• You need robust tenant provisioning, billing, isolation, audit logging, or self-service onboarding.
• Your security model depends on the package's tenant-boundary enforcement.
• You cannot accept ownership of an upgrade path — including the next Nova/Laravel major.

How to Pitch It (Stakeholders)

For executives: This is a small Laravel Nova admin tool for managing tenants. The new 4.0.0 release brings it onto Nova 4 / Laravel 10 / PHP 8.1+ and replaces an abandoned dependency, which lowers the technical risk of using it for internal tenant-management screens. It remains a narrow internal-operations tool with limited visible adoption, not a strategic or customer-facing dependency. Recommended posture: adopt as a pinned internal component with a named owner, or fork it — the value is faster internal operations, not differentiated customer functionality.

For engineering: 4.0.0 clears the main compatibility blocker (Nova 4, Laravel 10, PHP 8.1+) and removes the abandoned vyuldashev/nova-permission dependency in favor of kiritokatklian/nova-permission — review that substitution for authorization behavior and transitive risk. Treat the release as a green light to evaluate seriously rather than a maintenance guarantee: it's one release after dormancy, and it still lags Nova 5 / Laravel 11+. If adopted, pin the version, add tests around tenant switching and access boundaries, audit tenant-isolation assumptions, and assign an owner for the next major upgrade. If you're already on Nova 5 / Laravel 11+, use it as a design reference or fork base instead.