What this prompt does
This prompt implements multi-tenancy in a Laravel application, choosing between a database-per-tenant model and a shared database with scoping. It produces tenant resolution, automatic query scoping for tenant models, tenant-aware middleware and routing, a migration strategy, a provisioning Artisan command, shared-versus-tenant data separation, cache isolation, queue tenant-context preservation, and Filament tenant switching — with isolation tests to prove data doesn't leak.
The variables decide the architecture and its blast radius. [tenancy_type] picks the model (shared database with column scoping versus database-per-tenant), [app_type] frames the application, and [resolution_method] sets how a tenant is identified — typically a subdomain. [migration_approach] controls how schema changes apply across tenants, and [user_count] signals the scale you must support, which influences whether shared scoping or isolated databases is sensible. The prompt deliberately calls out cache and queue tenant context, because those are exactly where naive setups leak one tenant's data into another. Writing isolation tests first turns "it probably works" into something verifiable.
When to use it
- Building a SaaS where each customer's data must stay strictly isolated
- Choosing between shared-database scoping and database-per-tenant for a new product
- Adding subdomain-based tenant resolution to an existing Laravel app
- Ensuring cache keys and queued jobs carry the correct tenant context
- Provisioning new tenants reproducibly via an Artisan command
- Giving admins a Filament panel that can switch between tenants safely
Example output
You get tenant-resolution logic tied to your [resolution_method], a global scope (or trait) applied to tenant models, middleware that establishes tenant context per request, a migration strategy matching [migration_approach], a provisioning command, cache-key namespacing per tenant, queue middleware that restores tenant context inside jobs, and Filament tenant switching. Crucially, you also get tests that create two tenants and assert one cannot read the other's records. The shape reflects your chosen [tenancy_type].
Pro tips
- Choose
[tenancy_type]by isolation needs and scale: column scoping is simpler but leakier; database-per-tenant isolates hard but costs more to operate - Make
[resolution_method]concrete (subdomain tenant.app.com) so middleware and routing are generated against a real strategy - Pay special attention to the cache and queue sections — these are where the prompt earns its keep, since most leaks happen there
- Write the isolation tests first and keep them in CI; they're the only thing that proves scoping actually holds as the app changes
- Let
[user_count]honestly reflect scale — 500+ tenants on column scoping needs careful indexing the prompt won't fully solve - Verify queued jobs re-establish tenant context; a job that runs without it can silently write to the wrong tenant
