Multi-Tenant SaaS on Lovable: Setting Up Wildcard Subdomains the Right Way

Every SaaS founder building on Lovable hits the same wall eventually: you've got customers, they each need their own space in your app, and typing acme.yourapp.com by hand into a DNS dashboard every time someone signs up is not a business model. It's a bottleneck.

Wildcard subdomains fix this. One DNS rule, infinite tenants, zero manual work. Here's the full setup, based on a real Lovable + Cloudflare production configuration — including the failure modes nobody mentions until you've already hit them.

Quick Definition

A wildcard subdomain is a single DNS record — written as *.yourapp.com — that automatically routes any subdomain under your domain to your application. Your code then figures out, per request, which customer or workspace that subdomain belongs to. No per-tenant DNS entry required, ever.

Compare that to a custom domain, where a customer brings their own domain (like theirbrand.com) and points it at you. That's a related but separate feature — different Cloudflare tools, different setup entirely — and worth its own guide.

Why Cloudflare Sits Underneath Lovable Here

Lovable is excellent at application logic — your UI, your backend, your data model. What it doesn't do natively is edge-level DNS routing. That's Cloudflare's job: it sits in front of every request, decides where it goes, and lets you run custom logic (via Workers) before the request ever touches your Lovable backend. Pairing the two gives you a clean split — Cloudflare handles routing at the edge, Lovable handles what happens once a request arrives.

Before You Start

Get these four things in place first:

1. A Cloudflare account with your root domain added as a zone
2. An API token with Zone:DNS:Edit and Zone:Zone:Read permissions — nothing broader is needed
3. A Lovable project with edge/backend function support turned on
4. Your root domain (just the root — not every subdomain) connected inside Lovable's domain settings

The Setup, Step by Step

1. Add the wildcard DNS record. In Cloudflare, create a CNAME: *.yourapp.com → yourapp.com, and make sure the proxy status is on (orange cloud). If it's grey-clouded (DNS-only), Cloudflare won't intercept the traffic and none of the routing logic below will fire.

2. Write and deploy your router Worker. This is a small script that reads the Host header off every incoming request and forwards it toward your origin, tagging the original subdomain along the way so your app can identify the tenant. Attach it to the route *.yourapp.com/*.

3. Keep the apex domain out of the wildcard route. This trips people up constantly. yourapp.com by itself — your homepage, your login screen, your marketing site — needs to stay off the wildcard route. Mixing it in causes your main site to start behaving like a tenant page, or a tenant subdomain to accidentally serve your homepage. Route them separately.

4. Configure your secrets. You'll need: Cloudflare API token, account ID, zone ID, and a fallback hostname (the CNAME target). Store all four as environment secrets. If your fallback hostname isn't explicitly set, verify your code has a working default — a silent fallback failure here is hard to debug later.

5. Write the host-resolution logic. Somewhere early in your request pipeline — middleware, a route loader, an edge function — pull the subdomain from the request and look up which tenant it maps to. Serve their content, or a clean "this page isn't live" message if there's no match. This code runs on every request to every subdomain, so index your lookup table and keep the query fast.

6. Build subdomain claiming logic. Three pieces here:

• Suggestion: auto-generate a candidate subdomain from a workspace or business name at signup
• Validation: block reserved words and anything that would collide with system routes like www, api, or admin
• Uniqueness: enforce this at the database level with a unique constraint, not just an application-side check — race conditions during signup are real

What to Store in Your Database

Persisting status on the record itself — rather than hitting Cloudflare's API live every time someone loads a dashboard — keeps things fast and gives your support team an instant answer when a customer says "my subdomain isn't working."

Status States Worth Building Around

• Active — everything's healthy
• Provisioning — setup in progress
• Worker missing — the route exists, but the Worker script isn't attached or deployed
• DNS misrouted — the record exists but points wrong, or isn't proxied
• Unknown — hasn't been checked yet

Build a one-click (or fully automatic) repair path that re-runs provisioning when something's flagged unhealthy — recreate the DNS record, redeploy the route — so fixing a broken subdomain doesn't require someone manually digging through the Cloudflare dashboard.

Confirming It Actually Works

dig acme.yourapp.com CNAME
curl -I https://acme.yourapp.com

Look for a 200 status, a server: cloudflare header, and whatever custom header your Worker adds — that last one confirms the request went through your routing logic, not just Cloudflare's generic proxy.

Three Mistakes That Show Up Constantly

• Letting the wildcard route swallow the apex domain too
• No handling for a subdomain that resolves but has no live tenant behind it — leaves visitors staring at a blank or broken page
• Static assets (images, CSS, scripts) not passed through correctly, so pages render but look broken

Want This Built for You?

If you'd rather not spend a weekend debugging a misrouted Worker route, AIFun builds exactly this kind of wildcard subdomain infrastructure for Lovable-based SaaS platforms. Reach out and we'll handle the Cloudflare and Lovable configuration end to end.