Multi Tenancy Laravel Package

Product Decisions This Supports

• Build vs. buy on the tenancy layer. This package is a candidate for "buy" (i.e., adopt as a dependency) on the single hardest-to-retrofit piece of a B2B SaaS architecture. The decision it informs is whether tenant resolution and isolation are something we consume or own.
• Enterprise/agency tier roadmap. Multi-tenancy is the enabling capability behind a specific cluster of sellable features: custom domains and white-label branding, per-tenant themes/templates, tenant-scoped admin and permissions, and (depending on architecture) per-tenant data residency. Sequencing those roadmap items is blocked until the tenancy model is chosen.
• Data isolation and compliance posture. Single-database-with-tenant-scoping vs. schema-per-tenant vs. database-per-tenant is a customer-facing commitment. It drives what we can say in security questionnaires, how we handle per-tenant deletion/export, and what a "data breach" means for our blast radius. This package sits directly on that decision.
• Time-to-market for a "workspaces/organizations" primitive. If tenancy is on the near-term roadmap, the make-vs-adopt call has a schedule consequence; if it isn't, this evaluation should be deferred rather than resolved.
• Reference design input, not a dependency. The durable value here is as an artifact in an architecture review or ADR — a worked example of tenant resolution by host/domain and tenant-context propagation — not as a line in composer.json.

When to Consider This Package

Adopt only if all of the following hold:

• You are already inside the Superdesk Web Publisher / Symfony ecosystem and already accept AGPL-3.0 obligations for the product.
• Legal has explicitly cleared AGPL-3.0 for your distribution model — including the §13 network-use clause, which triggers source-disclosure obligations toward users interacting with the service over a network. For a multi-tenant SaaS this is the worst-case license shape, not a footnote.
• The deployment is internal and non-distributed, or fully open source.
• You are running a time-boxed spike and need a working tenant-resolution model more than you need maintenance guarantees.
• You have read the source and confirmed it fits your PHP version and framework of record.

Look elsewhere by default. Concrete disqualifiers:

• Laravel product. There is no evidence this is Laravel-native; expect Symfony/Doctrine coupling and framework glue that doesn't map. Use stancl/tenancy or spatie/laravel-multitenancy instead — both are maintained, Laravel-idiomatic, and have real adoption.
• Proprietary or commercially licensed product. AGPL is a non-starter without a licensing strategy.
• Tenant isolation is a security boundary for you. It always is. A package with a single star, zero dependents, and a last release in June 2018 is unmaintained code standing between tenants. That is not a risk you accept for a boundary you will be audited on.
• You need an SLA, security patching, PHP 8.x compatibility, or a migration path from an existing single-tenant dataset. None of these are plausibly supported here.

If you do evaluate it, grade it on: fail-closed behavior when tenant context is missing, cache-key and filesystem/queue namespacing, tenant-aware auth and session handling, and test coverage of cross-tenant leakage. Those are the failure modes that matter; the resolution-by-hostname logic is the easy part.

How to Pitch It (Stakeholders)

For executives: We evaluated an open-source package for the multi-tenant foundation of the enterprise tier and recommend against adopting it. Three reasons: it is licensed AGPL-3.0, which would obligate us to disclose source to customers using our service; it has had no release since 2018 and effectively no users or downstream dependents, so there is no one to fix a security defect in the code that separates one customer's data from another's; and its framework assumptions don't match our stack. There is no cost saving to weigh against that — the tenancy core is a contained engineering effort we would own and control, and we would spend more time adapting and auditing this package than writing the equivalent. Recommendation: build the tenancy layer, or adopt a maintained framework-native library, and use this codebase only as a design reference during architecture review. No budget or schedule impact either way.

For engineering: Treat this as a reference implementation, not a dependency. Mine it for the tenant-resolution and context-propagation model, then implement against our own requirements — fail-closed tenant context, cache/queue/storage namespacing, tenant-aware auth, and a migration path for existing data. If we want an off-the-shelf option, evaluate stancl/tenancy or spatie/laravel-multitenancy; both are actively maintained and idiomatic to our stack. Verify PHP version and framework compatibility before any further investment of time.