Multi Tenancy Bundle Laravel Package

Technical Evaluation

Category mismatch is the first finding. Despite being surfaced in a Laravel/PHP package search, swp/multi-tenancy-bundle is a Symfony bundle, not a Laravel package. It is a read-only subtree split of the Superdesk Web Publisher (SWP) monorepo, and it implements tenancy for a specific Symfony-based content publishing platform — not a general-purpose tenancy abstraction. Any evaluation of "fit" must start from that framing.

Architecture fit

• Designed around Symfony's DI container, bundle extension conventions, event dispatchers, and Doctrine ORM listeners/filters. The core mechanism is tenant-aware entities plus a Doctrine filter that scopes queries to the resolved tenant.
• Tenant resolution is coupled to SWP domain concepts (tenants, themes, publications, routing), not a generic "resolve tenant from host/subdomain/header" contract. That coupling is the reason it cannot be lifted cleanly into another framework.
• Assumes a shared database, shared schema, tenant_id discriminator model. There is no schema-per-tenant or database-per-tenant provisioning here — that lives elsewhere in the SWP stack.
• For a Laravel codebase the architectural fit is poor: Laravel tenancy is normally handled by stancl/tenancy or tenancy/tenancy, which own tenant identification, DB switching, cache/queue/filesystem/Redis namespacing, and Octane safety. This bundle provides a narrower slice of that surface, in a foreign idiom.

Integration feasibility

