Product Decisions This Supports
- The tenancy architecture decision (shared schema vs. schema-per-tenant vs. database-per-tenant). The irreversible decision here is which isolation model we commit to, not which package we install. Reading this bundle's source — even briefly — is a cheap way to pressure-test whether our compliance, noisy-neighbor, and per-tenant migration requirements actually fit a shared-code model before we lock it in. Retrofitting tenant scoping after data accumulates is a migration project, not a sprint.
- Build vs. buy for the tenancy layer. This repo moves the "buy" column in the wrong direction: 11 stars, 0 dependents, and an explicit "not maintained anymore" notice from the maintainer. The realistic shortlist is a maintained package (
stancl/tenancy or spatie/laravel-multitenancy for Laravel) or a thin in-house layer we own — not this repo.
- Framework-fit reality check. Despite the "Laravel/PHP" framing, this is a Symfony bundle, not a Laravel package: no service provider, no facade, no package auto-discovery. For a Laravel product its leverage is pattern-level only — how tenant resolution, request-lifecycle context, and data scoping are structured — never
composer require.
- Roadmap sequencing for multi-tenant readiness. If tenancy is on the roadmap, the decision this forces now is when to lock the isolation model, because it constrains data model, auth, queue design, and per-tenant migrations downstream.
- Prior-art input to a technical spike, not a dependency decision. Useful reading for how someone else wired tenant resolution, context propagation, and connection/schema switching — not a candidate for production.
- Risk-register anchor for "unmaintained OSS on the customer-data boundary." A concrete example to justify a policy on acceptable maintenance status for third-party code that sits on the isolation seam.
When to Consider This Package
- Only as reference material. Read the source during a tenancy design spike to borrow the resolver → listener → context → scoped-access pattern. Do not add it to a Laravel (or modern Symfony) project. The maintainer's "not maintained anymore" banner and zero dependents mean there is no ecosystem to inherit fixes from.
- Do not adopt if you need a supported Laravel/Symfony version matrix, security patching, or an upgrade path — none of which an unmaintained package can offer, regardless of the MIT license. Expect hard blocks: era-specific syntax and framework contracts that will not satisfy current type requirements, plus Composer pins that fence you out of security updates elsewhere.
- Look elsewhere — essentially always for the real dependency. Screen maintained alternatives on: release cadence in the last 12 months, declared support for your Laravel/PHP versions, test coverage on tenant-isolation paths, dependent count as real-world-hardening proxy, and a documented security-reporting channel. If nothing clears that bar, budget a small in-house scoping layer (resolver middleware, connection manager,
BelongsToTenant global scope) and own it deliberately.
- Reconsider a fork only if you have a named internal owner, a written maintenance commitment, and a reason the maintained options genuinely don't fit — and treat that as a 3–6 week build decision with ongoing cost, not a free dependency.
- Skip entirely if your "multi-tenancy" need is just row-level filtering on a handful of tables; application-level scoping plus isolation tests may be cheaper to own than any package.
How to Pitch It (Stakeholders)
To executives: This is free and MIT-licensed, but its total cost of ownership is not free — the maintainer has publicly stopped maintaining it, almost no one uses it, and it targets a different framework than ours. Adopting it would put unpatched third-party code directly on our customer-data boundary. Recommendation: do not adopt. It is genuinely useful as a one-day design reference while we choose our tenancy model, and its existence is a reminder that the tenancy decision is architectural and hard to reverse — worth funding properly rather than solving with the cheapest available package.
To engineering: Treat this as prior art, not a dependency — and note it is a Symfony bundle, so for a Laravel codebase the value is the pattern (tenant resolver middleware early in the lifecycle, request-scoped tenant context, global scopes for data access, explicit rebinding for queued jobs), not installable code. Pull it into a spike branch, write down what we'd steal and what we'd avoid, then evaluate maintained alternatives against an explicit checklist (Laravel version support, release cadence, isolation test coverage, dependents, security process). Whoever adopts a tenancy package owns the customer-data isolation guarantee, so the decision needs a named owner and a documented rationale — and if nothing clears the bar, we scope a small internal layer with a real owner and a migration-ready rollback plan.