DEV Community: Konstantin

How I built subdomain-based multi-tenancy with Next.js 14, Supabase RLS, and Cloudflare — for free

Konstantin — Wed, 06 May 2026 11:13:58 +0000

Multi-tenancy is one of those things that sounds simple until you're three hours deep into middleware, wildcard DNS, and Row Level Security policies wondering where it all went wrong.

I built it for Pronto — an open-source POS, CRM, and booking system for service businesses. Every business that signs up gets their own subdomain: salon-maya.trypronto.app. Fully isolated. One codebase.

Here's exactly how I did it, what broke, and what I'd do differently.

The architecture in one diagram

Client request: salon-maya.trypronto.app
        ↓
Cloudflare (wildcard *.trypronto.app → DigitalOcean)
        ↓
Next.js Middleware (extract slug from hostname)
        ↓
Supabase RLS (row-level isolation per business_id)
        ↓
Tenant data

Three layers. Each one solves a different problem.

Layer 1: Cloudflare wildcard DNS

This is the easiest part. In your Cloudflare dashboard, add one DNS record:

Type: A
Name: *
Content: your-server-ip
Proxy: ✅ (orange cloud)

One record handles every subdomain. salon-maya, barbershop-joe, cafe-lima — all routed to the same server automatically.

Then enable Universal SSL and make sure it covers wildcard *.yourdomain.com. Cloudflare's free plan does this.

That's it for DNS. Cost: $0.

Layer 2: Next.js Middleware — extracting the tenant

Every request needs to know which tenant it belongs to. Middleware runs before any page renders, which makes it the right place for this.

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'

export function middleware(request: NextRequest) {
  const hostname = request.headers.get('host') || ''
  const baseDomain = process.env.NEXT_PUBLIC_BASE_DOMAIN || 'trypronto.app'

  // salon-maya.trypronto.app → slug = "salon-maya"
  const slug = hostname.replace(`.${baseDomain}`, '')

  // Skip if it's the root domain
  if (slug === baseDomain || slug === 'www') {
    return NextResponse.next()
  }

  // Pass slug to the request via header
  const requestHeaders = new Headers(request.headers)
  requestHeaders.set('x-tenant-slug', slug)

  return NextResponse.next({
    request: { headers: requestHeaders }
  })
}

export const config = {
  matcher: ['/((?!api|_next/static|_next/image|favicon.ico).*)'],
}

Then in any Server Component or API route, read it back:

import { headers } from 'next/headers'

export default async function Page() {
  const headersList = headers()
  const slug = headersList.get('x-tenant-slug')

  const business = await getBusinessBySlug(slug)
  // ...
}

Layer 3: Supabase RLS — the real isolation

Passing a slug through headers is fine for routing, but if your database queries don't enforce tenant isolation at the DB level, you have a security problem.

Supabase Row Level Security fixes this.

Every tenant table has a business_id column:

create table businesses (
  id uuid primary key default gen_random_uuid(),
  slug text unique not null,
  name text not null,
  owner_id uuid references auth.users(id)
);

create table appointments (
  id uuid primary key default gen_random_uuid(),
  business_id uuid references businesses(id) not null,
  client_name text,
  starts_at timestamptz
);

Enable RLS and add a policy:

alter table appointments enable row level security;

create policy "appointments_business_isolation"
  on appointments
  using (
    business_id = (
      select id from businesses 
      where owner_id = auth.uid()
    )
  );

Now it's physically impossible for one tenant to read another tenant's data, even if there's a bug in your application layer.

Migration files — keep it simple:

I use numbered SQL files (001_initial.sql, 002_add_rls.sql) and a Node script that applies them in order on startup. No ORM magic — just SQL tracked in git.

// scripts/migrate.js
const migrations = await fs.readdir('./supabase/migrations')
const sorted = migrations.sort() // 001_, 002_, etc.

for (const file of sorted) {
  // Check if already applied, skip if so
  // Execute if new
}

The onboarding flow

When a new business registers, they pick their slug:

What's your business URL?
[ salon-maya ] .trypronto.app

On submit:

// Validate slug is URL-safe and available
const slug = input.toLowerCase().replace(/[^a-z0-9-]/g, '')

const existing = await supabase
  .from('businesses')
  .select('id')
  .eq('slug', slug)
  .single()

