- What is cortex/tenants and how does it implement multi-tenancy in Laravel?
- Cortex Tenants is a frontend layer for the Cortex ecosystem that implements single-database, shared-schema multi-tenancy in Laravel. It provides a polymorphic tenantable relation, a tenant resolver, and global query scopes that filter tenant-owned Eloquent models by tenant_id. It is not a standalone package and presumes the Cortex runtime, including cortex/foundation, cortex/auth, cortex/attributes, and rinvex/laravel-support, is already installed. It fits B2B SaaS applications with many similarly shaped tenants, but it is not a hard compliance or security boundary.
- Does cortex/tenants support Laravel 10, 11, or 12 and PHP 8.2+?
- Unlikely without patching. The repository is archived and the -classic branch is the superseded Cortex line, so its Illuminate/Support and PHP constraints target older Laravel 5.x and 6.x-era versions. To use it on Laravel 10 through 12 you would need to fork it, raise dependency constraints, and align transitive Cortex packages. Treat that as a sourcing and maintenance commitment, not a drop-in install.
- How do I install cortex/tenants with Composer?
- You would normally require it alongside the Cortex suite rather than in isolation, because it depends on cortex/foundation, cortex/auth, cortex/attributes, and rinvex/laravel-support. Because the package is archived, the published constraints may not resolve on a modern Laravel application, so expect to add a VCS or path repository pointing at your fork instead. Validate the full dependency tree with composer why-not before committing to the integration.
- Is cortex/tenants safe for production multi-tenant SaaS applications?
- It is reasonable when tenancy is a convenience boundary and tenants are small, similarly shaped, and not separated by regulation. It is a poor fit when tenancy is a security or compliance boundary, such as health, financial, or EU data-residency workloads, because there is no physical isolation. A single missed scope becomes a cross-tenant data exposure, and the archived repository means there is no upstream fix if a bypass is discovered.
- Why are my Eloquent queries returning other tenants' data with Cortex Tenants?
- Global scopes only apply to Eloquent query builders they are attached to. Raw DB:: queries, withoutGlobalScope calls, reporting joins, package internals with their own builders, and any model missing the tenant scope will return unscoped rows. Polymorphic tenant resolution adds another failure point, because if the tenant cannot be resolved you may get an exception or an unscoped result depending on configuration. Audit every query path and test explicitly for leaks.
- Do queued jobs and Artisan commands respect tenant scoping in cortex/tenants?
- Not automatically. Jobs, listeners, scheduled tasks, and console commands often run without an active tenant context, so global scopes resolve to nothing or to the wrong tenant. You need queue middleware or job payloads that re-establish the tenant before any tenant-owned model is queried, and explicit context setup in commands and schedulers. Treat these paths as high risk and cover them in tests.
- What database indexes and storage conventions do I need for single-database multi-tenancy?
- Use tenant_id as the leading column of every composite index on tenant-owned tables, because global scopes add a tenant_id predicate to nearly every query. Also namespace cache keys and file storage paths by tenant, such as tenant:{id}:users, since Redis and the filesystem are shared in a single-database setup. Neither is handled automatically by the package; both are application-level disciplines you must enforce consistently.
- How do I test that tenant isolation is working in cortex/tenants?
- Test at the boundaries, not just the happy path. Write feature tests that authenticate as tenant A and assert that records belonging to tenant B are never returned, then add tests for raw DB queries, withoutGlobalScope calls, queued jobs, console commands, and reporting joins. Seed at least two tenants in every relevant factory so accidental unscoped results fail loudly.
- Can I share reference data like countries or currencies across tenants with cortex/tenants?
- Yes, and that is the strongest fit for this model. The same-database design lets you keep centrally shared reference tables unscoped while tenant-owned tables carry tenant_id and the global scope. You decide which models are tenantable and which stay global, so plan catalogues, currencies, and country lists can remain shared. Document that boundary explicitly so global models are intentional rather than accidental.
- What are the alternatives to cortex/tenants, and is it maintained?
- The repository is archived, has very few stars and no dependents, so it is not actively maintained and should not be chosen for new work without a fork plan. Alternatives for Laravel multi-tenancy include stancl/tenancy and spatie/laravel-multitenancy, which support single-database or multi-database models and are actively maintained. If you need a hard tenant boundary, evaluate database-per-tenant or schema-per-tenant approaches rather than shared-schema scoping.