- How does stancl/tenancy handle tenant identification without manual code changes?
- The package automatically resolves tenants via middleware using hostname (e.g., tenant1.example.com), subdomains, or path prefixes (e.g., /tenant1/). No model traits or custom code are required—just configure resolvers in the Tenant model, and Laravel’s middleware pipeline handles the rest.
- Can I use stancl/tenancy with Laravel 11 or 12? What about PHP 8.0?
- The package officially supports Laravel 10–13 and requires PHP 8.1+. Laravel 11/12 are fully compatible, but PHP 8.0 is *not* supported. Always check the [latest version on Packagist](https://packagist.org/packages/stancl/tenancy) for minor version updates.
- Does stancl/tenancy work with shared database schemas instead of separate databases per tenant?
- No, this package enforces **database-per-tenant** isolation. For schema-per-tenant (shared DB), you’d need a custom solution like Laravel’s built-in `connection()` method or packages like `spatie/laravel-multi-tenant`. Tenancy’s design prioritizes strict isolation.
- How do I handle tenant-specific assets (CSS/JS) with Vite or Laravel Mix?
- Use the `TenantAssetsController` to serve tenant-scoped assets. Configure Vite/Laravel Mix with dynamic public paths (e.g., `/tenant1/assets/`) and let the middleware route requests automatically. The package includes built-in support for this workflow.
- Will stancl/tenancy slow down my application? What’s the performance impact?
- The middleware adds ~1–5ms per request for tenant resolution, which is negligible for most SaaS apps. Optimize by caching resolver results (e.g., `Cache::remember`) or using lightweight resolvers like `HeaderTenantResolver` for APIs.
- How do I back up tenant databases if each has its own schema?
- Use automated scripts (e.g., `pg_dump` for PostgreSQL or `mysqldump` for MySQL) targeting each tenant’s database. The package doesn’t include backup tools, but you can integrate with Laravel’s scheduler to run nightly backups via `Artisan::call()`.
- Can I use stancl/tenancy with Redis or Memcached for caching?
- Yes, the package automatically scopes cache operations using tags (e.g., `Cache::tags(['tenant:1'])`). This ensures tenant data isolation in Redis/Memcached without manual prefixing. Works seamlessly with Laravel’s cache drivers.
- What happens if two tenants try to access the same route (e.g., /dashboard) but use different paths (e.g., /tenant1/dashboard vs. /tenant2/dashboard)?
- The package routes tenants via path prefixes (e.g., `/tenant1/*`) or subdomains, so conflicts are avoided by design. Ensure your routes use `Route::prefix('tenant1')` or similar, and test with the `PathTenantResolver` for path-based setups.
- How do I test tenant isolation in my Laravel app?
- Use Laravel’s `actingAs()` with the `Tenant` model to simulate tenant contexts in tests. For database tests, leverage `DatabaseMigrations` with `Tenancy::initialize()` to switch tenants. The package includes test helpers in its docs for common scenarios.
- Are there alternatives to stancl/tenancy for Laravel multi-tenancy?
- Yes. For **database-per-tenant**, consider `spatie/laravel-multi-tenant` (more flexible but requires traits). For **schema-per-tenant**, use Laravel’s native `connection()` or `spatie/laravel-multi-tenant-schema`. Tenancy stands out for its zero-code approach and hostname/subdomain support.