Weave Code
Laravel Tenantable Laravel Package
binarcode/laravel-tenantable
A Laravel package for adding multi-tenancy to Eloquent models. Apply the Tenantable trait to scope queries and relationships to the current tenant, with support for tenant resolution and data isolation. Keeps tenant-aware model code simple while helping prevent cross-tenant access.
Just another multi tenant support package for Laravel.
Frequently asked questions about Laravel Tenantable
- How do I install binarcode/laravel-tenantable in a Laravel app?
- Install it with Composer using composer require binarcode/laravel-tenantable. Like most Laravel packages it registers through package discovery, so no manual service provider entry is normally needed. Check the repository README for any publishable config or migration steps before wiring it into existing models. Pin an explicit version constraint rather than a floating one so tenant scoping behaviour cannot change silently underneath you.
- Which Laravel versions does binarcode/laravel-tenantable support?
- Release 2.7.0 added Laravel 13 support, and earlier 2.x releases track the framework's annual major cadence. Because framework support was shipped as a minor bump rather than a major, the package treats it as non-breaking. Always confirm the actual constraint range in the package's composer.json rather than trusting the changelog line alone. If you are on an older major, verify that 2.7.0 still declares support for your version instead of superseding it.
- How does the Tenantable trait scope Eloquent queries to the current tenant?
- You add the Tenantable trait to any Eloquent model that should be tenant-aware. The trait applies a global scope so queries on that model are automatically filtered to the current tenant, and relationships defined on the model inherit the same restriction. This keeps tenant-aware model code close to ordinary Eloquent code instead of wrapping every query by hand. Review the trait source to confirm exactly which columns and relations it touches in your schema.
- How is the current tenant resolved at runtime?
- The package supports tenant resolution so a request, job, or console command can establish which tenant is active before models are queried. The resolution mechanism is configured on your side, typically driven by the authenticated user, a subdomain, or an explicitly set context. Because resolution is a request-level concern, make sure queue workers and scheduled commands set the tenant explicitly, otherwise scoped queries may run against the wrong or a null tenant.
- Does this package prevent cross-tenant data access?
- It scopes queries and relationships to the current tenant, which removes the most common accidental leak path in application code. It is not a database-level isolation guarantee, so raw queries, DB facade calls, and explicit scope removals can still bypass it. Treat it as defence in depth alongside authorisation policies and, where required, per-tenant database separation. Audit any place your code calls withoutGlobalScopes or builds hand-written SQL.
- Will the Tenantable trait break eager loading and relationships?
- Relationships are intended to be scoped to the current tenant as well, so eager loading with with() should stay consistent with the parent model's scope. The risk area is cross-tenant relations, such as a shared lookup table or an admin view that legitimately needs data from several tenants. Test those cases explicitly, since a global scope that is correct for end users can be wrong for reporting and back-office screens. Use explicit scope removal only where it is deliberate and reviewed.
- How do I write tests for models using the Tenantable trait?
- Set an explicit tenant context in each test before hitting the model, then assert that records belonging to another tenant are excluded. Use Laravel's RefreshDatabase trait so tenant-scoped fixtures are rebuilt between tests and leaks cannot hide behind leftover rows. Add negative tests that confirm a query returns nothing rather than another tenant's records. Also cover queue jobs and console commands, since those paths do not have a request to derive the tenant from.
- How do I upgrade from 2.6.x to 2.7.0 safely?
- Diff the composer.json constraints between 2.6.x and 2.7.0 to see whether Laravel 13 was added alongside your current major or replaced it. Bump the package on your existing framework version first, run the suite, and only then attempt the Laravel 13 upgrade as a separate change. Keeping the two steps apart means a failure tells you which upgrade caused it. Keep the previous tag pinned so reverting is a one-line change.
- Is the Laravel 13 support in 2.7.0 actually tested?
- A widened Composer constraint is not proof of tested support, and the most common failure pattern is adding a framework version to composer.json without adding it to the CI matrix. Check the repository's workflow files to confirm Laravel 13 jobs exist and pass. Also confirm whether Laravel 13 was GA, RC, or unreleased when 2.7.0 was tagged, since dev-stability constraints can destabilise lockfile resolution. Until that is verified, treat the release as a promising signal rather than a guarantee.
- What alternatives to binarcode/laravel-tenantable should I consider?
- Wider-adopted options include stancl/tenancy and spatie/laravel-multitenancy, which cover tenant resolution, database switching, and lifecycle events out of the box. This package is narrower: it focuses on scoping Eloquent models to a tenant rather than managing tenant provisioning or per-tenant databases. Choose it when you want lightweight row-level scoping inside a single database, and choose a heavier package when you need full tenant isolation, domain routing, or automated tenant migrations. Evaluate maintainer activity and security disclosure policy before promoting any of them to a production-critical dependency.
Weaver
How can I help you explore Laravel packages today?