Laravel Multi Tenant Manager Laravel Package

Product Decisions This Supports

• The tenancy model decision, which is really a pricing and ops decision. "Do we support multiple customers on one instance?" is not an engineering question — it determines whether you can sell a self-serve tier with instant activation or whether every customer requires a provisioning runbook. This package's advertised capabilities (subdomain/domain resolution, per-tenant database connections, Eloquent scoping) are a concrete menu of the isolation models available, and reading that menu forces the product decision early instead of discovering it mid-build.

• Build vs. buy — with the honest answer being "neither, yet." At 1 star, 0 dependents, a single 0.1.0 release dated August 2021, and a changelog that says only "initial functionality," this is not a vendor you can buy from. It is a design reference. The decision it informs is build, with this repo as prior art to critique in a spike — not buy, because there is no counterparty, no support commitment, and no adoption signal to borrow confidence from.

• Cost-to-serve shape. "Per-tenant database connections" sounds free on a feature comparison and is expensive in operations: migrations across N databases, per-tenant backup and point-in-time restore, connection-pool pressure, and a much harder staging story. Choosing this model is a standing infrastructure cost that belongs in the pricing model, not just the architecture doc.

• Enterprise deal enablement. If the pipeline contains any variation of "can this customer get their own database / their own region / a restore of only their data," tenancy is a revenue-blocking capability rather than a nice-to-have. That question is the trigger to act.

• Onboarding and activation design. Tenant resolution from subdomain vs. path vs. custom domain cascades into signup flow, SSL provisioning, invitation and SSO behaviour, and how much of the funnel is self-serve. Worth deciding before the onboarding screens are designed, not after.

• Fits for use cases like: B2B SaaS with named accounts, agency/white-label deployments where each client wants their own instance, and multi-brand storefronts. Poor fits: consumer apps, anything where "tenant" is really just "user."

When to Consider This Package

Consider it as reading material — not as a dependency — if:

• Multi-tenancy is a real roadmap item within the next two quarters and no decision has been made on the isolation model. A one-to-two day spike against this repo (or its README plus src/) is cheap and produces a written comparison of isolation strategies.
• You have a named engineer who can own a fork. The last release predates current Laravel majors; assume you would be maintaining this, not consuming it.
• Tenancy is a supporting capability, not the product. If your differentiation is "we isolate your data better than anyone," you cannot outsource that to a 2021 single-release package.
• The blast radius is genuinely low — no auth, payments, or data-integrity path in the first integration.

Look elsewhere — or build — if any of these are true:

• You need a maintained dependency. stancl/tenancy and spatie/laravel-multitenancy are the obvious maintained comparisons and should be on the same evaluation sheet. This package should be evaluated against them, not in isolation.
• You're on a current Laravel version. With the last release in August 2021 and no published version matrix, compatibility with anything recent is unverified — treat "does it even install" as an open question, not an assumption.
• You need an SLA, a security disclosure policy, or a support contract. There is no issue history, no documented support commitment, and no signal about maintainer count. Escalation is "the maintainer's GitHub," which is acceptable for a utility and disqualifying for anything customer-data-adjacent.
• You want managed isolation (separate schemas, Postgres row-level security, per-tenant infrastructure) rather than a PHP package's opinion about it.
• Nobody can own it. The recurring cost here is upgrade review every Laravel cycle, indefinitely. If that owner doesn't exist, the answer is no regardless of code quality.

How to Pitch It (Stakeholders)

For executives — one paragraph: Multi-tenancy is a decision we will eventually have to make, and it quietly sets our pricing floor (per-tenant databases cost real money to operate) and our enterprise ceiling (some buyers will require data isolation before they sign). This specific package is not the answer — one star, zero dependents, one release in 2021, no documentation, no support — but it is a free, concrete catalogue of the isolation options, and it costs us half a day of one engineer to read it and come back with a recommendation. The ask is not approval to adopt a dependency. The ask is approval for a half-day discovery and a two-day spike, with a kill-criteria gate before anything touches production. The expected outcome is a written build-vs-alternatives recommendation, with an internal interface we keep either way.

For engineering — the framing that matters: we are buying an implementation detail, so we should buy the interface first. Install the package behind our own contract and an adapter binding; nothing in application code references the package namespace. Pin it exactly (0.1.0, never ^0.1 — pre-1.0 semver permits breaking changes in a minor bump), and publish and commit any config it ships so that default drift shows up as a diff in our repo rather than as a behavioural change in production. Two specific things to verify in the spike rather than discover later: whether it does synchronous work in the request hot path, and whether it holds tenant state across queue workers or Octane requests — that second one is a common and expensive failure mode in Laravel packages written against the traditional per-request lifecycle. If the spike passes, we have a working prototype; if it fails, we keep the interface and write a thin in-house implementation, and the adapter cost is sunk either way. That is the point.

For everyone — what would change my mind: an active maintainer, tests running in CI, a license we can live with, and a version constraint that covers our Laravel. Failing any of those, this repo's value is the lessons in it, not the code.