Laravel Tenant Aware Laravel Package

Product Decisions This Supports

• Multi-tenancy architecture decisions: whether to build tenant isolation in-house or adopt an opinionated package that applies tenant scoping to Eloquent models, so engineering can spend time on product surface area instead of plumbing.
• Feature prioritization: unblocks roadmap items that implicitly assume tenant segregation — per-tenant configs, tenant-scoped reporting, white-label/customer-branded experiences, tiered plans with isolated data, and any "organization/workspace" data model.
• Build vs. buy: a mature, Laravel-native dependency that reduces bespoke tenancy code — cheaper to adopt than maintaining a proprietary scoping layer, though the abstraction becomes a load-bearing dependency to own and upgrade.
• Go-to-market segmentation: supports serving both single-tenant and multi-tenant customers from one codebase, which matters for decisions about entry-level self-serve tiers vs. enterprise accounts.
• Upgrade and platform-lifecycle planning: 2.2.0 adds Laravel 13 support and drops PHP 8.1 — this feeds directly into the decision of when to schedule framework/PHP upgrades and how long to support older runtime baselines.
• Release 2.2.0 is largely housekeeping: the bulk of the changelog is Dependabot bumps to CI tooling (laravel-pint-action, fetch-metadata). The only product-relevant change is the Laravel 13 / PHP 8.1 shift. Treat this as a maintenance release, not a capability release — no new features to sell or re-plan around.

When to Consider This Package

Consider adoption when:

• The product is (or is becoming) multi-tenant SaaS on Laravel, and tenant isolation is a cross-cutting concern touching many models rather than a single bounded feature.
• The team wants convention over invention — a package-managed scoping approach instead of a hand-rolled global scope trait that drifts per developer.
• You are on a supported runtime: this release signals an active forward path for Laravel 13, but PHP 8.1 is no longer supported. If your runtime baseline is 8.1, stay on 2.1.x or budget the PHP upgrade first — this is a breaking constraint, not a soft deprecation.
• You want an actively maintained dependency with automated dependency hygiene (the Dependabot cadence here is a positive maintenance signal).

Look elsewhere or build in-house when:

• You need database-per-tenant provisioning, migration orchestration, or fleet-scale tenant lifecycle management — this package is about tenant-aware model behavior, not full tenancy infrastructure.
• Your isolation requirements are regulatory or security-critical (data residency, hard separation guarantees) where you need auditable, bespoke controls rather than a community package's default scoping.
• You are not on Laravel or run a heavily customized Eloquent layer that will fight the package's assumptions.
• You need a large, independently verifiable user base — a smaller-vendor package means you should factor in due-diligence cost and a contingency plan for maintainer turnover.

How to Pitch It (Stakeholders)

For executives: This is a small, focused Laravel component that handles tenant data separation — the mechanism that lets one product serve many customers safely. Adopting it instead of building our own shortens time-to-market for multi-tenant features and lowers the risk of isolation bugs, which are expensive and reputationally damaging. The 2.2.0 release is maintenance-only plus support for the next Laravel major version; it contains no new product capability. The one real cost is that it drops PHP 8.1, so we should confirm our runtime baseline and fold any PHP upgrade into existing platform work rather than treating it as a surprise.

For engineering: 2.2.0 is a dependency-hygiene release — CI action bumps plus Laravel 13 support and PHP 8.1 removal. Upgrade is low-risk if we're already on PHP 8.2+; if any service is still on 8.1, that's the gating item. No API or behavioral changes indicated, so no migration work beyond the runtime bump. Recommend pinning to ^2.2 once the PHP baseline is confirmed, and keeping an eye on the release cadence as a maintenance-health signal.

Recommendation: Adopt/continue with the package, but treat this release as an upgrade trigger for our PHP baseline, not a feature event. Verify runtime support before bumping the constraint.