Multi Tenancy Bundle Laravel Package

Technical Evaluation

Architecture fit

The first thing to flag in any cross-functional review is a naming mismatch: despite being evaluated under a "Laravel/PHP package" lens, mapeveri/multi-tenancy-bundle is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config/multitenancy.php, and no package auto-discovery. For a Laravel codebase the fit is zero without a port, and the port is a rewrite, not an adaptation.

The underlying model — a config-driven tenant resolver that binds tenant context into the container during the request lifecycle — is sound and matches what every production tenancy library eventually does. But the value here is conceptual, not functional: the package demonstrates the shape of tenant resolution, not a runtime you can depend on. Multi-tenancy is a security boundary (one tenant reading another's data), so the architecture fit matters much more than for a typical utility. A pre-modern implementation of a security boundary is a liability, not an enabler.

Integration feasibility

Low, and effectively blocked three ways:

1. Framework mismatch — Symfony bundle cannot be auto-wired into Laravel.
2. Era mismatch — Laravel 4 / Symfony 2-era conventions (manual bundle registration, pre-Composer conventions) precede the service-provider era that modern Laravel assumes.
3. Maintenance posture — the README carries an explicit WARNING: this repo is not maintained anymore. Combined with 11 stars and 0 dependents, there is no community to lean on: no reference implementations, no fork ecosystem, no third-party security review.

Technical risk

High and asymmetric. The downside of a tenancy defect is cross-tenant data exposure, which is a reportable incident in most regulated environments. Adoption would put unmaintained code directly on the customer-data boundary with:

• No CVE tracking, no patch channel, no upstream escalation path.
• Unknown test coverage on isolation paths.
• Unverified behavior for background jobs, scheduled commands, cache/session namespacing, and long-running workers (Octane).
• Composer version constraints likely to fence us out of framework security upgrades elsewhere.

Key questions (to resolve before any spike spend)

• Which stack are we actually on? If Laravel, this package is disqualified as a dependency and survives only as a reading reference. If Symfony, still check whether the declared constraints overlap with ours.
• What isolation model do we need — shared schema with row scoping, schema-per-tenant, or database-per-tenant — and which of those does the bundle's resolver actually enforce (vs. assume)?
• Where is the isolation boundary enforced? Doctrine filters, connection switching, or convention. If it can be bypassed by a raw query, that's the whole risk.
• How does tenant context propagate to queued jobs, scheduled commands, and long-running workers?
• Is there a named internal owner for the fork, with a written maintenance commitment and an exit cost if abandoned in 12 months?

Integration Approach

Stack fit

The realistic TPM framing is build-vs-adopt vs. reference, not "how do we install this":

• Adopt — disqualify. Unmaintained, zero dependents, framework mismatch for Laravel. Recommendation: do not composer require.
• Adopt a maintained alternative — evaluate stancl/tenancy or spatie/laravel-multitenancy (for Laravel) or a maintained Symfony bundle against the isolation model.
• Build a thin internal layer — a tenant resolver (middleware/kernel listener), a tenant-context service, an Eloquent trait or Doctrine filter for scoping, and a connection manager. ~2–4 weeks with a test suite is the honest estimate; the ongoing cost is what matters.
• Reference only — read the source during a design spike. This is the recommended use of the package.

Migration path (only if we insist on using it)

Fork → rename to internal namespace → pin Composer constraints → replace Symfony bundle registration with a Laravel service provider (or a Symfony DI extension if staying on Symfony) → port deprecated APIs → wrap every query path in an isolation test harness → security review → feature-flagged staged rollout. Budget 3–6 weeks engineering, and treat it as a rewrite with the original as a design document, not a dependency upgrade.

Compatibility

Expect hard blocks from PHP-version syntax and pre-modern Symfony/Laravel contracts. The most common realistic outcome is a Composer conflict that prevents installation outright, or an install that pins the framework to a version that blocks unrelated security patches. Confirm the version matrix from composer.json before allocating sprint capacity.

Sequencing

1. Spike (1–2 days): read source, confirm isolation model, confirm version constraints, write a one-page "what we'd steal / what we'd avoid."
2. Decision gate: maintained alternative vs. build-in-house. Default recommendation: maintained alternative; fall back to build.
3. Only if fork: 3–6 week rewrite with an isolation test suite accepted before any feature work.
4. Security review + feature-flagged rollout with a rollback path that does not depend on the package.

Operational Impact

Maintenance

We inherit 100% of the burden. No upstream commits, no dependency updates, no advisories. Every Laravel/Symfony major version is manual porting work against code we now own. This is the single largest ongoing cost and the one TPMs most often underestimate.

Support

No maintainer triage, no issue response, no community forum presence. Designate at least two engineers as owners who understand the isolation model well enough to be on-call for it. Codify an SLA for isolation defects — these are SEV-1 by nature, and "upstream will fix it" is not an option.

Scaling

Unknown and untested. Connection-per-tenant switching has real implications for connection pools and per-tenant latency as tenant count reaches the hundreds/thousands. Background workers are the classic failure point: if tenant context isn't rebound per job, jobs silently run against the wrong tenant. Neither property is validated by an 11-star project.

Failure modes to put on the risk register

• Tenant-context leakage across requests, especially under Octane or long-running workers.
• Cross-tenant reads/writes from unscoped raw queries or bypassed filters.
• Migrations executed against the wrong tenant database.
• Cache key and session collisions between tenants.
• Silent breakage: with no maintainer, defects are discovered by us, in production, without upstream fixes.

Ramp-up

Documentation is minimal or stale; no example applications exist. New engineers must read source to understand behavior. Combine that with the security sensitivity of the domain and onboarding cost is measured in weeks, not days. Factor this into the resourcing plan alongside the rewrite.

Bottom line for the product decision: the package's score (0.305), zero dependents, and explicit unmaintained status are consistent with what any code inspection will show. Close the evaluation at the spike stage. Redirect engineering toward a maintained tenancy library or a small internal implementation with a named owner. Fund the tenancy decision properly — it is architectural and hard to reverse — rather than reaching for the cheapest available package on the customer-data boundary.