Laravel Multitenant Laravel Package

Product Decisions This Supports

• Tenancy architecture choice (the big one). This package commits the product to single-database, shared-schema multi-tenancy (tenant_id discriminator + Eloquent scoping). That is a product decision, not just a technical one: it determines per-tenant pricing economics, whether you can ever sell "data isolation" to enterprise buyers, and how expensive GDPR/right-to-be-forgotten and per-tenant restore become.
• Build vs. buy vs. borrow. Realistic alternative is 1–3 weeks of in-house scoping boilerplate (tenant resolver, global scopes, job/command/queue propagation, admin bypass). At 24 stars and a single release in 2024, treat this as borrow-with-a-fork-plan, not buy. The decision is "do we spend a week on a spike to save two weeks of build?"
• Roadmap sequencing. Enables a fast multi-tenant SaaS launch (many small tenants, uniform schema) while deferring DB-per-tenant isolation until a signed contract or compliance requirement forces it. Good for MVP → first 50 customers; a one-way-ish door for later re-architecture.
• Packaging and pricing inputs. Shared tables make cross-tenant analytics cheap — this directly enables admin dashboards, benchmarking/aggregate features, and usage-based billing queries. Conversely it caps per-tenant customization and "dedicated instance" premium tiers without additional engineering.
• Use cases it fits: B2B SaaS with many small, homogeneous tenants; internal tools; proof-of-concept multi-tenancy before committing capital.
• Risks it puts on the product roadmap (must be tracked): data-leakage via any unscoped query path (queues, artisan commands, raw SQL, admin panels) — a trust-destroying event; noisy-neighbor performance on shared tables; per-tenant backup/restore and deletion are application-level; schema migrations now touch every tenant at once.

When to Consider This Package

Adopt (with guardrails) when:

• The team is already on Laravel and comfortable reading/forking a small package — vendor it and pin the version.
• Tenants are numerous, small, and have identical data requirements; no per-tenant schema customization, no data-residency or BYOK commitments in the current sales pipeline.
• You are pre-product-market-fit and speed-to-learn outweighs long-term durability; a later re-architecture is an acceptable cost of being wrong.
• You can absorb the maintenance risk: 24 stars, single-maintainer profile, last release March 2024, no evidence of security audit or broad production usage.

Look elsewhere when:

• You need per-tenant databases/schemas, tenant-aware migrations, or tenant-level backup/restore → evaluate stancl/tenancy, the de facto standard in this ecosystem, before writing anything.
• Enterprise/regulated buyers will require physical isolation, data residency, or key management — the shared-schema model becomes a sales blocker you cannot patch around.
• You want isolation enforced below the application layer → consider Postgres Row-Level Security rather than relying on Eloquent global scopes, which are bypassable by construction.
• You need an SLA, security patching guarantees, or a vendor who will respond to a CVE.
• You have a few very large tenants where noisy-neighbor performance on shared tables is commercially unacceptable.

Minimum diligence before any commitment: a 2-day spike reading the source, checking test coverage, and deliberately attempting scope escapes through jobs, console commands, and raw queries. If that spike is uncomfortable, that is the answer.

How to Pitch It (Stakeholders)

To executives: This is an accelerator, not a platform bet. It lets us ship a multi-tenant tier in days instead of weeks by reusing a shared-database pattern, at the cost of deferring "dedicated instance / data isolation" as a sellable enterprise feature. The financial exposure is small and bounded — the package is small enough to fork and own — but the reputational exposure of a cross-tenant data leak is not, so adoption is contingent on our own leak-regression tests and a documented exit path. Recommendation: approve a short evaluation spike against the mature alternative, not a direct dependency add.

To engineering: Evaluate the pattern (tenant resolver + tenant_id + global scopes) on its merits, not the package's popularity. Benchmark it against stancl/tenancy; if we adopt, vendor/fork it, pin the version, and write our own test suite specifically for scope leakage across queues, scheduled commands, and raw queries. Assume the package will be unmaintained within a release cycle and plan accordingly.