laravel-multi-tenancy
Laravel Multi-Tenancy
In a multi-tenant app every line of code runs in one of two contexts: central (the app itself: tenants, plans, sign-up) or one tenant's. stancl/tenancy switches between them. Identification middleware finds the tenant on each request and initialises tenancy; bootstrappers then point the database, cache, filesystem and queue at that tenant, and revert them when tenancy ends. Tenant code is then ordinary Laravel code that never mentions the tenant. Central code is the marked exception, and the only code that moves between contexts.
This skill targets stancl/tenancy v4 (PHP 8.4, Laravel 12). v3 differs in namespaces and in how identification is configured; when composer.lock shows v3, check each API against its vendor source.
Choices the project makes once
| Choice | Options | Consequence |
|---|---|---|
| Where tenant data lives | A database per tenant, or one shared database | Decides how tenant models look (Rules, one shared database) |
| How a request names its tenant | Domain or subdomain, a path segment, or a header | Decides the middleware and what the tenant model needs (Identification) |
Follow the choice the project has made. Don't mix modes or identification methods without a reason the project states.