Framework Laravel Package

Product Decisions This Supports

• SaaS delivery model: Informs whether the product can be sold as a shared-infrastructure, multi-tenant SaaS (one codebase, many customers) versus single-tenant deployments per customer. The package is the plumbing that makes tenant-aware behaviour possible across database, cache, filesystem, queue, and session layers.
• Data isolation strategy — the biggest architectural fork: Single database with row-level scoping vs. database-per-tenant vs. hybrid (shared DB for small accounts, dedicated DB for enterprise). This framework is deliberately unopinionated about the storage model, so it supports shipping a tiered isolation offering rather than locking the roadmap into one.
• Build vs. buy on tenancy infrastructure: The core build-vs-buy call is whether tenancy primitives are a differentiator (they are not, for 95% of B2B SaaS) or table stakes to be adopted. This package represents the "buy/adopt" branch: use a maintained abstraction instead of hand-rolling tenant resolution, bootstrapping, and lifecycle hooks.
• Enterprise tier feasibility: Tenant onboarding, offboarding, per-tenant migrations, and per-tenant configuration are the mechanics behind "Enterprise plan" packaging. Knowing the framework handles tenant lifecycle events lets product commit to self-serve provisioning and dedicated-instance upsells.
• Roadmap sequencing: Because tenant bootstrapping is a cross-cutting concern, adoption is a platform-phase investment that should land before the first paying customer, not retrofitted. This shapes release sequencing and pricing launch dates.
• Operational cost modelling: Database-per-tenant changes hosting, backup, and support economics. The framework makes the choice reversible-ish, which supports a "start shared, split later" strategy and defers infrastructure spend.

When to Consider This Package

Consider it when:

• You are building a Laravel/PHP B2B SaaS and multi-tenancy is a foundational requirement, not an edge case.
• You need tenants to be first-class objects with lifecycle events (created, bootstrapped, migrated, deleted) that other systems (billing, provisioning, analytics) can hook into.
• You expect to support more than one isolation model over the product's life, or expect to migrate from shared DB to dedicated DB per large customer.
• You want per-tenant driver configuration (separate cache, queue, storage, and mail) rather than a single global config.
• You are comfortable that this is a low-level framework layer — it is the substrate, not the finished product. Budget for integration and driver wiring.

Look elsewhere when:

• You are not on Laravel. There is no value here for Symfony, Node, Django, or polyglot stacks; that is a platform decision, not a package decision.
• Row-level scoping is genuinely sufficient and will stay sufficient. For a small, simple app, straightforward global scopes or a lighter-weight multitenancy package will get you to market faster with less abstraction to learn.
• You need a high-level, batteries-included package. This is the framework code, not the ready-to-use tenancy package; you will likely want the higher-level packages in the same ecosystem. Adopting this one alone means significant wiring.
• Supply-chain risk tolerance is low. 13 stars and a low composite score mean thin community validation. No vendor SLA, no commercial support, small hiring pool. If your organisation requires a supported dependency with a security-response commitment, this is a gap you must accept and self-insure against — vendor the code, pin versions, and assign an internal owner.
• The team has no Laravel service-provider fluency. The abstraction is powerful precisely because it hooks deeply into the container and boot lifecycle; debugging it requires framework depth.

How to Pitch It (Stakeholders)

For executives (the commercial case): We are deciding how to serve many customers from one product without letting their data touch. The default path is to build tenancy ourselves — authentication scoping, per-customer databases, provisioning, backups, and the audit story. That is months of platform work that no customer will ever pay for, and it delays revenue. This package is a proven pattern, MIT-licensed and free of vendor lock-in, that gives us that foundation so engineering time goes into the product instead. The practical outcome: we can launch a shared-infrastructure SaaS sooner, sell a dedicated-database "Enterprise" tier without re-architecting, and reduce the risk of the single worst failure mode in B2B SaaS — one customer seeing another customer's data. The caution is counterpart to the upside: it is a small open-source project, so we adopt it deliberately, own the code internally, and do not assume anyone else will fix it for us.

For engineering (the delivery case): This is the core framework layer of the tenancy ecosystem — tenant resolution, bootstrapping, lifecycle events, and per-tenant driver hooks — not an end-user package. Adopting it means we stop re-inventing tenant context propagation and instead wire drivers and events to our own requirements. It is MIT and Laravel-native, so it composes with the stack we already run. The trade-off is real: low adoption (13 stars, low health score), no commercial support, and an abstraction that reaches into the container and boot sequence, so ramp-up and debugging cost is non-trivial and we should treat it as code we own. Recommendation: prototype it against one representative service before committing, evaluate the higher-level packages in the same ecosystem alongside it rather than this low-level repository in isolation, and only proceed if the isolation model it enables is one we genuinely intend to sell.