Next.js edge middleware resolves tenant context from custom domains or subdomains before routing, injecting tenant_id into all downstream requests. Supabase PostgreSQL with row-level security policies enforces data isolation at the database layer, while tenant branding configuration is stored as JSON and applied via server-side rendered CSS custom properties. Stripe Connect handles multi-party billing with automated revenue splits between platform owner and reseller.
Where enterprise projects fail
Cross-tenant data leakage happens when your application relies on filtering logic in the app layer to keep tenant data separated. Sounds fine in theory. But application code has bugs. ORMs have quirks. A single misconfigured query, a missing WHERE clause, a junior dev who didn't realize the context wasn't set -- and suddenly Tenant A is reading Tenant B's customer records. That's not a hypothetical. It happens in production. And when it does, you're looking at a genuine security breach, exposed customer PII, potential GDPR or HIPAA violations depending on your industry, and the kind of trust collapse that kills reseller programs overnight. Chicago-based resellers don't stick around after their end-customers get a breach notification email. Database-enforced isolation -- meaning actual PostgreSQL row-level security policies -- is the only architecture that holds up under real pressure. Application-layer filtering alone isn't enough. Full stop.
We've seen platforms where onboarding one reseller client takes 2-3 days of back-and-forth with DevOps. That's brutal. And the real kicker is it creates a hard ceiling on growth -- you physically can't onboard more than a handful of tenants per week without dedicated engineering time just for SSL setup. So your sales team closes deals and then... everyone waits. Automating custom domain SSL provisioning programmatically during onboarding isn't just a nice-to-have. It's what separates a platform that scales from one that stalls out at 15 tenants.
What they don't expect is filing a ticket and waiting for a code deploy to see a hex color change go live. But that's exactly what happens when branding is baked into the codebase rather than stored as configuration. Honestly, this is one of the fastest ways to lose reseller relationships. Engineering gets buried in a queue of "can you update our primary button color" requests while actual product work sits untouched. Sales closes a new reseller, promises quick turnaround on white-labeling, and then the ops team is scrambling. Competitors who've solved this -- where branding changes are instant, no deploy required -- will absolutely poach your resellers over it.
You've got Reseller A who gets 30% of each tenant subscription, Reseller B on a different tier, some tenants on monthly plans, others annual -- and someone's tracking this in a spreadsheet? Errors are inevitable. Revenue recognition gets delayed. Resellers notice when their splits are off, and they stop trusting the platform. And when you try to grow the reseller program from 10 partners to 50, the whole thing collapses under its own weight. A proper billing system -- Stripe Connect with automated splits, per-tenant subscription management, real-time revenue tracking -- isn't optional at scale. It's foundational.
What we deliver
What White-Label Multi-Tenant Platforms Actually Require
A white-label platform isn't a theme switcher bolted onto a monolith. It's a full multi-tenant architecture where every tenant gets their own branded experience, their own custom domain, their own isolated data—and your client (the reseller) gets a super-admin dashboard to manage all of it.
We build these on Next.js and Supabase. That combination gets us server-side rendering for tenant-aware routing, PostgreSQL row-level security for data isolation that actually holds up, and edge middleware that resolves tenant context before a single component renders. Every tenant thinks they're on their own platform. Under the hood, it's one codebase, one deployment, one infrastructure bill.
This is what agencies, vertical SaaS companies, and platform businesses need when they want to sell software under their customers' brands.
Why In-House Teams Hit the Wall
Multi-tenant white-label development looks straightforward—until you're three months in and realize your data model leaks between tenants, your custom domain SSL provisioning doesn't scale, and your branding system requires a deploy for every new customer.
Here's what we see repeatedly:
Tenant isolation failures
Most teams start with a tenant_id column and call it done. Without rigorous row-level security policies enforced at the database layer—not the application layer—you're one ORM bug away from a cross-tenant data breach. We've audited platforms where a missing WHERE clause exposed 40,000 records to the wrong tenant. One missing filter. Forty thousand records.
Custom domain complexity
Every tenant wants app.theirbrand.com. That means automated SSL certificate provisioning, DNS verification flows, wildcard fallbacks, and middleware that resolves the correct tenant from any incoming hostname. Vercel's custom domain API handles this at scale, but wiring it into a tenant provisioning pipeline with proper error handling and retry logic is genuinely painful to get right.
Branding that doesn't require deploys
Per-tenant branding means logos, color palettes, typography, email templates, and sometimes entirely different navigation structures—all driven by configuration, not code. Teams that hardcode branding into build-time config create a deployment bottleneck that kills their ability to onboard tenants quickly. You can't be waiting on CI pipelines every time a customer wants to change their accent color.
Reseller admin tooling
The reseller needs to onboard tenants, manage subscriptions, view cross-tenant analytics, and control feature flags—without touching code or filing support tickets. Building this admin layer properly often takes as long as the tenant-facing application itself. Most teams underestimate it badly.
Our Architecture: Next.js + Supabase Multi-Tenant Stack
We've refined this pattern across multiple production platforms. Here's how the pieces fit together.
Tenant Resolution at the Edge
Next.js middleware runs on every request before routing. We parse the incoming hostname, match it against a tenant lookup table cached at the edge, and inject the tenant context into request headers. The entire application—from page rendering to API routes—knows which tenant it's serving without any client-side logic.
middleware.ts → parse hostname → edge cache lookup → inject tenant_id header → route
For custom domains, we use Vercel's Domains API to programmatically add and verify tenant domains. SSL provisioning is automatic. For development and staging, we fall back to subdomain-based resolution (tenant.platform.com).
Data Isolation with Supabase RLS
Every table that contains tenant-scoped data has a row-level security policy:
CREATE POLICY tenant_isolation ON orders
USING (tenant_id = current_setting('app.current_tenant_id')::uuid);
The tenant context gets set at the beginning of every database session via a Supabase Edge Function or PostgREST header. This is enforced at the PostgreSQL level—no application code can bypass it. Even if a developer forgets a filter, the database refuses to return rows from other tenants.
For tenants requiring physical isolation (regulated industries, enterprise contracts), we provision dedicated Supabase projects with automated schema migrations synced from the primary codebase.
Dynamic Branding System
Tenant branding lives as a JSON configuration in Supabase and resolves during server-side rendering. We generate CSS custom properties from the tenant's brand config and inject them into the document head. Zero client-side flash, instant brand-correct rendering, no build step required.
{
"primary_color": "#1a2b3c",
"logo_url": "https://cdn.platform.com/tenants/acme/logo.svg",
"font_family": "Inter",
"nav_items": ["Dashboard", "Reports", "Settings"]
}
New tenants go from signup to fully branded, live platform in under 60 seconds.
Reseller Super-Admin Dashboard
The reseller gets a dedicated admin application (also Next.js) with:
- Tenant provisioning: Create new tenants, assign plans, configure feature flags
- Billing integration: Stripe Connect for per-tenant subscription management with automated revenue splitting
- Cross-tenant analytics: Aggregated usage metrics, churn indicators, and revenue dashboards
- White-label email: Tenant-branded transactional emails via Resend or Postmark with per-tenant DKIM/SPF
- Feature flag management: Toggle capabilities per tenant or per plan tier without deploys
Authentication Per Tenant
Supabase Auth handles tenant-scoped authentication. Each tenant can have its own auth providers (Google, SAML, email/password), its own password policies, and its own user management—all within a single Supabase project using custom claims and RLS.
For enterprise tenants requiring SSO, we integrate SAML 2.0 via Supabase's auth hooks, mapping IdP attributes to tenant-scoped roles.
Technology Stack
This architecture relies on specific, battle-tested components:
- Next.js 14+ (App Router): Server components for tenant-aware SSR, middleware for edge resolution, API routes for tenant provisioning
- Supabase: PostgreSQL with RLS for data isolation, Edge Functions for tenant provisioning automation, Realtime for live tenant dashboards
- Vercel: Hosting with custom domain API, edge middleware, preview deployments per tenant configuration
- Stripe Connect: Multi-party billing, per-tenant subscriptions, reseller revenue splits
- Tailwind CSS: Dynamic theming via CSS custom properties generated from tenant config
- Resend/Postmark: Tenant-branded transactional email with per-tenant sender domains
- Turborepo: Monorepo management for shared packages across tenant app, admin app, and provisioning services
Proven at Scale
These patterns aren't theoretical. We've applied tenant isolation, dynamic content resolution, and per-entity branding across production platforms handling serious volume.
Our directory platform manages 137,000+ listings with entity-specific data scoping and dynamic page generation—the same architectural pattern that drives tenant isolation in white-label platforms. Our content platform serves 91,000+ dynamically generated pages from a headless CMS, which proved out our server-side rendering pipeline for high-volume, configuration-driven content delivery. Our internationalization work across 30 languages for a Korean manufacturer shows we can manage per-entity configuration at global scale.
The auction platform we built processes bids at sub-200ms latency with real-time data synchronization—that's the same Supabase Realtime infrastructure powering live tenant dashboards and cross-tenant analytics in white-label platforms.
Every project ships with Lighthouse scores of 95+, regardless of tenant count or branding complexity.
Delivery Model
White-label platform projects follow a phased approach:
Phase 1 (Weeks 1-3): Core multi-tenant architecture—tenant resolution, RLS policies, branding system, basic admin dashboard. You'll have a working platform with 3-5 test tenants.
Phase 2 (Weeks 4-6): Reseller tooling—billing integration, provisioning automation, analytics dashboards, custom domain management.
Phase 3 (Weeks 7-9): Hardening—security audit, load testing across 100+ simulated tenants, compliance review, documentation for reseller onboarding.
Phase 4 (Weeks 10-12): Launch support—production deployment, first 10 real tenants onboarded, monitoring and alerting configured.
Post-launch, we offer retained support for tenant-specific customization, scaling optimization, and feature development on a monthly retainer.
Every phase includes architecture documentation, security review, and performance benchmarks. You own the code, the infrastructure, and the relationship with your tenants.
See this capability in action
Frequently asked
How do you isolate tenant data in a multi-tenant architecture?
We use PostgreSQL row-level security policies enforced at the database layer through Supabase. Every query gets scoped to the current tenant using session-level configuration variables that get set at connection time. So even when application code has a bug -- and eventually it will -- the database itself refuses to return rows belonging to other tenants. It's not a safety net you can accidentally code around. And unlike application-layer filtering, there's no way for a rogue query or ORM quirk to bypass it. For regulated industries like healthcare or fintech, we can go further and provision physically separate Supabase projects per tenant, giving you full database-level isolation if compliance requires it.
How do custom domains work for each tenant?
We wire Vercel's Domains API directly into the tenant provisioning flow, so custom domain verification and SSL certificate setup happen automatically -- no manual steps, no DevOps intervention. Next.js edge middleware then resolves the incoming hostname to the right tenant configuration before any page renders, so branding and data scope are correct from the first byte. On the tenant's side, the only thing they need to do is add a CNAME record to their DNS provider. That's it. Everything else is handled programmatically, and they're live in under 60 seconds.
Can each tenant have completely different branding and UI?
Yes, and this is one of the parts we're most deliberate about. Tenant branding -- colors, logos, fonts, navigation structure, email templates -- lives as configuration data in Supabase, not as code. At render time, we pull that configuration server-side and apply it via CSS custom properties, so the right branding is baked into the page before it ever hits the browser. No rebuild, no redeploy, no ticket queue. A reseller updates their logo and it's live immediately. We can handle anything from simple color palette swaps to entirely different navigation layouts and email template structures per tenant.
How many tenants can this architecture support?
The architecture handles thousands of tenants on a single codebase and a single Vercel deployment. Edge middleware tenant resolution adds negligible latency -- we're talking low single-digit milliseconds in practice. Supabase's connection pooling through Supavisor manages concurrent tenant database sessions without connection exhaustion, which is the silent killer on multi-tenant platforms at scale. We've stress-tested with 100+ simultaneous tenants and consistently hit sub-200ms response times. And for any tenant that needs it -- enterprise clients, regulated industries, high-volume accounts -- physical database separation is available without restructuring the rest of the platform.
What does the reseller admin dashboard include?
The super-admin dashboard is a full standalone Next.js application with role-based access control. It's not a bolt-on settings page. Resellers can provision new tenants themselves, manage subscription plans through Stripe Connect with automated revenue splitting, configure per-tenant feature flags, view cross-tenant analytics and usage metrics, manage custom domains, and control white-label email sender domains. Platform admins see everything across all resellers. Resellers see only their own tenants. It's built for the operational reality of a multi-reseller business -- the kind of tooling where your support team can actually get work done without filing engineering tickets for every change.
How long does it take to build a white-label multi-tenant platform?
A production-ready white-label platform typically runs 10-12 weeks across four phases. First three weeks: core multi-tenant architecture -- middleware, RLS policies, branding system, auth. Weeks 4-6: reseller tooling, Stripe Connect billing, the admin dashboard. Weeks 7-9: security hardening, load testing, edge case coverage. Final three weeks: launch support with real tenant onboarding, fixing the things you only discover when actual resellers start poking around. By the end of week 3, you'll have a working prototype with test tenants running -- not mockups, actual working multi-tenant infrastructure you can demo to resellers.
Do we own the code and infrastructure?
Yes, completely -- and this matters more than most clients initially realize. You own the Git repository, the Supabase project, the Vercel deployment, and every byte of tenant data. We hand everything over with full documentation: architecture decisions, environment setup, deployment procedures, the works. There's no vendor lock-in to us. Your engineering team can maintain, extend, and scale the platform without us involved at all. Post-launch, we do offer optional retained support if you want ongoing development help -- but that's your call, not a requirement.
Browse all 15 enterprise capability tracks or compare with our SME-scale industry solutions.
Schedule Discovery Session
We map your platform architecture, surface non-obvious risks, and give you a realistic scope — free, no commitment.
Schedule Discovery Call
Let's build
something together.
Whether it's a migration, a new build, or an SEO challenge — the Social Animal team would love to hear from you.