- How do I install phariscope/multitenant in a Laravel app?
- Install the package with Composer and pin the exact pre-1.0 version, such as 0.0.29, rather than a caret constraint. Register the package service provider and tenant-resolution middleware in your Laravel HTTP stack as documented. Publish any configuration, verify tenant-aware database connections, and run a migration spike before using it in production.
- What tenancy models does phariscope/multitenant support?
- The package resolves tenants through domains, subdomains, or custom callbacks. That covers many SaaS and white-label setups, but path-prefix or header-based tenancy should be confirmed before adoption. If your required model is not native, plan a thin adapter layer rather than scattering custom resolution logic through the app.
- Does phariscope/multitenant support database-per-tenant or single-database scoping?
- Its core feature set includes automatic database switching with per-tenant connections, so database-per-tenant is the clearest fit. It also scopes cache and configuration to reduce cross-tenant leakage. If you need single-database row scoping, validate whether Eloquent global scopes cover raw queries, DB::table calls, relationship traversal, and admin paths.
- Which Laravel and PHP versions are supported by phariscope/multitenant?
- The provided package overview does not publish a Laravel or PHP support matrix for version 0.0.29. Check the repository composer.json and README before adoption, then run a compatibility spike on your target Laravel and PHP versions. Pin the exact version and commit the lockfile while the package remains pre-1.0.
- How do I run migrations and Artisan commands for each tenant?
- The package includes Artisan helpers for running migrations and commands per tenant. Use them to iterate tenants and execute migrate, db:seed, or custom commands inside each tenant context. Wrap execution so tenant context is reset even on failure, and test the helpers against your most complex existing migrations.
- How does tenant context propagate to queued jobs and scheduled tasks?
- The overview focuses on per-request tenant resolution and does not document queue or scheduler propagation. Treat tenant context as process-global state: capture the tenant identifier when dispatching, restore it inside the job or scheduled task, and reset it in a finally block. Add integration tests under a real queue worker to prove context does not bleed between jobs.
- Is phariscope/multitenant safe under Laravel Octane, Horizon, or long-running workers?
- Tenant context can bleed in long-running processes if it is not explicitly cleared between requests or jobs. Under Octane, Horizon, or queue workers, set the tenant at the start of each unit of work and reset it in a finally block. Validate this with consecutive-tenant tests running in the same worker process.
- How should I test tenant isolation with phariscope/multitenant?
- Build a tenant-aware test base case and add negative isolation tests, not only happy-path feature tests. Exercise Eloquent relationships, raw queries, DB::table calls, cache reads and writes, and admin routes that may bypass global scopes. Also test that configuration and database connections revert correctly when tenant context changes.
- Is phariscope/multitenant stable enough for production use?
- Version 0.0.29 is pre-1.0, so semver convention means there are no API stability guarantees, and release notes appear sparse. Pin the exact version, commit the lockfile, and wrap the package behind your own tenancy abstraction so it can be replaced. Treat production adoption as a time-boxed spike plus an explicit maintenance-risk decision.
- What are alternatives to phariscope/multitenant for Laravel multi-tenancy?
- Common alternatives include stancl/tenancy and spatie/laravel-multitenancy, each with different tenancy models, features, and maturity levels. Compare them on database-per-tenant versus single-database scoping, queue and cache support, migration tooling, and Laravel version compatibility. Keep your own TenantResolver interface so switching implementations remains practical.