- What is sbine/simple-tenancy used for?
- sbine/simple-tenancy is a lightweight Laravel package for shared-database, row-level multi-tenancy. You add a trait to Eloquent models so queries are automatically filtered to the current tenant and new models are created with tenant awareness. It is aimed at apps that need clean tenant isolation without per-tenant databases, not at regulated workloads requiring physical isolation.
- How do I install and configure simple-tenancy in Laravel?
- Install it with Composer and confirm the package constraints against your Laravel and PHP baseline before adopting it. Configuration is mostly application-side: add the trait to tenant-owned models, add tenant_id columns, and wire tenant resolution through middleware or a request-scoped resolver. Read the source and run a short spike because the overview does not document every setup detail.
- Does simple-tenancy support database-per-tenant isolation?
- No. The package targets a single shared database with row-level isolation enforced through Eloquent scopes. It is not a substitute for database-per-tenant, schema-per-tenant, or hard isolation for regulated or enterprise customers. Use it as an application-level enforcement aid, not a complete tenancy platform.
- Which Laravel and PHP versions are supported by simple-tenancy?
- The overview does not list exact Laravel and PHP version constraints, so check the package composer.json and repository before committing. Verify compatibility against your current framework baseline and CI matrix. If the constraints are stale, budget for a wrapper or fork under the MIT license.
- How does simple-tenancy resolve the current tenant?
- The package does not appear to prescribe a full tenant resolver; you are expected to resolve the tenant in your Laravel app, typically from the authenticated user, domain, or middleware. Confirm how the current tenant is stored and propagated by reading the source. Make sure the context is set before queries run and reset between requests and jobs.
- How do I prevent cross-tenant data leakage with simple-tenancy global scopes?
- The trait applies global scopes that automatically filter Eloquent queries to the current tenant, which is the main isolation mechanism. You still need to guard intentional bypasses such as withoutGlobalScopes, raw SQL, admin paths, and code that runs without tenant context. Add negative tests that prove cross-tenant access is denied.
- Does simple-tenancy work with queues, Artisan commands, and Laravel Octane?
- Do not assume queue workers, Artisan commands, events, notifications, or Octane requests inherit tenant context correctly. The evaluation flags long-running workers and console contexts as key risk areas, so set and reset tenant context explicitly at each boundary. Add contract tests that verify context reset between jobs and requests.
- Is simple-tenancy production-ready and actively maintained?
- Treat it as medium-high risk for production until you validate it. Adoption is low, with limited community scrutiny and bus factor, so plan for internal ownership, version pinning, and a possible fork under MIT. Gate production on demonstrated cross-tenant isolation rather than successful installation.
- What are alternatives to simple-tenancy for Laravel multi-tenancy?
- Alternatives include more complete Laravel tenancy packages that support database-per-tenant or schema-per-tenant models, as well as building your own tenant scopes. Choose based on whether you need shared-database row-level isolation or hard physical separation. simple-tenancy fits only the former and is intentionally small.
- How should I test and roll out simple-tenancy safely?
- Start with a non-production proof of concept on one representative module, add tenant_id to tenant-owned tables, backfill a default tenant, and apply the trait model by model. Add middleware for tenant resolution, wrap tenant context boundaries, and keep a feature flag and rollback path. Use contract tests for cross-tenant denial and context reset, then roll out by bounded context with monitoring.