Technical Evaluation

Architecture fit

stancl/tenancy is opinionated about lifecycle, not business logic: it hooks Laravel's bootstrapping to resolve a tenant (domain/hostname, with second-level domain support) and to re-point database, cache, filesystem, session, and queue contexts per request.
Default v3 model is database-per-tenant: a central DB holds tenants and domains, each tenant gets its own schema/connection. This is the strongest isolation story and the cheapest to retrofit if the app already respects Eloquent connections.
The README's "you won't have to change a thing" claim holds for a clean, connection-agnostic Laravel app. It does not hold for apps with raw SQL joins, cross-tenant admin reports, global caches, hardcoded storage paths, or job payloads carrying model instances (the latter only became safe in v3.5's queue tenancy rework).

Integration feasibility

Install is a standard Composer + config-publish + two central migrations + tenant model + middleware path. A spike is days, not weeks.
Retrofitting a mature SaaS is a multi-sprint effort dominated by audit work: query inventory, cache key audit, storage path audit, queue payload audit, and per-tenant migration authoring.
Greenfield is straightforward; brownfield with existing customer data is where the schedule risk lives.

Technical risk

Cross-tenant leakage is the existential risk. Every historical bug class in the changelog is this shape: resolver cache not invalidated on delete (3.9.1), queue worker not reverted to central context (3.5.x, 3.8.5), cache tag argument handling (3.8.5), asset path validation hardening (3.7.1). Long-running processes (Octane, Horizon, queue workers) are the highest-risk surfaces.
Schema drift across N databases is a second-order risk: tenant migrations are your app's migrations multiplied by tenant count, with no built-in drift detection.
Provisioning latency: tenant creation is synchronous DB creation + migration run; signup UX degrades as migration count grows unless you move it to a job.
Doc/version divergence: README badges say Laravel 10.x/11.x while v3.10.x supports Laravel 13; the documentation site is v4-centric while the released code is 3.x. A team can burn a sprint following the wrong docs.

Key questions

Database-per-tenant, or single-DB with a tenant column? The package's strongest value is the former; if you need the latter, validate against v4 docs, not the shipped 3.x behavior.
How many tenants in 12/24 months, and what is the per-tenant data size? Connection ceilings and backup fan-out are the constraints.
Do any customers require physical isolation, data residency, or per-tenant restore? If yes, DB-per-tenant is close to mandatory and this package is a good fit.
Which Laravel version and do you run Octane/Horizon? Both change the risk profile materially.
Who owns tenant migrations — app team or platform? Ambiguity here is the most common source of drift.
Is committed 3.x or pre-release 4.x the target? Do not straddle.

Integration Approach

Stack fit

Laravel 10–13 on PHP 8+, MySQL/MariaDB/Postgres (SQLite for tests). Cache, filesystem, Redis, session, and queue bootstrappers are included; Horizon/queue tenancy is supported since 3.5.
MIT license removes procurement friction. There is no commercial SLA — support is community GitHub issues plus the paid documentation site, so plan an internal owner.

Migration path

Phase 0 (1 sprint): branch spike — two tenants, one domain each, verify isolation across HTTP, queue, cache, storage, and console.
Phase 1: introduce the central DB (tenants, domains) and the tenant model; leave customer data untouched.
Phase 2: author tenant-scoped migrations and a provisioning job; run against synthetic tenants.
Phase 3: data migration per existing customer, one at a time, with a per-tenant verification script.
Phase 4: cutover via subdomain/DNS, with the old path kept read-only for a defined window.

Compatibility

Trust Composer constraints and CI, not the README badge. Pin the package minor and upgrade on Laravel minor releases — 3.10.1 was a Laravel 13.24 compatibility backport, which tells you Laravel minors occasionally break this package.
Never mix v3 and v4 documentation in the same design doc.

Sequencing

Build the isolation test harness first (assert no tenant can read another's rows, cache keys, files, or queued jobs) and make it a required CI gate before any feature work lands.
Provisioning job and tenant deletion/export tooling come next — they are operational prerequisites, not nice-to-haves.
Only then migrate the first real customer.

Maintenance

Release cadence is active and patch-oriented, but maintainer concentration is high (effectively a single primary author). Treat this as a bus-factor risk requiring an internal engineer who can read the package source, not just its docs.
Budget roughly a day per Laravel minor upgrade for package compatibility validation. Pin versions; upgrade quarterly rather than continuously.

Support

No vendor SLA. Escalation path is GitHub issues plus the documentation site. Define an internal on-call owner for tenancy-related incidents before launch; "the package handles it" is not an incident response.

Scaling

Connection count becomes a first-class capacity metric: N tenants × pool size against database max_connections. Model this before tenant 50, not after.
Migration fan-out and per-tenant backup/restore are linear in tenant count and must be job-queued and observable. Per-tenant monitoring (not just aggregate APM) is required to catch single-tenant degradation.
Cache and storage namespacing must be verified under load, not just in tests — prefix collisions surface as intermittent, hard-to-attribute bugs.

Failure modes to instrument

Stale domain resolver cache after domain changes (historically a real bug — add a post-change smoke test).
Queue worker retaining tenant context between jobs; assert central-context revert in your own test suite rather than trusting the package.
Provisioning partially completing (DB created, migrations failed) — needs idempotent retry and a quarantine state.
Filesystem/Vite asset path regressions (three of the sampled releases are exactly this).
Security-relevant path handling in tenant asset serving — maintain strict patch discipline; do not pin to an old minor for convenience.

Ramp-up

One to two sprints for a mid-level Laravel engineer to be productive; the conceptual load is Laravel bootstrapping internals, not the package API.
Required runbooks before GA: provision tenant, upgrade tenant schema, export tenant data, delete tenant, recover tenant from backup, rotate a tenant domain.
Note the low ecosystem signal (0 declared dependents, opportunity score 40.89) — it does not mean "don't use," but it does mean your evidence must come from the spike and the isolation harness, not from downstream adoption.