if (existing.data) {
  return { error: 'This URL is already taken' }
}

// Create the business record
const { data: business } = await supabase
  .from('businesses')
  .insert({ slug, name: businessName, owner_id: userId })
  .select()
  .single()

// Redirect to their new subdomain
redirect(`https://${slug}.trypronto.app/onboarding`)

No DNS configuration needed on the customer's side. The wildcard handles it instantly.

What broke (and how I fixed it)

Problem 1: Cookies don't cross subdomains by default.

salon-maya.trypronto.app and trypronto.app are different origins. A session cookie set on the root domain won't be readable on the subdomain.

Fix — set the cookie domain with a leading dot:

response.cookies.set('sb-token', token, {
  domain: '.trypronto.app', // note the leading dot
  httpOnly: true,
  secure: true,
  sameSite: 'lax'
})

Problem 2: Middleware fired on static assets.

Without the matcher config, middleware runs on every _next/static/... request and adds latency to every image and JS chunk. The matcher I showed above fixes this.

Problem 3: Double-booking at the application layer.

Two concurrent requests could both pass the "is this slot free?" check before either wrote to the database. Fixed with a PostgreSQL trigger:

create or replace function prevent_double_booking()
returns trigger as $$
begin
  if exists (
    select 1 from appointments
    where business_id = NEW.business_id
      and employee_id IS NOT DISTINCT FROM NEW.employee_id
      and status != 'cancelled'
      and tstzrange(starts_at, ends_at) && tstzrange(NEW.starts_at, NEW.ends_at)
      and id != NEW.id
  ) then
    raise exception 'SLOT_CONFLICT' using errcode = 'P0001';
  end if;
  return NEW;
end;
$$ language plpgsql;

The API returns HTTP 409 on conflict. No race condition possible.

Custom domains (bonus)

For customers who want booking.their-salon.com instead of a subdomain, Cloudflare for SaaS handles this. The first 100 custom domains are free.

The customer adds a CNAME pointing to your domain, you verify ownership, Cloudflare provisions the SSL certificate automatically. From your app's perspective, it's the same middleware pattern — just match on the full hostname instead of extracting a slug.

The full cost breakdown

Layer	Tool	Cost
Wildcard DNS + SSL	Cloudflare	$0
Subdomain routing	Next.js middleware	$0
Tenant isolation	Supabase RLS	$0
Custom domains	Cloudflare for SaaS	$0 (first 100)
Hosting	DigitalOcean	~$20/mo

The entire multi-tenancy infrastructure costs $20/month — just the server.

The code is open source

Pronto is MIT-licensed. If you're building something similar — a SaaS for service businesses, a booking system, anything with subdomain tenancy — the full implementation is there to read.

⭐ github.com/SGrappelli/pronto

Live demo: trypronto.app

Questions about any layer? Drop them in the comments.

How I built an open-source POS with Telegram, WhatsApp & Viber — one Docker command install

Konstantin — Wed, 29 Apr 2026 12:42:36 +0000

A friend of mine runs a beauty salon. Every evening she manually texts appointment reminders to her clients. She tracks inventory in Excel. And she pays 20% commission to a booking platform — for clients she spent years building relationships with herself.
So I built Pronto: an open-source POS, CRM, booking system, inventory tracker, and omnichannel notification engine for service businesses. Self-hosted or cloud. Zero commission. One command to install.
This post is about the technical decisions that were actually hard.

The architecture in one paragraph

Next.js 14 API routes + Supabase (PostgreSQL + Auth) + Cloudflare R2 for file storage. Notifications via Resend/SMTP, Telegram Bot API, Meta WhatsApp Cloud API, and Viber Bot API. Docker Compose for self-hosting. PWA via next-pwa for offline POS. Multitenancy via Supabase Row Level Security.
Credential model: each self-hoster (or SaaS tenant) brings their own API keys — Telegram bot token, WhatsApp Phone Number ID + Access Token, Viber token. The platform owner pays nothing to the messenger providers.

Problem 1: The double-booking race condition

App-level booking conflict checks have a classic race condition. Two clients simultaneously pick the same slot → both pass the check → both get confirmed.
The fix: a PostgreSQL trigger that runs atomically at commit time.

