Product Decisions This Supports
- Build vs. buy for tenant isolation. This package is best treated as a design reference, not a purchase. It answers "what does the shape of a multi-tenancy layer look like?" — tenant resolution from domain/subdomain, tenant context propagation, per-tenant configuration — which accelerates the build-vs-buy conversation before you commit engineering weeks to it.
- Tenant data-isolation model. The single most expensive and irreversible decision in a B2B SaaS roadmap is shared-database vs. schema-per-tenant vs. database-per-tenant. Reading this bundle's abstractions gives the team concrete vocabulary (tenant resolver, tenant-aware connection/entity manager) to make that call with the migration story in view.
- Enterprise / white-label tier readiness. If the roadmap has a "sell to multiple customers with separate branding, data, and admin" milestone, this is scoping input for that milestone — what the platform layer must own vs. what the application layer must own.
- Legacy modernization triage. For an acquired or inherited Symfony 2 PHP application, this is a fast read on whether the existing tenancy is a pattern worth preserving during a rewrite or a liability to discard.
- Not a dependency decision. With 0 dependents and 25 stars against a framework line (Symfony 2) that has been end-of-life since 2019, this should not appear on a procurement, security-review, or vendor-risk agenda at all.
When to Consider This Package
Consider it when all of the following hold:
- You are on, or inheriting, Symfony 2 / early Symfony 3 with PHP 5.x–7.x and cannot move off it in the current planning horizon.
- You need one tenant per domain/subdomain resolution and a shared tenancy context — the generic 80% case, not something exotic (per-tenant sharded databases, row-level security, tenant-scoped queues).
- You want a reference implementation to read in an afternoon — a spike, a pattern source for a design doc — rather than a library to
composer require and support.
- Your team is small and the cost of writing the tenancy layer from scratch is measured in weeks, not days.
Look elsewhere — decisively — when any of these are true:
- You are on Laravel. This is a Symfony bundle; there is no port path. Use
stancl/tenancy or tenancy/tenancy and stop reading.
- You are on Symfony 5/6/7 or PHP 8. Framework and language both moved on; the bundle will not install cleanly and will not be maintained.
- You need per-tenant migrations, queue/worker isolation, tenant-aware caching, or per-tenant backups. These are the hard parts of multi-tenancy, and a 25-star Symfony 2 bundle will not carry them.
- Anything security- or compliance-sensitive. Data isolation bugs are breach-class incidents. Zero dependents and no maintenance signal means no one is finding those bugs for you.
- You need a support contract or CVE response. Neither exists here.
How to Pitch It (Stakeholders)
To executives (one paragraph): We evaluated a small open-source component for multi-tenant support and are not recommending adoption. It is a 25-star Symfony 2 bundle with no downstream users, built for a framework line that has been unsupported since 2019 — the vendor-risk and maintenance-risk are both disqualifying. Its real value is as a free reference design: a few hours of engineering reading it sharpens our thinking on tenant data isolation, which is one of the more expensive and hard-to-reverse architecture bets in our B2B roadmap. Net cost is near zero; net benefit is a faster, better-informed architecture decision. No budget, no dependency, no procurement.
To engineering: This is a read-only artifact. Pull the tenant-resolution and tenant-context abstractions as input to our own design doc; do not vendor, fork, or composer require it. If we are on Laravel, the equivalent conversation is stancl/tenancy; if we are on modern Symfony, it is a hand-rolled tenant resolver plus Doctrine filters. Timebox the review to half a day and come back with a one-page recommendation on isolation model — shared DB with tenant scoping, schema-per-tenant, or DB-per-tenant — with the migration cost of each. That recommendation, not the package, is the deliverable.
To the product team: Nothing here changes the roadmap directly. It de-risks the enterprise/white-label milestone by making the isolation-model decision explicit and early, instead of discovering it mid-build. Flag it if that milestone is within the next two quarters.