Weave Code
Multi Tenancy Bundle Laravel Package
swp/multi-tenancy-bundle
SWP MultiTenancyBundle provides flexible multi-tenant support for PHP applications, with tenant-aware services, configuration, and integration helpers for isolating data and switching tenants. Ideal for SaaS projects needing clean tenant separation.
This bundle provides tools to build multi-tenant architecture for PHP applications.
Frequently asked questions about Multi Tenancy Bundle
- Can I use swp/multi-tenancy-bundle in a Laravel application?
- No, swp/multi-tenancy-bundle is a Symfony bundle, not a Laravel package. It depends on Symfony's DI container, bundle extension conventions, event dispatchers, and Doctrine ORM, so direct adoption in an Eloquent-first Laravel app is not practical. For Laravel, use a Laravel-native tenancy package such as stancl/tenancy or tenancy/tenancy instead. Treat this bundle as a design reference only if you are evaluating tenancy patterns.
- How do I install swp/multi-tenancy-bundle?
- Install it with Composer using composer require swp/multi-tenancy-bundle, then register the bundle in a Symfony application's kernel and configure tenant resolution and Doctrine integration. It is intended for Symfony projects, typically within the Superdesk Web Publisher component family. The repository is a read-only subtree split, so you cannot open pull requests against it. Expect PHP and Symfony version constraints from the 2018 release line.
- Does swp/multi-tenancy-bundle support Laravel 10 or Laravel 11?
- No. The bundle targets Symfony and Doctrine, and its 2018 release line predates PHP 8, while Laravel 10 and 11 require PHP 8.1+ and Symfony 6/7 components. Composer resolution in a modern Laravel app would likely conflict on symfony/*, doctrine/orm, and PHP platform requirements. Supporting Laravel would require a fork and platform-requirement overrides, which is a large architectural tax for a narrow capability.
- How does tenant resolution work in swp/multi-tenancy-bundle?
- The bundle resolves tenants through strategies tied to SWP domain concepts such as domains, requests, tenants, themes, publications, and routing. It provides a shared tenant context and tenant-aware services, but it does not expose a generic resolve-tenant-from-host, subdomain, or header contract. The mechanism is framework-native Symfony integration rather than a portable tenancy abstraction. Custom resolution strategies are possible through the bundle's extensible interfaces.
- Does swp/multi-tenancy-bundle support database-per-tenant isolation?
- No, the bundle assumes a shared database and shared schema with a tenant_id discriminator, backed by tenant-aware entities and a Doctrine query filter. Schema-per-tenant and database-per-tenant provisioning live elsewhere in the Superdesk Web Publisher stack. If your customers or regulators require database-per-tenant backup, restore, or residency, this bundle alone does not provide that isolation model. You would need additional provisioning and switching infrastructure.
- Is swp/multi-tenancy-bundle maintained and production-ready?
- It is effectively abandoned: the last release was 2018-06-11, it has around 30 stars and zero dependents, and there is no CVE triage, PHP 8 compatibility work, or security response path. The repository is a read-only split of the Superdesk Web Publisher monorepo, which is itself dormant, so fixes become permanent local forks. The composite score reflects topical relevance, not health. For a new production system, that risk profile is usually disqualifying.
- What license does swp/multi-tenancy-bundle use, and is AGPL-3.0 safe for SaaS?
- The dominant licensing risk is AGPL-3.0, which carries network copyleft obligations for software offered as a service. For a commercial SaaS, legal review is required before vendoring or deploying the code. It is not a footnote you can defer until after integration. If AGPL is incompatible with your business model, do not adopt this bundle.
- Can I customize tenant storage and tenant switching in swp/multi-tenancy-bundle?
- Yes, the bundle exposes extensible interfaces for custom tenant storage and switching, and it integrates with Symfony's DI container and event dispatcher. However, customization is constrained by SWP domain assumptions around tenants, themes, publications, and routing. You are extending a Symfony bundle in the Superdesk ecosystem, not plugging into a generic tenancy contract. Any significant change should be planned as a maintained local fork.
- Does swp/multi-tenancy-bundle handle tenant context in CLI commands, queues, and long-running workers?
- The available context does not establish that it covers CLI, queue workers, or long-running processes; tenant resolution is described around domains, requests, and Symfony request handling. That matters because tenancy packages must propagate tenant context beyond HTTP, especially for queued jobs and workers. If you need cache, queue, filesystem, Redis, and Octane-safe namespacing, this bundle is not a complete solution. Verify any non-HTTP behavior in a fork before relying on it.
- What are the best alternatives to swp/multi-tenancy-bundle for Laravel and Symfony?
- For Laravel, stancl/tenancy and tenancy/tenancy are the usual choices because they own tenant identification, database switching, cache, queue, filesystem and Redis namespacing, and Octane safety. For Symfony, evaluate maintained Symfony-native tenancy bundles or build on Doctrine filters with explicit tenant context propagation, and consider the SWP component family only if you are already running Superdesk Web Publisher. The capability gap matters: identification, data isolation, storage namespacing, and per-tenant migrations each point to different solutions. Avoid pulling Doctrine into an Eloquent-first app just to reuse one bundle.
Weaver
How can I help you explore Laravel packages today?