Download the PHP package ubayedtanvir/laravel-tenancy without Composer

Single-database multi-tenancy for Laravel that fails closed.

[](https://packagist.org/packages/ubayedtanvir/laravel-tenancy) [](https://github.com/ubayedtanvir/laravel-tenancy/actions?query=workflow%3Atests+branch%3Amain) [](https://phpstan.org/) [](https://packagist.org/packages/ubayedtanvir/laravel-tenancy) [](LICENSE)

--- Laravel Tenancy adds single-database multi-tenancy to Laravel the way you'd expect a first-party feature to work — implement a marker interface on your tenant model, add a trait to scoped models, and the package handles query filtering, write stamping, foreign keys, and middleware. It follows Laravel conventions so there's almost nothing to configure if your app already follows them. Where it differs from existing packages: this one is built specifically for shared-schema tenancy, and it **fails closed**. A query without a tenant context throws an exception, a write to the wrong tenant is rejected, and the tenant column is immutable after creation. You catch the bug in your test suite, not in a customer's data. > [spatie/laravel-multitenancy](https://github.com/spatie/laravel-multitenancy) and [stancl/tenancy](https://github.com/archtechx/tenancy) are great if you need a database per tenant. This package does shared-schema only — one database, row-level isolation. --- ## Requirements - PHP 8.4+ - Laravel 13 --- ## Installation The install command figures out your tenant model, foreign key, and column type, then tells you what it picked. --- ## Quick Start ### 1. Mark your tenant model `IsTenant` is a marker interface. No methods to implement. Any model works — Team, User, Store, whatever your app calls a tenant. Foreign keys follow Laravel's `getForeignKey()` convention. If you follow the convention, there's nothing to configure. ### 2. Scope your models This adds a global scope, auto-stamps the tenant on create, guards the column against mass assignment, throws on cross-tenant writes, and makes the tenant column immutable. It also gives you `withoutTenancy()`, `acrossTenants()`, and `forTenant($tenant)` scopes. ### 3. Migration `$table->tenant()` looks at your tenant model and picks the right column type. ### 4. Middleware Or with the aliases the package registers: `['tenant', 'tenant.required', 'tenant.member']`. ### 5. Routes Now `/acme/invoices` queries acme's data and `/globex/invoices` queries globex's. No tenant context = exception. ## Tenant Resolution Three resolvers ship out of the box: For anything custom: --- ## Cross-Tenant Queries When you need to reach across tenants, you can — but it's always explicit: Every cross-tenant call dispatches a `CrossTenantAccessGranted` event, so you can log or audit it. And `grep -rn 'crossTenant\|acrossTenants\|withoutTenancy' app/` gives you a full list of every place isolation is relaxed. --- ## Queues Jobs dispatched inside a tenant context run in that same context when the worker picks them up. This works for jobs, mailables, notifications, listeners, closures, chains, and batches — the tenant id goes into the queue payload via `Queue::createPayloadUsing`. If a job shouldn't be tenant-aware, mark it: --- ## Console Commands Run any artisan command inside a tenant context: For your own commands, there's a trait: The trait adds `--tenant`, `--all`, and `--continue-on-error` options automatically. --- ## Tenant-Scoped Cache `Cache::tenant()` returns a decorator that prefixes keys with the current tenant. The global cache stays untouched: --- ## Schema Auditor Checks for missing traits, non-composite unique indexes, column type mismatches, missing foreign keys, and strict mode. You can run it in CI: --- ## Testing The package ships a `InteractsWithTenancy` trait with an `assertTenantIsolated` helper that checks read isolation, write rejection, ownership immutability, and the missing-context exception: There's also `actingAsTenant($tenant)` for when you need to set up the context manually in your tests. --- ## Current Tenant Tracking For team switchers and "redirect to last visited tenant" flows: Add `RecordsCurrentTenant` to your middleware stack to keep the preference up to date on each GET request. Use the `tenant.landing` middleware on your landing route to redirect users to their last tenant (self-heals if that tenant was deleted or the user lost access). When a tenant is deleted, switch affected users to their next available tenant: This preference is only used for landing — never for scoping or authorization. The URL is always authoritative. --- ## Custom Foreign Key If a table uses a non-standard column name: --- ## API Reference ## Middleware Aliases | Alias | Class | Purpose | |---|---|---| | `tenant` | `IdentifyTenant` | Resolves and binds the tenant from the request | | `tenant.required` | `RequireTenant` | Returns 404 when no tenant is bound | | `tenant.member` | `EnsureTenantMember` | Returns 404 if the user isn't a member | | `tenant.record` | `RecordsCurrentTenant` | Saves the tenant as the user's landing preference | | `tenant.landing` | `RedirectToCurrentTenant` | Redirects to the user's last-visited tenant | | `tenant.strict-switch` | `RequireExplicitSwitch` | Requires explicit confirmation to switch tenants | --- ## Changelog Please see [CHANGELOG](CHANGELOG.md) for recent changes. ## Contributing Please see [CONTRIBUTING](CONTRIBUTING.md) for details. ## Security Vulnerabilities If you discover a security vulnerability, please email **[email protected]** instead of using the issue tracker. Please see [SECURITY](SECURITY.md) for our full security policy. ## Credits - [Ubayed Tanvir](https://github.com/ubayedtanvir) - [All Contributors](../../contributors) ## License The MIT License (MIT). Please see [License File](LICENSE) for more information.