Multitenant Plugin Laravel Package

Technical Evaluation

Architecture fit. The package is a Filament admin-panel plugin that provides tenant management UI on top of stancl/tenancy. That framing matters for the evaluation: the load-bearing, hard-to-reverse part of the architecture is stancl/tenancy (tenant resolution, database isolation, bootstrappers, lifecycle events), and this package is a thin resource/forms/actions layer that drives it. So the architecture question splits in two: (1) does stancl/tenancy fit our application — a strategic decision independent of this plugin; and (2) does this plugin fit how we build Filament panels — a much narrower, lower-stakes decision. A TPM should evaluate them separately and not let a 1-star UI wrapper gate a decision about the tenancy substrate, or vice versa.

Integration feasibility. Mechanically straightforward: Composer install, register the plugin on a Filament panel, publish config, point it at the tenant model and the stancl/tenancy connection/domain configuration we already own. The real feasibility constraint is version alignment across three moving parts — Filament major (v3 vs v4), stancl/tenancy major, and Laravel/PHP floor. Filament ships majors on a roughly annual cadence and is willing to break plugin APIs; a single-maintainer plugin with one star is unlikely to track that cadence promptly. Treat the plugin as feasible only if we accept that we may pin Filament or own a fork.

Technical risk. Ranked:

1. Bus-factor and scrutiny risk. One star and a single maintainer means effectively no community review, no third-party security reporting, and no guarantee of a response to a Filament-breaking change. This is the dominant risk — not code quality, but the absence of a crowd to catch problems.
2. Filament version coupling. The plugin's surface is Filament resources, pages, and actions — precisely the APIs most likely to churn. A Filament upgrade becomes a blocked-by-upstream event.
3. Implicit coupling to stancl/tenancy internals. Tenant provisioning orchestration (DB creation, migrations, seeding, domain setup) is where subtle bugs live; if the plugin wraps those lifecycle calls opaquely, failures are hard to diagnose and hard to override.
4. Authorization surface. A UI that lists and switches between all tenants is a privileged control plane. The plugin is unlikely to ship an opinionated authorization model matching ours; we must own that, and a misconfiguration here is a cross-tenant data-exposure incident rather than a UI bug.
5. Opaque failure semantics. With minimal documentation, partial-provisioning and rollback behaviour must be discovered by reading source.

Key questions.

• Which Filament major(s) are supported, and does the maintainer intend to track Filament releases? What is the stated support policy?
• Which stancl/tenancy major is required, and does the plugin constrain it permissively enough that a stancl/tenancy patch does not require an upstream release?
• Does the plugin own tenant provisioning (DB creation, migration, seeding) or only present forms over our own actions? Can we substitute our provisioning service behind its UI?
• How does it model authorization — policies, gates, panel access — and can we replace that with our own without forking?
• Does it assume a central panel or a tenant panel, and does it support both domain- and subdomain-based identification?
• What is published to our repo (config, migrations) that we then own and must maintain?
• What does removal look like — do published config, migrations, or route registrations survive? Is the UI additive only?
• Evidence gap: near-zero adoption (1 star) and no visible release documentation means there is no external corroboration of production use. Any green light here is a bet on a thin forkable surface, not on the package's maturity — and the assessment should say so explicitly.

Integration Approach

Stack fit. Confirm against a single target Filament panel first: PHP floor, Laravel major, Filament major, stancl/tenancy major, and no conflict in shared dependencies (notably spatie/laravel-package-tools, which many Filament plugins pull in at differing constraints). Confirm it composes with our existing panel conventions — auth guard, navigation grouping, policies — rather than imposing its own. Where it deviates, cost the deviation as customization work we will carry forever.

Migration path. This is greenfield for the plugin itself, which is the favourable case: introduce it as a presentation-layer adapter over provisioning and tenancy services we already control. The architectural rule to set now is that domain and infrastructure code must never import the plugin's classes; the plugin consumes our services, never the reverse. If the plugin cannot be confined to that seam — if it insists on owning tenant creation end to end — that is the signal to skip it and write ~a few hundred lines of Filament resource ourselves. Budget that alternative explicitly; for a UI layer of this size it is a realistic fallback and materially de-risks the decision.

Compatibility. Three axes to pin in a decision record: Filament major, stancl/tenancy major, Laravel/PHP. Set a version-pin policy up front — permissive constraints where safe so routine patches flow, an explicit upper bound on Filament so a surprise major cannot land in CI. Add a scheduled job or dependabot lane that surfaces upstream releases so we learn about breakage from a dashboard rather than a failed deploy.

Sequencing.

1. Ratify stancl/tenancy as the tenancy substrate on its own merits; the plugin decision is subordinate to it.
2. Verify the Filament/stancl/tenancy/Laravel/PHP matrix in a throwaway branch before committing engineering time.
3. Spike on one non-critical service: stand up a central panel, provision two tenants end to end, exercise suspend/delete, and confirm our policies — not the plugin's — gate access.
4. Run the uninstall test: remove the package and confirm no residue in config, migrations, routes, or container bindings.
5. Decide build vs. consume with the spike's actual numbers in hand; if consume, record the fork policy and the named owner.
6. Extend to a second service only after the first has run a full release cycle without intervention.

Operational Impact

Maintenance. The honest maintenance burden here is Filament, not Laravel: expect at least one compatibility event per Filament major. Because the surface is thin, the mitigation is cheap and should be pre-agreed — fork and vendor the plugin under our org, treat upstream as a reference implementation, and accept patch responsibility. That converts an unmanaged external dependency into a small internal one. Assign a named owner regardless; an unowned admin-panel plugin sitting in the tenancy control plane is an unmanaged risk.

Support. Define the escalation path before adoption: who triages tenant-provisioning failures surfaced through the UI, and at what threshold we patch the fork versus wait upstream. Given the adoption level, assume upstream response is best-effort and plan for self-sufficiency. Our own changelog for the fork becomes the record of truth.

Scaling. Scaling risk is almost entirely inherited from stancl/tenancy and our database topology, not from this plugin — connection handling, per-tenant migration fan-out, and queue/tenancy bootstrapper behaviour. The plugin-specific scaling concerns are narrower but real: tenant list and search performance in the admin panel as tenant count grows into the thousands (unpaginated or unindexed queries are a common failure in scaffolded resources), and the cost of bulk operations like migrate-all-tenants triggered from a UI button, which should be queued rather than synchronous.

Failure modes. Plan detection signals for each:

• Partial provisioning — tenant row created, database or migrations not; needs an idempotent retry path and a visible status column, not a silent half-state.
• Filament upgrade breakage — caught by a compatibility CI lane that boots the panel and runs the plugin's own paths.
• Authorization drift — a policy regression exposes the tenant control plane; needs a test asserting non-privileged roles cannot reach it.
• Upstream abandonment — low severity given the fork option, but must be a decision made deliberately, not discovered.
• Removal residue — published config and migrations outliving the package; the uninstall test is the control.

Ramp-up. Small but non-zero and per-team: engineers need to learn where the plugin ends and stancl/tenancy begins, or they will debug tenancy problems in the wrong layer. Pair the spike with a short internal write-up — two pages on the seam, the fork policy, and the provisioning flow — so the knowledge outlives the branch. For a TPM the practical framing is that this package buys roughly days-to-weeks of Filament CRUD scaffolding at the price of a small, forked, internally owned dependency; that is a reasonable trade at this size, provided the ownership and fork policy are written down before the first commit rather than after the first incident.