Best Boilerplate with Multi-Tenancy 2026

Multi-Tenancy: Build It In or Bolt It On?

Multi-tenancy is the difference between a tool for individuals and a platform for teams. It's also one of the hardest features to retrofit into an existing application.

When users belong to organizations, everything changes: data isolation, billing, permissions, invitations, workspace switching. Get it wrong and you leak data between tenants. Get it right and your SaaS scales from 1 user to 1,000 organizations without architectural changes.

Three boilerplates take multi-tenancy seriously from day one: Supastarter, Volca, and Bedrock. Each approaches the problem differently.

TL;DR

Supastarter ($299-$349) has the most complete multi-tenancy with organizations, member management, RBAC, per-org billing, and workspace switching — supporting both Next.js and Nuxt. Volca ($149-$399) focuses on multi-tenant project workspaces with clean data isolation. Bedrock ($395-$995) targets enterprise with advanced RBAC, audit logs, and SOC 2 compliance patterns. Choose Supastarter for the best all-around multi-tenancy. Choose Bedrock for enterprise compliance.

Key Takeaways

All three handle the basics — organizations, member invites, data scoping. The differences are in depth and edge cases.
Supastarter's multi-tenancy is the most complete — org switching, per-org billing, RBAC, invitations with role assignment, and a clean tenant context throughout the app.
Bedrock targets enterprise with audit logs, SOC 2 patterns, and granular permissions. If compliance matters, Bedrock is the choice.
Volca uses a "project" model instead of "organizations" — similar concept, different UX (think Vercel's project-based navigation).
Data isolation approach matters. All three use row-level isolation (shared database, filtered queries). None uses schema-level or database-level isolation.
Adding multi-tenancy later is painful. Every database query needs tenant scoping. Every route needs org context. Every permission check needs org awareness. Start with it.

Multi-Tenancy Architecture

Data Isolation Approaches

All three boilerplates use shared database with row-level isolation:

┌─────────────────────────────────┐
│     Shared PostgreSQL Database   │
│  ┌─────────┬─────────┬────────┐ │
│  │ Org A   │ Org B   │ Org C  │ │
│  │ data    │ data    │ data   │ │
│  │ (org_id │ (org_id │ (org_id│ │
│  │  = 1)   │  = 2)   │  = 3) │ │
│  └─────────┴─────────┴────────┘ │
└─────────────────────────────────┘

Every table that stores tenant data has an org_id column. Every query filters by the current tenant's ID. This is the most common approach for SaaS because it's simple to manage and scales well.

The risk: A missing WHERE org_id = ? clause leaks data between tenants. The boilerplates mitigate this differently:

Supastarter: Middleware sets the tenant context. All database queries use Prisma's where clause with the current org ID.
Volca: Project-scoped middleware filters all queries through the current project context.
Bedrock: Uses Prisma middleware to automatically add org_id filtering to every query — harder to accidentally bypass.

Organization Model Comparison

Feature	Supastarter	Volca	Bedrock
Entity name	Organization	Project	Team/Organization
URL pattern	`/org/{slug}/...`	`/project/{id}/...`	`/team/{slug}/...`
Workspace switching	✅ Dropdown	✅ Dropdown	✅ Dropdown
Personal workspace	✅ Default org	⚠️ Optional	✅ Default team
Nested orgs	❌	❌	❌
Org-level settings	✅ Full	✅ Basic	✅ Full
Custom domains	❌	❌	⚠️ Manual
Org creation limit	✅ Configurable	✅ Plan-based	✅ Configurable

Member Management

Feature	Supastarter	Volca	Bedrock
Email invitations	✅ With role	✅ Basic	✅ With role
Invite links	✅	❌	✅
Pending invites list	✅	✅	✅
Revoke invitation	✅	✅	✅
Member removal	✅	✅	✅
Role assignment	✅ Multiple roles	⚠️ Basic roles	✅ Granular
Transfer ownership	✅	❌	✅
Member limit per org	✅ Plan-based	✅ Plan-based	✅ Plan-based

Role-Based Access Control (RBAC)

Feature	Supastarter	Volca	Bedrock
Default roles	Owner, Admin, Member	Owner, Member	Owner, Admin, Member, Viewer
Custom roles	⚠️ Code-defined	❌	✅ Admin-defined
Permission granularity	Feature-level	Role-level	Action-level
UI permission guards	✅ Components	✅ Basic	✅ Components + hooks
API permission guards	✅ Middleware	✅ Middleware	✅ Middleware + decorators
Audit logs	❌	❌	✅ Built-in

Bedrock's RBAC is the most sophisticated. Permissions are action-level (e.g., project:create, member:invite, billing:manage), and custom roles can be created by team admins through the UI. Audit logs track who did what, when — critical for enterprise compliance.

Supastarter's RBAC is practical for most B2B SaaS. Feature-level permissions (can this role access billing? Can they manage members?) cover 90% of use cases without the complexity of action-level granularity.

Billing in Multi-Tenant Context

Feature	Supastarter	Volca	Bedrock
Per-org billing	✅	✅	✅
Per-user billing	✅	❌	✅
Per-seat pricing	✅ Auto-count	❌	✅ Auto-count
Org plan limits	✅ Members, features	✅ Projects, storage	✅ Members, features, usage
Free tier per org	✅	✅	✅
Trial per org	✅	✅	✅
Billing admin role	✅	❌ (owner only)	✅

The key question: who pays — the user or the organization?

Per-user billing (Slack model): Each user has their own subscription. Simpler but limits team features.
Per-org billing (GitHub model): The organization subscribes. Members are added/removed. The subscription quantity adjusts.
Per-seat billing (Atlassian model): The organization pays per active member. Adding a team member automatically increases the bill.

Supastarter and Bedrock support all three models. Volca supports per-org billing only.

Implementation Quality

Data Isolation Testing

Test	Supastarter	Volca	Bedrock
Cross-tenant query protection	✅ Middleware	✅ Middleware	✅ Prisma middleware
API endpoint isolation tests	⚠️ Manual	⚠️ Manual	✅ Automated
Webhook tenant resolution	✅	✅	✅
File upload isolation	⚠️ Manual path scoping	⚠️ Manual	✅ Tenant-scoped buckets
Search isolation	✅ Scoped	✅ Scoped	✅ Scoped

Bedrock's automated cross-tenant testing is notable. Test suites verify that User A in Org A cannot access Org B's data through any API endpoint. This is the kind of security testing that enterprise customers audit for.

Migration from Single-Tenant

If your boilerplate doesn't include multi-tenancy, adding it later requires:

Adding org_id to every tenant-scoped table (migration)
Backfilling org_id for existing data (data migration)
Adding WHERE org_id = ? to every query (code changes across entire codebase)
Adding org context to every route (middleware)
Building the invitation/member management UI (new feature)
Updating billing to support per-org subscriptions (billing refactor)
Testing for data leakage across every endpoint (security audit)

Estimated time: 3-6 weeks for a moderately complex SaaS. This is why starting with multi-tenancy matters.

Pricing

Boilerplate	Price	Multi-tenancy tier
Supastarter	$299-$349 (one-time)	All tiers
Volca	$149-$399 (one-time)	All tiers
Bedrock	$395-$995 (one-time)	All tiers

Bedrock is the most expensive but includes enterprise features (audit logs, compliance patterns) that the others don't. Volca is cheapest but has the simplest multi-tenancy. Supastarter offers the best value — comprehensive multi-tenancy at a mid-range price.

When to Choose Each

Choose Supastarter If:

You need solid multi-tenancy without enterprise complexity — org management, RBAC, per-org billing
Multi-framework support matters — Next.js and Nuxt variants available
Per-seat billing is important — automatic seat counting and subscription adjustments
You want the broadest feature set — billing, i18n, email, waitlist, onboarding + multi-tenancy

Choose Volca If:

Budget is tight ($149 entry price)
"Project" model fits your product — Vercel-style project switching vs Slack-style org management
Simplicity is preferred — fewer features, less complexity
You're building project-management or workspace-style SaaS

Choose Bedrock If:

Enterprise compliance matters — SOC 2 patterns, audit logs, granular permissions
You're selling to large organizations who require security audits
Custom roles are needed — admin-defined roles with action-level permissions
You want automated security testing — cross-tenant isolation tests built-in

The Risk of Retrofitting Multi-Tenancy

The most common failure pattern: build for individual users, gain traction, then try to add teams. The database migration alone touches dozens of tables. Every SQL query needs org_id filtering added. Every route handler needs the current organization extracted from the session. Every auth check needs organization awareness. Every third-party webhook needs to resolve to the correct tenant.

The 3-6 week estimate in the migration section above assumes an experienced full-stack engineer with prior multi-tenancy work. For a solo founder or a small team without that background, the realistic timeline is often 2-3 months — during which shipping velocity drops to near zero, support requests accumulate, and planned features stall.

The three boilerplates here (Supastarter, Volca, Bedrock) encode patterns you would otherwise spend months discovering: how to scope Prisma queries with organization context, how to structure invitation workflows, how to wire per-organization billing in Stripe, how to build a workspace switcher that works reliably. Starting with the right foundation is not just about speed — it's about building the architecture that enterprise customers expect when they ask about "team accounts," "SSO," and "audit logs."

Evaluating Multi-Tenancy Implementation Quality

Not all boilerplate multi-tenancy implementations are equal. The architectural quality of the implementation determines how much work you'll do when you hit edge cases. Key evaluation criteria:

Data isolation model. The strongest isolation is database-level: Supabase Row Level Security enforces that every database query automatically filters by the authenticated user's organizations, without the application needing to add WHERE clauses manually. Application-level isolation (Prisma middleware that adds organizationId filters) is almost as strong but depends on the application never forgetting to apply the filter. Shared database with application-level filtering is the most common pattern and works well when implemented consistently — the risk is developer error introducing a query that skips the organization filter.

Invitation and membership workflow completeness. Multi-tenancy isn't just data isolation — it's the complete workflow of inviting users, accepting invitations, managing roles, and removing members. An incomplete implementation might handle the happy path but miss: what happens when an invited user already has an account with a different email, when an invitation expires, when the last admin of an organization tries to downgrade themselves, or when a user is removed but has pending items owned under their user ID. Supastarter and Bedrock have the most complete implementations of these edge cases; newer boilerplates often have gaps that require custom development.

Billing integration. Multi-tenant billing requires Stripe subscriptions at the organization level, not the user level. The billing portal must be accessible to organization admins (not all members), seat counting must update when members are added or removed, and plan limits must be enforced organization-wide, not per-user. This Stripe-organization coupling is complex to implement correctly from scratch — it's one of the areas where starting with a boilerplate that has it right saves the most time.

The multi-tenancy decision is foundational — it shapes your database schema, billing model, auth system, and access control from day one. Starting with a boilerplate that has multi-tenancy built correctly is significantly faster than retrofitting it onto an architecture that assumed single-user access. The three boilerplates reviewed here (Supastarter, Volca, Bedrock) each make different trade-offs in how they model organizations, and understanding those trade-offs is worth the time investment before you commit to a foundation.

Compare multi-tenancy boilerplates in our best open-source SaaS boilerplates guide.

See the data model patterns in our multi-tenancy patterns for SaaS guide.

Review Supastarter in detail in our Supastarter review.

Teams that build multi-tenant SaaS from a solid foundation ship team features faster and with fewer regressions than those who retrofit. Choose the right architecture from the first commit.

The SaaS Boilerplate Matrix (Free PDF)