- Is hakam/multi-tenancy-bundle compatible with Laravel?
- No. It is a Symfony bundle built around a Bundle subclass, a DI extension, compiler passes, and Symfony kernel event subscribers, and Laravel has no loading mechanism for those. Adopting it in Laravel would require rewriting the integration layer or porting the internals into service providers and middleware.
- How do I install hakam/multi-tenancy-bundle?
- You install it with Composer into a Symfony 6 or 7 application, register the bundle in the Symfony kernel, and configure tenant resolution and connections. There is no Laravel installation path because Laravel does not load Symfony bundles. In a Laravel app, installing it would only add a dormant dependency.
- Which Laravel versions does this package support?
- None. The package targets Symfony 6 and 7, and its Composer constraints and integration points are Symfony-specific. It does not declare Laravel framework support or provide Laravel service providers, middleware, or facades.
- What is the difference between this bundle and stancl/tenancy or spatie/laravel-multitenancy?
- hakam/multi-tenancy-bundle is a Symfony package, while stancl/tenancy and spatie/laravel-multitenancy are Laravel-native packages that integrate through service providers, middleware, and Artisan commands. The Symfony bundle is useful as a design reference for tenant routing, database switching, and tenant-aware migrations, but it is not a drop-in Laravel alternative.
- Can I use this bundle to build a multi-tenant SaaS on Laravel?
- Not as a runtime dependency. You could study its domain model and reimplement tenant resolution, connection switching, and context isolation with Laravel middleware and service providers. For most teams, evaluating a Laravel-native tenancy package first is the lower-risk path.
- How does tenant resolution work in hakam/multi-tenancy-bundle?
- The package overview says it routes tenants by domain or subdomain and switches databases and configuration per request. That covers common SaaS patterns, but the repository does not clearly document whether resolution is pluggable for custom domains, headers, or token claims. Verify the exact resolution hooks in a spike before designing around them.
- Does it support database-per-tenant, schema-per-tenant, or shared-schema tenancy?
- The published overview emphasizes per-request database and config switching, which points toward database-per-tenant support. It does not clearly document schema-per-tenant or shared-schema-with-tenant-column models, and mixed models are unconfirmed. Treat the exact tenancy model as a key question for the maintainer.
- Is hakam/multi-tenancy-bundle production-ready and actively maintained?
- The risk assessment is cautious: it has about 133 stars and zero dependents, is maintained by a single author without organizational backing, and its last release date needs verification. Multi-tenancy is a security boundary, so an unproven package with no downstream users is high risk for production. Do not adopt it as a dependency without a thorough audit.
- How do tenant-aware migrations work with this bundle?
- The overview states that the bundle supports tenant-aware migrations, which in Symfony would run through the bundle's own commands and tenant connection handling. It does not provide Laravel Artisan commands. In Laravel you would use a Laravel-native tenancy package's migration commands or write custom Artisan commands that iterate tenant connections.
- What should I check before porting this bundle's tenancy model to Laravel?
- Confirm the tenancy model, how tenant resolution is performed, and whether resolution is pluggable. Check how tenant context propagates to queued jobs, scheduled commands, and long-running workers, and whether context is reset between units of work. Also review connection-failure handling, tenant teardown, test suite and CI coverage, static analysis, PHP and Symfony version support, and maintainer commit cadence. Any port becomes your code to own and secure.