Multi Tenancy Laravel Package

Technical Evaluation

Architecture fit: Weak for a Laravel application. The package is a generic/legacy PHP multi-tenancy component from the Superdesk Web Publisher ecosystem, not a Laravel-native tenancy layer. It is unlikely to align cleanly with Laravel middleware, service container, Eloquent connection switching, queue context, cache/storage partitioning, or tenant-aware migrations without custom adapters. It may be useful as a reference for tenant resolution or provisioning concepts, but not as a core platform dependency.

Integration feasibility: Low. With one star, zero dependents, and a last release in June 2018, the package is effectively abandoned. Composer constraints are likely incompatible with modern PHP 8.x and Laravel 10/11. Any integration would require forking, dependency updates, security review, and custom lifecycle hooks for tenant context propagation across HTTP, CLI, queues, scheduled jobs, and tests.

Technical risk: High. Key risks include:

• License: AGPL-3.0 is strong copyleft; network use can trigger source-disclosure obligations. Legal review is mandatory before commercial SaaS use.
• Maintenance: No active maintainer, no recent security patches, no dependents to validate behavior.
• Isolation correctness: Multi-tenancy failures are severe: cross-tenant data leakage, cache collisions, storage path collisions, and queue jobs executing under the wrong tenant.
• Framework mismatch: Laravel’s native idioms may need to be bypassed, increasing long-term maintenance cost.
• Compatibility: PHP version, database driver, cache backend, queue system, and testing framework compatibility are unknown until proven.

Key questions:

• What tenancy model does it implement: shared database with tenant scopes, database-per-tenant, schema-per-tenant, or hybrid?
• Is it framework-agnostic, Symfony-oriented, or Laravel-compatible?
• How does it resolve tenants for HTTP, CLI, queues, and scheduled tasks?
• What is the AGPL implication for a hosted commercial product?
• Are there known security issues or CVEs since 2018?
• Can tenant isolation be proven with automated cross-tenant tests?
• Is the code small enough to fork and own, or should the pattern be reimplemented on a maintained Laravel package?

Integration Approach

Stack fit: Poor as a direct dependency. For a Laravel stack, prefer a maintained Laravel tenancy package such as stancl/tenancy or spatie/laravel-multitenancy, or implement a thin internal tenant manager if requirements are simple. Use swp/multi-tenancy only as a design reference or in an isolated spike.

Migration path: Do not perform a big-bang integration. Start with a time-boxed proof of concept in a disposable branch:

1. Confirm PHP/Laravel compatibility and Composer resolution.
2. Map its tenant resolution, connection switching, and provisioning APIs.
3. Wrap any usable behavior behind an internal TenantManager interface.
4. Build tenant-aware tests for HTTP, CLI, queue, cache, filesystem, and database migrations.
5. Decide whether to fork, vendor, or discard based on legal and isolation results.

If proceeding, vendor or fork the package under AGPL compliance, pin the commit, and document all patches. Keep the integration behind internal interfaces so it can be replaced without rewriting domain code.

Compatibility: Treat compatibility as unproven. Build a matrix for PHP 8.x, Laravel version, MySQL/PostgreSQL, Redis, queue driver, and object storage. Expect to patch deprecated syntax, old dependency constraints, and missing Laravel hooks.

Sequencing: Legal/license review → technical spike → isolation test suite → adapter design → pilot tenant → production rollout. The pilot should include provisioning, migration, backup/restore, and tenant deletion before any customer data is onboarded.

Operational Impact

Maintenance: High. An abandoned 2018 package shifts ownership to your team. Every Laravel/PHP upgrade becomes a compatibility review. Security patching, dependency updates, and framework integration fixes are your responsibility.

Support: Effectively none. There is no active community, no vendor support, and no dependent ecosystem to rely on for fixes. Incident response would depend on internal code ownership.

Scaling: Unknown. Tenant provisioning, connection pooling, migration orchestration, cache partitioning, and queue throughput must be load-tested. Database-per-tenant models can create connection and migration fan-out problems; shared-database models require rigorous scoping and indexing.

Failure modes: The highest-severity failures are cross-tenant data exposure, incorrect tenant context in background jobs, cache key collisions, storage path collisions, failed tenant migrations, connection exhaustion, and incomplete tenant deletion. Add tenant-aware logging, audit trails, isolation tests, and per-tenant backup/restore procedures.

Ramp-up: High. Sparse documentation, stale code, and non-Laravel patterns increase onboarding time. A TPM should budget for an initial discovery spike, legal review, fork ownership, and a dedicated isolation test suite before committing engineering capacity.

Recommendation: Do not adopt swp/multi-tenancy as a production dependency for a Laravel platform without a compelling, validated reason. Leverage it as a reference implementation only; for production, use a maintained Laravel tenancy package or build a small internal tenant abstraction with explicit isolation guarantees.