How a multi-tenant hosting platform serves customer domains through Cloudflare's edge
Two routing patterns. Same Cloudflare edge.
There are two distinct ways traffic can flow through Cloudflare to a backend, and the difference matters a lot for a hosting platform like [Your Platform].
Flow A is what happens when Cloudflare serves a domain you own. The domain lives in your Cloudflare account, you bind a Worker to it directly, the edge routes traffic to your Worker. This is regular Workers behavior and works on any Cloudflare plan.
Flow B is what happens when Cloudflare serves a domain your customer owns. The domain is NOT in your account. Your customer just points their domain at your platform via a CNAME. Cloudflare for SaaS handles the rest: validates the domain, issues a dedicated SSL certificate for it, and routes traffic through your platform's backend using a setting called the Fallback Origin.
Why [Your Platform] needs Flow B: Your customers keep ownership of their domains. They won't (and shouldn't) move them into your Cloudflare account. Flow B is the pattern that lets you serve their site without taking ownership of their domain. That's the entire purpose of Cloudflare for SaaS.
Flow A: Domain you own
Regular Worker Route. The simple path. No Cloudflare for SaaS involved.
Visitor
Types store.yourplatform.com
Cloudflare's Edge
Closest PoP (1 of 330+)
1 Worker Route matches directly
Route pattern store.yourplatform.com/* binds to a Worker on your zone. Edge resolves immediately.
Worker
Your platform's logic
Reads request, renders response
Outcome
Visitor sees your platform's content
★ Flow B: Domain your customer owns
Cloudflare for SaaS. Custom Hostname + Fallback Origin. This is the production [Your Platform] pattern.
Visitor
Types customer-domain.com
Cloudflare's Edge
Closest PoP (1 of 330+)
1 DNS lookup
The customer's domain is proxied through Cloudflare via CNAME to cname.yourplatform.com. Edge recognizes this as a configured Custom Hostname destination.
2 Custom Hostname check
Edge confirms an Active Custom Hostname exists for the customer's domain on your SaaS zone. SSL cert is valid (auto-issued, auto-renewing).
3 Where to route?
Edge needs a backend. It looks up the Fallback Origin configured on the SaaS zone.
★ Fallback Origin (configured once on your SaaS zone)
Your platform's backend
Default backend for ALL Custom Hostnames on this SaaS zone
Why this matters: Configured once. Every new customer Custom Hostname automatically uses it. No per-customer routing config.
4 Route to backend
Edge sends the request to your platform's backend. The original Host header is preserved, so your code can tell which customer this is for.
Your platform's backend
Worker, container, or origin
Reads Host header, renders the right customer's site
Outcome
Visitor sees customer's site on customer's domain
★ The SSL Certificate: What actually happens
Your customer does almost nothing. Cloudflare automates the entire certificate lifecycle behind the scenes.
Your customer's DNS
customer.com → points to [Your Platform]
1 You add a Custom Hostname
Through the [Your Platform] dashboard, you (or your system) tell Cloudflare: "please serve customer.com for this tenant." Status starts as Pending.
2 Cloudflare validates ownership
Cloudflare checks the customer's DNS to confirm they actually own customer.com. This is automatic — no emails, no file uploads, no support tickets.
3 Dedicated certificate issued
Cloudflare generates a dedicated SSL certificate specifically for customer.com. Not shared. Not a wildcard. Their own cert.
★ Certificate Active
customer.com is now protected
Status flips from Pending → Active. Traffic can now serve securely.
Then it just stays on: Cloudflare auto-renews the certificate before it expires. Your customer never thinks about SSL again. Neither do you.
What your customer actually has to do
This is the part that sells it. Your customer wants their own domain with HTTPS. Here's literally what they do:
1
Buy their domain (or use one they already own)
Same as always. No special registrar required.
2
Add one DNS record at their domain registrar
They log into wherever they bought their domain (GoDaddy, Namecheap, Cloudflare Registrar, Route 53, Squarespace Domains, etc.) and add a single CNAME pointing their domain at your platform:
Type: CNAME Name:www (or @ for apex) Target:cname.yourplatform.com
You never touch their DNS. They keep their domain at whatever registrar they had it. You just give them the CNAME target and they handle the rest in their own dashboard.
3
That's it
SSL certificate auto-issues. HTTPS works. No configurations. No uploads. No waiting on you.
The pitch: "Give us your domain, add one CNAME, and you're live with SSL in minutes — not days."
Why not just use a wildcard certificate?
This is the natural question your customer (or their IT team) will ask. Here's the honest answer:
❌ A wildcard covers *.yourplatform.com — not customer.com
If your customer owns acme-store.com, a certificate for *.yourplatform.com does nothing for them. Browsers will show a security warning.
❌ Customer bringing their own certificate is a support nightmare
They'd need to generate a CSR, buy a cert, upload it to your platform, remember to renew it yearly, and contact you when it breaks. Nobody wants that.
✅ Cloudflare for SaaS: dedicated cert per customer, fully automated
Each customer domain gets its own SSL certificate, issued and renewed automatically. Your customer adds a CNAME. You add a hostname. Cloudflare handles the rest. That's it.
Migrating thousands of customers at once
Onboarding one customer is easy: they add a CNAME, you add a Custom Hostname. But what if [Your Platform] already has 10,000+ existing customers and you want to move them all onto Cloudflare for SaaS? That's a different conversation.
The good news: it's not a one-by-one manual process. There are three migration patterns most platforms use, depending on how much control you want and how cooperative your customers are.
1
Bulk API onboarding (your code does the work)
[Your Platform] already has every customer's domain in your database. Run a script that iterates through your customer list and calls the Cloudflare Custom Hostnames API for each one. Cloudflare creates the entries, starts the validation process, and issues certs as customers' DNS resolves correctly.
Timeline: The API can handle thousands of additions in minutes. The bottleneck is DNS, not Cloudflare. Customers whose CNAMEs are already pointing at you go Active immediately. Customers whose DNS isn't ready yet stay in Pending until they update it.
2
Staged rollout (recommended for production migrations)
Don't migrate everyone at once. Start with a pilot group: maybe 10-50 friendly customers who agreed to test. Validate the flow end-to-end. Confirm certs issue cleanly, traffic routes correctly, no regressions in their site behavior. Then expand in waves: 100 customers, then 1,000, then the rest.
Why this matters: If something breaks (a routing bug, a cert validation edge case, a Worker logic issue), you find it with 10 customers, not 10,000. Most platforms do this over 2-4 weeks.
3
Customer-initiated (lowest risk, slower)
Instead of pushing the migration, you announce the new platform and let customers opt in through their [Your Platform] dashboard. They click "upgrade to new platform," your backend calls the Cloudflare API for their domain, they update their CNAME, and they're migrated.
Why this matters: Zero risk of breaking sites for customers who aren't paying attention. The downside is migration takes months, not days. Good for enterprise customers who want to control timing on their side.
What most platforms actually do: A combination. Use Pattern 2 (staged rollout) for the technical validation, then Pattern 1 (bulk API) for the main migration wave once you're confident, with Pattern 3 (customer-initiated) as a fallback for customers who need extra time or have unusual DNS setups.
What to watch out for during migration
Honest list of the things that actually trip platforms up when they move thousands of customers onto Cloudflare for SaaS. None of these are blockers, but you want to know about them in advance.
⚠️ DNS propagation timing
When a customer updates their CNAME, it can take seconds to a few hours for DNS to fully propagate globally (depending on their TTL). Cloudflare will keep re-checking until validation succeeds. No action needed from you, just don't panic if a hostname stays Pending for a bit.
⚠️ Customers with existing CNAMEs pointing elsewhere
If a customer already has a CNAME pointing at old-infrastructure.yourplatform.com, they need to update it to the new CNAME target before validation succeeds. Build that into your migration communication.
⚠️ Apex domain customers
Customers who use the bare apex (no www) need different handling. If their DNS is on Cloudflare, CNAME flattening solves it for free. If not, they need a dedicated IP from Cloudflare (additional cost) or they need to redirect to www. Identify these customers early.
⚠️ Old SSL certs hanging around
If a customer's domain previously had its own SSL cert managed elsewhere, you don't need to revoke it. Cloudflare will issue a new dedicated cert and serve that instead once the Custom Hostname goes Active. The old cert just expires naturally.
⚠️ Customers who manage their own Cloudflare account
Some of your existing customers may already have their own Cloudflare account (maybe they set it up themselves before joining your platform). You can't add their domain as a Custom Hostname on your zone while it's an active zone on theirs. They'll need to remove it from their account first, or you keep them on a separate flow.
Side-by-side comparison
Aspect
Flow A (domain you own)
Flow B (customer's domain)
Who owns the domain
You (the platform)
Your customer
In your Cloudflare account?
Yes, it's your zone
No, it's their zone (or registered elsewhere)
Routing mechanism
Direct Worker Route on the hostname
Custom Hostname → Fallback Origin → Worker
SSL certificate
Your zone's Universal SSL
Dedicated cert auto-issued per customer domain
Per-customer config
Each subdomain is its own route
One Custom Hostname API call, no routing config
Cloudflare product
Workers (any plan)
Cloudflare for SaaS (Pro, Business, Enterprise)
Use case for [Your Platform]
[Your Platform]'s own marketing site, dashboard, etc.