Laravel Auto Tenancy Laravel Package

Product Decisions This Supports

• Feature scoping for enterprise tiers. Per-tenant database isolation is the kind of capability that gates deals in regulated or security-conscious segments (health, finance, gambling-adjacent esports). This package directly informs whether "isolated tenant data" ships as a v1 platform capability or a paid enterprise add-on.
• Build vs. buy vs. borrow. Use it as a pricing input for the build option: DB-per-tenant done properly means connection lifecycle management, migration fan-out across N databases, queue/scheduled-job context propagation, provisioning and offboarding automation, and backup/restore per tenant. That is typically 2–4 engineer-weeks plus permanent maintenance. A package like this is a "borrow" candidate to compress that.
• Architecture fork with roadmap consequences. Post-authentication tenant resolution ("switch connection after login") is a genuine architectural commitment. It constrains onboarding flows (invite-based signup, SSO, free trials), the shape of the login experience, and how you handle users who belong to multiple tenants. Choosing it now is cheap; reversing it later is not.
• Packaging and pricing decisions. Database-per-tenant unlocks clean per-tenant backup/restore, per-tenant deletion (GDPR erasure SLAs), and cost pass-through on infrastructure — all of which support a premium "isolated" tier and defensible pricing above shared-schema competitors.
• Operational roadmap. Forces explicit answers on tenant lifecycle: how tenants are provisioned, suspended, migrated, and offboarded, and whether you invest in internal ops tooling before or after launch.
• Risk register input. The package's adoption signal (33 stars, 0 dependents, unknown license) is itself a decision input: it tells you the ecosystem has not validated this implementation, so you would be an early adopter absorbing edge-case discovery costs.

When to Consider This Package

Consider it when all of the following hold:

• You are on Laravel, running a monolith or a small number of services, with a small platform team.
• Your tenancy model is genuinely database-per-tenant, not shared-schema with row-level scoping.
• Tenant identity can be resolved at authentication time — i.e., a user's session maps to one tenant, and you are not designing for heavy cross-tenant switching mid-session.
• You are evaluating it as a reference implementation or prototype accelerator, not as a production dependency.

Look elsewhere when:

• License clarity is required. The NOASSERTION license is a hard stop for legal and procurement. Until the license is explicit and compatible with your distribution model, this cannot be approved for production — full stop.
• You need vendor or community support. 33 stars, zero dependents, and a single organizational maintainer means no ecosystem, no Stack Overflow surface area, and no security-response process. You will be the first to hit most edge cases.
• Your async surface is large. Queues, scheduled jobs, websockets, and event listeners must all carry tenant context. Verify this rigorously; silent context leakage in queued jobs is the classic multi-tenancy failure mode.
• You need cross-tenant analytics or admin reporting, which DB-per-tenant complicates considerably.
• A mature alternative exists. stancl/tenancy and spatie/laravel-multitenancy are the mainstream Laravel choices with real adoption, clear licensing, and community support. Default to those unless you have a specific reason not to.
• Data residency or compliance certification is on the critical path — in which case you need an audited, supported dependency, not a 33-star package.

How to Pitch It (Stakeholders)

For executives: This is an evaluation of a small open-source Laravel package that solves a specific, high-value problem — giving every customer their own isolated database, switched automatically when they log in. The capability matters commercially: it underpins enterprise pricing, clean data-deletion guarantees, and per-customer backup and restore.

The recommendation: treat it as a design reference, not a dependency. Three reasons: the license is undefined, so legal cannot approve it; it is maintained by a single organization with no downstream adoption, so we would absorb all edge-case risk ourselves; and there is no support path if it breaks.

The ask: a short engineering spike to evaluate the pattern against our requirements, followed by a build-vs-adopt decision weighted toward a mainstream package (stancl/tenancy or spatie/laravel-multitenancy). The likely outcome is adopting one of those, using this package's approach as a sanity check on our design. Cost of the spike is small; cost of shipping an unlicensed, unmaintained dependency into a customer-facing isolation boundary is not.