• Low for direct adoption into a Laravel app. Expect Composer conflicts on symfony/* components, doctrine/orm, and PHP version constraints (the 2018 release line predates PHP 8). Laravel 10/11 requires PHP 8.1+ and Symfony 6/7 components; resolution would require a fork and platform-req overrides.
• Medium-high only if the organization is already running Symfony and the SWP component family (swp/tenancy, swp/tenant-bundle, swp/publisher). In that context it is the intended component and the constraint graph resolves.
• Pulling Doctrine into an Eloquent-first application to use one bundle is a large architectural tax for a small, unmaintained capability.

Technical risk

• Licensing: AGPL-3.0 is the dominant risk. Network copyleft obligations attach to software offered as a service. For a commercial SaaS, this is a legal review item before any code is vendored — not a footnote.
• Abandoned. Last release 2018-06-11, 30 stars, zero dependents. No CVE triage, no PHP 8 compatibility work, no security response path. The composite score (~0.95) reflects topical relevance, not health; the opportunity score (3.12) should be read alongside these negatives.
• Read-only split. This repo accepts no PRs. Any fix becomes a permanent local fork with no upstream merge path. The canonical history lives in the SWP monorepo, which is itself dormant.
• Silent-failure surface. Tenant scoping implemented as a query filter means any raw SQL, native query, or listener bypass leaks cross-tenant data without an error. This is a correctness risk, not just a maintenance one.

Key questions

1. Is our target runtime Laravel or Symfony? If Laravel, is this being evaluated as a design reference or as a dependency? (Recommendation: reference only.)
2. Has legal signed off on AGPL-3.0 for a network-delivered service?
3. What isolation model do our customers/regulators require — shared schema with a discriminator, or database-per-tenant for backup/restore and residency?
4. Does the bundle's tenant context cover CLI, queue workers, and long-running processes, or only HTTP requests?
5. Is there a maintained fork or a vendor relationship with the Superdesk team that makes upstream support real rather than theoretical?
6. What is the actual capability gap we are trying to close — identification, data isolation, cache/storage namespacing, or per-tenant migrations? Each points to a different solution.

Integration Approach

Stack fit

• Target stack Laravel/Eloquent: do not integrate. Reimplement the concept with stancl/tenancy, which covers identification, DB switching, cache/queue/filesystem/Redis prefixing, and per-tenant migrations — the capabilities this bundle only partially addresses.
• Target stack Symfony + SWP: integrate as intended, pinning the resolved versions and vendoring a fork under our own namespace so we control patches.
• Hybrid (Symfony service emitting tenant-scoped read models consumed by a Laravel app): technically possible, operationally expensive, and not recommended for a first tenancy rollout.

Migration path

1. Treat the bundle as a reference architecture, not a dependency. Extract the pattern: tenant context resolver → request-scoped context holder → tenant-aware entity contract → automatic query scoping → explicit escape hatch for cross-tenant admin operations.
2. Map each pattern onto the chosen Laravel primitive, and document where behavior differs (notably: filter-based scoping vs. connection-based scoping).
3. If any code is copied, isolate it behind an internal adapter interface so a future swap does not touch domain code.
4. Never run a Doctrine tenant filter and Eloquent global scopes side by side over the same tables; pick one enforcement point.

Compatibility

• Verify composer.json PHP and Symfony constraints against the target framework before any spike; assume conflicts on symfony/http-foundation, symfony/console, symfony/event-dispatcher, and doctrine/orm.
• Assume PHP 8 incompatibility (dynamic properties, removed functions, deprecated signatures) and budget a hardening pass if a fork is required.
• The bundle's DB schema expectations must be reconciled with our migration tooling; there is no per-tenant migration runner here.

Sequencing

1. Week 0 — decision gate. Legal ruling on AGPL; confirm Laravel vs Symfony target; confirm isolation model.
2. Week 1 — spike. Prove tenant identification and query scoping end-to-end with stancl/tenancy in a throwaway branch, using this bundle only as a checklist of concerns.
3. Week 2 — threat model the leak paths. Raw queries, jobs, console commands, subrequests, cache keys, file paths, search indexes.
4. Weeks 3+ — build. Identification middleware, tenant-aware model trait/global scope, per-tenant migration and seeder path, CI test that asserts cross-tenant invisibility for every model.
5. Defer indefinitely: adopting swp/multi-tenancy-bundle as a runtime dependency in a Laravel application.

Operational Impact

Maintenance

• Upstream is effectively frozen. Adopting it means becoming the maintainer: fork, patch, track PHP/Symfony/Doctrine upgrades, and re-audit on every framework bump. Budget an ongoing owner (roughly 0.25–0.5 FTE steward) if adopted for real.
• The read-only subtree split means our fork can never be merged back, so divergence is permanent and any future upstream fix (unlikely) requires manual reconciliation.

Support

• No maintainer, no issue tracker on this repo, no release cadence, no documented support channel. Documentation exists only as a byproduct of SWP platform docs.
• Internal knowledge will be single-sourced unless deliberately spread; write the runbook during the spike, not after launch.

Scaling

• The tenancy primitive itself is not the bottleneck; the shared-schema model is the scaling constraint. Noisy-neighbor effects are shared across tenants, per-tenant restore is a row-level exercise, and data-residency commitments are difficult to honor.
• Tenant resolution and context propagation add negligible latency; the query filter adds a predicate to every statement, which matters for large tables without a leading tenant_id index.
• Long-running workers and Octane-style runtimes need explicit context reset between jobs — a classic source of tenant bleed.

Failure modes

• Tenant context unset in a queue worker or console command → either zero rows (loud) or unscoped results (silent and dangerous).
• A query path that bypasses the filter (raw SQL, native query, DQL without the filter enabled) → cross-tenant data exposure.
• Cache, session, or filesystem keys not namespaced by tenant → collision and leakage.
• Tenant resolution from a spoofable host or header → tenant impersonation.
• Missing tenant row on a request → unhandled exception rather than a clean 404.
• Upgrade of Doctrine/Symfony silently disabling the filter registration.

Ramp-up

• A Laravel-fluent engineer needs ~2–4 weeks to be productive in Symfony bundle conventions and Doctrine filter semantics, plus additional time for the SWP domain model. Skills do not transfer from typical Laravel hiring pipelines.
• Because the package is unmaintained and undocumented outside its parent platform, onboarding cost is front-loaded onto whoever runs the initial spike — plan for that person to own the internal design doc that replaces the package's missing documentation entirely.