Laravel Auto Tenancy Laravel Package

Technical Evaluation

Architecture fit

• The package addresses a real, high-stakes pattern: database-per-tenant isolation with connection switching after authentication. That is the most defensible isolation model for compliance-sensitive data (data residency, per-tenant backup/restore, blast-radius containment) and avoids the query-scoping footguns of shared-schema row-level tenancy.
• "Post-authentication" is the architectural crux. Tenant context is not known until a user (or token) is resolved, which means:
  • The tenancy resolver must live in or after the auth middleware, and its correctness depends on precise middleware ordering.
  • Unauthenticated surfaces (login, registration, password reset, SSO callbacks, health checks, webhooks) execute against a default connection. This must be an explicit, audited design decision, not an accident.
• Per-tenant databases shift complexity from the ORM to operations: N databases to provision, migrate, back up, restore, and monitor. The package handles connection switching; it likely does not solve provisioning orchestration, migration fan-out, or cost controls.

Integration feasibility

• Feasibility hinges on whether the package integrates through Laravel's DatabaseManager/connection configuration cleanly or mutates config('database.connections') at runtime. The former is composable and testable; the latter is fragile and interferes with connection pooling, read replicas, and long-running workers.
• It must be validated against your pinned Laravel and PHP versions. With 33 stars and 0 dependents, the supported-version matrix is unproven, and composer constraints should be read directly before any spike.
• It will conflict with, or require explicit configuration for, anything that assumes a single database: queue workers and Horizon, scheduled commands, Telescope, Pulse, migrations, seeders, and any package running its own migrations.

Technical risk

• License (NOASSERTION) is a gating risk. Until clarified, treat as unusable for commercial or distributed software. This is a legal blocker, not an engineering one, and should be resolved before any code is written.
• Adoption risk is severe. 33 stars, 0 dependents, and a single-vendor organization (World-eSports-LLC) imply a probable bus factor of one and no external validation of the multi-tenancy logic — the exact component where bugs become cross-tenant data exposure.
• Score 0.195 is consistent with an early-stage, unproven package. This is a candidate to evaluate, not a dependency to adopt on faith.
• The mature alternatives (stancl/tenancy, tenancy/tenancy) have orders of magnitude more production exposure. The only reason to prefer this package is a specific capability or fit those do not provide.

Key questions

1. What is the exact license, and is it compatible with our distribution and commercial model?
2. How is the tenant resolved — subdomain, custom domain, session claim, or JWT claim — and what happens on resolution failure?
3. Does the package use Laravel's connection manager or rewrite config at runtime? Does it support read/write splits and connection pooling?
4. How is tenant context propagated to queued jobs, events, listeners, scheduled commands, and notifications? This is the most common source of cross-tenant leakage.
5. What is the migration story — does it fan out migrate across all tenant databases, and is it transactional and resumable?
6. What are the test helpers, and can we assert "no query escapes tenant context" in CI?
7. What is the rollback path if we need to extract the package later?
8. What is the maintainer's support commitment and release cadence?

Integration Approach

Stack fit

• Best fit: a greenfield or actively refactored Laravel application with a clean tenant boundary and a genuine compliance or isolation requirement that justifies N databases.
• Poor fit: applications already on stancl/tenancy (redundant), applications with heavy cross-tenant reporting (DB-per-tenant makes aggregate queries painful), or teams without the operational maturity to run N databases.
• If the tenant boundary is fuzzy or tenants must share data, this is the wrong model regardless of package quality.

Migration path

• Do not adopt directly. Run a time-boxed spike (1–2 weeks) that validates the four highest-risk behaviors: middleware ordering, job/queue context propagation, migration fan-out, and failure handling on unresolvable tenants.
• Wrap the package behind a thin internal abstraction (a TenantContext interface plus a connection resolver) so the vendor can be swapped or forked without touching application code. Given 0 dependents, assume you may become the maintainer.
• Pilot with a single non-critical tenant before broad rollout.

Compatibility

• Pin the Laravel and PHP versions explicitly and verify the package's composer.json constraints.
• Audit every package that runs migrations, schedules tasks, or assumes a single connection. Expect to configure or exclude them.
• Confirm behavior under Octane or any long-running worker — runtime config mutation does not survive or behave consistently across requests in those runtimes.

Sequencing

1. License clarification — hard gate; stop here if unresolved.
2. Architecture spike against a disposable Laravel app with two tenants.
3. Abstraction layer and CI guardrails (cross-tenant leak tests).
4. Pilot tenant in a low-risk module with a documented rollback.
5. Provisioning and migration automation before onboarding tenant #2.
6. Broad rollout gated on operational runbooks being in place.

Operational Impact

Maintenance

• Expect to own a meaningful share of maintenance. With a single-vendor package at this adoption level, plan for the possibility of forking. Budget ongoing effort to track Laravel releases, since a major Laravel upgrade may strand the package.
• The tenancy layer is security-critical infrastructure, not a utility library. Treat it with the review rigor of authentication code.

Support

• Community-only, no SLA, no evident commercial support tier. For a production platform, internal ownership of the code — reading it, understanding it, being able to patch it — should be a precondition, not an aspiration.

Scaling

• DB-per-tenant scales cleanly for isolation but linearly in operational cost: backups, migrations, monitoring, and connection counts all multiply by tenant count. MySQL/Postgres max_connections becomes a hard constraint well before application load does.
• Requires automated tenant provisioning and deprovisioning, per-tenant backup/restore, and a migration orchestrator. This is infrastructure work the package does not do for you.
• Cross-tenant analytics will need a separate reporting path (ETL into a warehouse), which is additional scope.

Failure modes

• Cross-tenant data exposure — wrong or stale tenant resolution, or a query escaping the tenant connection. This is the catastrophic failure and must be defended with CI leak tests and fail-closed behavior.
• Connection exhaustion — N tenants × pool size exceeding database limits under load.
• Migration blast radius — a migration applied to the wrong database, or partially applied across tenants with no resumability.
• Queue/worker context bleed — a job dispatched under tenant A executing under tenant B or the default connection.
• Unauthenticated surface leakage — login, password reset, webhooks, and health checks silently reading/writing the default database.
• Cache and session bleed — if cache/session stores are not partitioned per tenant.

Ramp-up

• The team must internalize middleware ordering, connection lifecycle, and job context propagation. This is nontrivial and should be backed by runbooks and a documented "how tenancy works here" guide.
• Onboarding cost is highest for whoever owns the tenancy layer; plan for a named owner rather than diffuse responsibility.

TPM recommendation: This is a conditional evaluate, not an adopt. The pattern is sound and may be the right architectural choice, but the package itself carries unacceptable unmitigated risk today — unclear license, negligible adoption, single-vendor dependency, and it sits on the most security-sensitive seam in the application. Proceed only if (a) the license is clarified, (b) a spike proves the job/migration/failure-path behavior, and (c) the team accepts ownership of a fork if necessary. Otherwise, evaluate stancl/tenancy first and return to this only if it offers a capability the incumbents lack.