Filament v5 + stancl/tenancy: the best of both, together

Two of our favorite tools in the Laravel ecosystem are Filament and stancl/tenancy. Both are excellent at what they do — and they do different things. We've built multi-tenant SaaS backends with each of them, and the happiest outcome we've found is using them together: Filament for the product experience, stancl/tenancy for the data architecture.

This post is a tour of when each one shines on its own, and what it takes to combine them into a database-per-tenant SaaS with a first-class panel experience.

Filament v5 tenancy: great ergonomics, right out of the box

Filament v5's built-in panel tenancy is genuinely impressive. Point a panel at a tenant model and you get an enormous amount for free:

• A tenant switcher in the navigation, with search.
• Tenant registration and profile pages — your "create organization" flow is a page class, not a week of routing work.
• Automatic scoping: Resource::scopeToTenant() constrains resource queries to the current tenant through an ownership relationship, so a user only ever sees their team's records.
• Tenant-aware routing, URLs, and middleware — the current tenant flows through everything, from navigation items to widgets.

When it's the right choice: team-based apps where tenants share one database — a team_id-style relationship on tenant-owned models — and that's most B2B SaaS at the start. Project tools, CRMs, internal platforms: one database, fast queries across all tenants, simple backups, simple analytics. If that's your product, Filament's tenancy is not a compromise; it's the pragmatic, well-designed default, and you should use it happily.

stancl/tenancy v4: real isolation, engineered properly

stancl/tenancy is the de facto standard for multi-database tenancy in Laravel, and v4 is the best version of it yet. Its superpower is the thing shared-database tenancy can't give you: each tenant gets their own database.

The engine handles the genuinely hard parts:

• Bootstrappers swap the database connection, cache prefix, filesystem roots, and queue context the moment a tenant is initialized — Model::all() inside tenant context transparently hits that tenant's database.
• Identification resolvers for domains, subdomains, and paths.
• A provisioning pipeline — TenantCreated fires jobs like CreateDatabase and MigrateDatabase through your queue.
• Per-tenant database config — each tenant can carry its own connection, credentials, even its own server.

When it's the right choice: the moment isolation becomes part of the product. An enterprise security questionnaire asks "is our data in a separate database?" — and you get to answer yes. A procurement contract has data-residency language — and you can put that tenant's database on an EU server, physically. A big customer wants their own backup and restore cadence — it's just their database. These are conversations where database-per-tenant turns a hard negotiation into a checkbox.

Better together

Here's the thing: these two strengths aren't in competition. Filament is the best way to build the product — the panels, the resources, the forms, the tenant switcher your users touch every day. stancl/tenancy is the best way to architect the data — one clean database per customer, provisioned on demand, placed wherever it needs to live.

Combine them and you get a SaaS where the enterprise prospect hears "yes, fully isolated" and your team ships features at Filament speed. The user experience doesn't change — same panel, same switcher, same flows — but underneath, every organization lives in its own database.

The two frameworks weren't designed with each other in mind, though, so bridging them means wiring up a real integration layer: identification that respects both routing systems, sessions that work across subdomains and custom domains, keeping central and tenant writes on the right connections, and a good user experience during those seconds while a new tenant's database is being created. It's all very buildable — we know because we built it — and it's exactly the kind of work that's better solved once, properly, than re-derived by every team.

That's what our plugin does.

Packstub Tenancy: the bridge, done right

Packstub Tenancy is a commercial Filament v5 plugin that connects the two. Everything below ships working out of the box:

Identification with zero middleware wiring. Subdomain, custom domain, or path identification, wired into Filament's panel routing so both systems agree on who the tenant is. In path mode, Filament resolves the tenant and the plugin bridges it into stancl via the TenantSet event — one source of truth, no duplicate resolution.

Sessions that just work. Sessions and auth stay central — so logins survive Livewire round-trips — while tenant data lives in tenant databases, which is where the isolation actually matters. For custom domains, the plugin includes the single-origin login handoff pattern (the same approach used by Clerk's satellite domains, Shopify, and Auth0): login happens on your central domain, and identity crosses to app.customer-domain.com via a short-lived, single-use code with replay protection built in.

Custom domains, verified. Tenants can bring their own domain, with DNS ownership verification before it goes live and the login handoff ready on day one.

Async provisioning with a friendly waiting room. New tenant databases are created and migrated through your queue. Meanwhile the user lands on a Livewire-polled waiting room that redirects the moment their workspace is ready — with a "taking longer than usual" hint and a retry path if a job fails. And the plugin is careful about the details: ready-first default-tenant selection, a ready-only tenant switcher, and a middleware gate so a half-provisioned tenant is never one click away from a broken page.

Central ⇄ tenant syncing. Some data lives in both worlds — the tenant record itself, user profiles, plan limits. The plugin syncs resources across the boundary, bidirectionally and queueably, so you don't hand-roll cross-database consistency.

A load-balanced database pool. Our favorite part. As you grow, tenant databases spread across multiple database servers — least-tenants, round-robin, or weighted placement, persisted per tenant. Adding capacity is one connection definition and one line of config. And for that data-residency customer: pin their tenant to a specific server, and the pin always wins over the pool.

You can watch the pool from inside the panel (above) or from the terminal — php artisan tenants:pool shows placement strategy and per-server tenant counts, and --check verifies every server is reachable and can create databases:

All of it is backed by 300+ tests, including an end-to-end suite that provisions tenants across three real PostgreSQL servers.

Start with what fits, grow into both

If you're building team-based SaaS and shared-database tenancy fits, use Filament's built-in tenancy with our blessing — it's excellent. If you're at the stage where customers ask about isolation, residency, or their own database, that's when stancl/tenancy earns its place — and the bridge between it and your Filament panels is a solved problem.

Packstub Tenancy is in early access now, with launch pricing on the page: packstub.dev/tenancy.

We'd love to hear what you're building — and what would make or break this for your stack.