CREATE OR REPLACE FUNCTION check_booking_conflict()
RETURNS TRIGGER AS $$
BEGIN
  IF EXISTS (
    SELECT 1 FROM bookings
    WHERE business_id = NEW.business_id
      AND employee_id IS NOT DISTINCT FROM NEW.employee_id
      AND status NOT IN ('cancelled', 'no_show')
      AND (NEW.start_time, NEW.end_time) OVERLAPS (start_time, end_time)
      AND id != NEW.id
  ) THEN
    RAISE EXCEPTION 'Booking conflict: slot already taken';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

IS NOT DISTINCT FROM handles the NULL case — when employee_id is NULL (group bookings), it still works correctly. The API returns HTTP 409 on conflict, and the UI refreshes the slot grid automatically.

Problem 2: Docker broke auth callbacks

The app worked perfectly locally. Inside a Docker container, Supabase auth redirected back to http://0.0.0.0:3000/auth/callback — because request.url resolves to the container's internal address, not the real hostname.
The fix: read NEXT_PUBLIC_SITE_URL explicitly instead of deriving origin from the request.

const siteUrl = process.env.NEXT_PUBLIC_SITE_URL || 'http://localhost:3000'
const { data, error } = await supabase.auth.exchangeCodeForSession(code)
return NextResponse.redirect(`${siteUrl}/dashboard`)

This made the install truly one-command — no post-install auth debugging required.

Problem 3: WhatsApp's 24-hour window

Nobody documents this clearly upfront: Meta Cloud API only allows free-form text within a 24-hour window after the client initiates contact. Business-initiated messages — appointment reminders, birthday greetings, re-activation nudges — require pre-approved Message Templates (HSM) submitted through Meta Business Manager.
This matters if you're building anything that sends proactive notifications via WhatsApp. You either get your templates approved first, or your reminder system silently fails for business-initiated messages. I documented this honestly in the README as a known limitation.

Automatic migrations on startup

Self-hosters shouldn't have to run database migrations manually. I wrote a scripts/migrate.js that runs all Supabase migrations in order before the app starts, using the pg library directly.

# docker-compose.yml
services:
  migrate:
    build: .
    command: node scripts/migrate.js
    depends_on:
      db:
        condition: service_healthy

  app:
    build: .
    depends_on:
      migrate:
        condition: service_completed_successfully

The service_completed_successfully condition means the app won't start until all 18 migrations have run cleanly. docker compose up -d is now genuinely one command.

The full stack

Frontend: Next.js 14 + Tailwind + shadcn/ui
Backend: Next.js API routes + Supabase
Database: PostgreSQL (Supabase), 18 migrations
Auth: Supabase Auth — Email + Google OAuth
Notifications: Resend, Telegram Bot API, Meta WhatsApp Cloud API, Viber Bot API
Storage: Cloudflare R2
Self-hosting: Docker Compose, multi-stage build, non-root user
PWA: next-pwa 5.6.0, IndexedDB for offline POS
i18n: next-intl 4.9.0 (EN active, more coming)

What's live in v1.0

POS — completes a sale in 3 clicks, works offline via PWA + IndexedDB
CRM — full client history, visit patterns, birthday, tags, notes
Booking calendar — drag & drop, week view, staff columns
Public booking page — name + phone only, no client account required
Inventory — stock tracking, low-stock alerts via all channels
Notifications — all 4 channels fire automatically: booking confirmed → 24h reminder → 1h reminder → thank-you → 30-day re-activation → birthday → low-stock
Multitenancy — each business isolated via Supabase RLS, own subdomain.

Running costs at zero customers

~$20–25/month on an existing DigitalOcean server. One Starter customer ($19/mo) covers it. Two Pro customers ($39/mo) puts it in the green.

What I'm still figuring out

Payment processing as a solo founder based in Georgia (the country) is genuinely difficult. LemonSqueezy and Polar.sh both don't support bank payouts to Georgia. Paddle has been pending verification for two weeks. Currently testing Dodo Payments. If you've solved this from a non-Stripe-supported country, I'd genuinely appreciate knowing what worked.

GitHub: github.com/SGrappelli/pronto — MIT, Docker Compose, CI/CD
Live cloud version: trypronto.app
Happy to answer questions about any of the technical decisions above.