What's Live Right Now
Everything is set up. The demo is fully functional. Open the URLs below in a browser to confirm.
The 6 Live URLs
The puppy-co.org URLs are the strongest part of the demo. That domain is a real, separate domain you registered. It is being served by your demo platform (platform-demo.tarheel.us) through a real Cloudflare for SaaS Custom Hostname with an auto-issued cert. That is exactly the architecture the customer wants to build for their own customers.
Architecture Diagram (customer-facing, separate file)
File: SSL_for_SaaS_Architecture.html (on your desktop)
This is the customer-safe diagram. No internal notes, no demo URLs, no prep content. Share-screen this file when you want to walk them through the architecture. The talk track below is what you say while they look at it.
Talk Track for the Diagram
Use this when you have the Architecture Diagram open on screen. Take it at a normal pace, ~3 minutes total. Resist the urge to read it.
Intro panel (top of diagram)
Okay let me pull up a diagram real quick because I think it'll make this all click. There are really two different scenarios for how websites get served through Cloudflare, and the difference matters a lot for what you're trying to build. Most companies only ever deal with one of these scenarios. You're going to deal with both.
Flow A (blue box) · all steps
Flow A up here is the simple, normal case. This is what most companies on the internet do. You own a website, you put Cloudflare in front of it for speed and security, that's it. So for your business, this is for your own websites. Your marketing site at yourplatform.com. Your customer dashboard. Your documentation. Anything that lives on a domain you control. Visitor types your URL, Cloudflare's network catches it first, makes it fast and secure, sends it through to your servers, and the visitor gets your page. Three steps, super simple. This is the kind of thing every Cloudflare customer in the world is doing.
Flow B (orange box) · intro
Flow B is the interesting one for you, and it's the reason we're talking. This is what happens when Cloudflare needs to serve a website that's on a domain your customer owns, not yours. So let's say your customer is Acme Coffee and they bought acmecoffee.com years ago. They sign up for your hosting service and they want their coffee shop website running on your infrastructure, but they want it to show up as acmecoffee.com, not as something like acmecoffee.yourplatform.com. Their domain stays their domain. They never have to create a Cloudflare account, they never even know Cloudflare is in the picture. From their perspective, they're just signed up with you. Their site loads fast, has HTTPS, and works perfectly. That's the magic. That's exactly what Cloudways built their whole business on, and it's what we're going to help you build too.
Flow B · steps 1 2 3
So let me walk through what actually happens behind the scenes when somebody visits Acme Coffee's website. They type acmecoffee.com into their browser. The request hits Cloudflare's network. Cloudflare looks at the request and goes "okay, this is acmecoffee.com, I have a record that says this site belongs to your platform, and I have a valid SSL certificate for it, all good." Then Cloudflare needs to know where to actually send the request to get the website's content. That's where the Fallback Origin comes in.
Flow B · Fallback Origin (yellow box) + step 4
The Fallback Origin is just a setting you configure once on Cloudflare's side that says "here's where my platform's servers are." So you set it once to point at your platform's backend, whatever that is. After that, every single customer site that gets added to your platform automatically routes there. You don't have to configure anything per-customer. Customer signs up, your code tells Cloudflare "add acmecoffee.com to our list," Cloudflare handles the cert, and traffic just starts flowing to your servers automatically. That's the part that lets you scale this to thousands or hundreds of thousands of customers without managing each one individually.
Comparison table (bottom of diagram)
And down here at the bottom of the diagram is a quick comparison table summarizing the two flows. The line I'd really focus on is the last row, "use case for your platform." Flow A is for your platform's own websites. A handful of domains you own and control. Flow B is for every one of your hosting customers. Potentially hundreds of thousands of domains your customers bring to your platform. Two completely different problems, two completely different solutions, and you need both.
Transition
Okay let me close this and head back to the dashboard, I want to show you what this actually looks like running on real infrastructure.
The Key Facts (for when they ask)
Custom Hostnames Active
2 (puppy-co.org, www.puppy-co.org)
Cert Authority
Google Trust Services
Fallback Origin
platform-demo.tarheel.us
Worker Name
hostingco-platform-demo
Routes Bound
6 hostnames, 1 Worker
The Demo Walkthrough ~4-5 minutes
This goes in your existing call script during the technical block, after you've explained Cloudflare for SaaS conceptually. Replaces the generic dashboard tour with a live demo.
Open three tabs before the call so you can switch between them fast:
https://platform-demo.tarheel.us (the platform landing page)https://dash.cloudflare.com (logged in to CF-1 Lab, on the tarheel.us zone)- A fresh blank tab for typing customer site URLs as you go
Transition into the demo
Let me actually show you what this looks like in practice. I built a small version of this exact pattern on my own infrastructure, so instead of walking you through a generic dashboard, we can look at something real. Mind if I share my screen?
Step 1: Show the platform landing page
Open https://platform-demo.tarheel.us. Show the dark page with four customer rows listed (Portland Coffee, Stackpath Consulting, Riverside Fitness, Puppy Co).
Okay, so the URL up here in the bar is platform-demo.tarheel.us. That's the address I'm using as a stand-in for my fake hosting platform's backend. Think of it as my "app server" for the demo. In your real production setup, this would be the hostname of your actual application, like app.yourplatform.com or hosting.yourplatform.com, wherever your platform code actually runs. It's the address that ultimately serves all the customer traffic.
And what you're looking at right now is the landing page for that platform. Four fake customer sites, all hosted on the same infrastructure. Each one has its own domain, but they're all powered by the same piece of code behind the scenes. Cloudflare calls these "Workers" — it's basically just a small program that runs on Cloudflare's network and generates the website's content for each visitor. For this demo, one Worker is handling all four fake customer sites. Same way you could have one piece of platform code handling thousands of customer sites. Let me show you what each one actually looks like to a visitor.
Step 2: Click into the first customer site
Click Portland Coffee on the platform page, or open https://portland-coffee.tarheel.us in your blank tab.
This is Portland Coffee. Their own subdomain, their own branding, their own content. From a visitor's perspective they're just on Portland Coffee's site. They have no idea Cloudflare or my platform is even involved. Look at the bottom card — their site has a Cloudflare cert that was issued automatically, DDoS protection is on, WAF is active, all of that just works because it sits underneath my platform's Cloudflare account.
Step 3: Click into the second customer site briefly
Open https://stackpath-consulting.tarheel.us in your blank tab. Quick glance, show the different branding.
Here's Stackpath Consulting. Same exact platform underneath, different industry, different branding, different plan tier. The Worker reads the incoming hostname and decides what to render based on which customer is being requested. Different business, same code path.
Step 4: ★ The star moment — Puppy Co (the real external domain)
Open https://puppy-co.org in your blank tab. Show the Puppy Co branded site loading on a domain that doesn't have "tarheel" in it.
This is the moment that matters most. The previous customers were subdomains of my platform domain, which is a useful demo but doesn't show the real Cloudflare for SaaS pattern. Puppy Co is different. It's an actual external domain (puppy-co.org, registered separately) that's pointing at my platform. That's exactly what the customer's end-customers would do — they bring their own domain, and the platform serves their site.
Okay this one is actually the most important. Notice the URL: puppy-co.org. That is not a subdomain of my platform. That is a completely separate domain that I registered through Cloudflare Registrar last week for like four dollars. From the visitor's perspective, this is Puppy Co's website. They have no idea my platform is in the picture at all. But behind the scenes, puppy-co.org is pointing at my platform via a Cloudflare for SaaS Custom Hostname. Cloudflare automatically issued an SSL cert for their domain. Auto-renewing. No human ever set that up.
That is the pattern. A new customer signs up with you. They bring their own domain. Your code calls the Cloudflare API to add their hostname. Within seconds, Cloudflare validates the domain and issues a cert. Their site is live on your platform with full DDoS, WAF, CDN, all of it. End to end, zero human steps.
Step 5: Pivot to the Cloudflare dashboard — show the Custom Hostnames page
Switch to your dashboard tab. Navigate to: tarheel.us zone → SSL/TLS → Custom Hostnames. You should see two entries: puppy-co.org and www.puppy-co.org, both with active status and SSL active. Also visible on the same page near the top: the Fallback Origin setting, configured to platform-demo.tarheel.us.
Okay let me jump over to the Cloudflare dashboard real quick. I want to show you what this looks like from the platform operator's perspective — meaning, what your team would actually see and use day to day.
So this is my Cloudflare account, and I'm clicking into a domain called tarheel.us. That's the domain I'm using as the "platform" for this demo. In your setup, the equivalent would be a domain you own — like yourplatform.com — and you'd configure it the same way.
Now I'm clicking into SSL/TLS in the menu, and then Custom Hostnames. This is the page where Cloudflare for SaaS lives. And here it is.
Let me walk you through what's on this page. At the top there's a setting called Fallback Origin. Mine's set to platform-demo.tarheel.us. Remember from the diagram, the Fallback Origin is the address Cloudflare sends customer traffic to by default. So when someone visits one of your customer's sites, Cloudflare knows to route that traffic to your platform's backend — wherever your application actually runs. In your case, this would point at your hosting infrastructure. You configure it one time, right here, and you never touch it again.
Below that is the list of customer domains. I've got two right now: puppy-co.org and www.puppy-co.org. Both say "Active" — that means Cloudflare verified the customer owns the domain and everything's working. And both have a valid SSL certificate, the green lock icon you see in a browser. Cloudflare issued these certificates automatically, and renews them automatically forever. I never have to think about SSL certificates again.
Here's the most important thing for you. I didn't manually click any buttons to add these customer entries. I had my code make a single request to Cloudflare for each one, which took about a second, and Cloudflare did everything else — the verification, the SSL certificate, the routing setup. All automatic. In your production setup, this dashboard would basically be your "live customers" view — updated automatically every time a customer signs up through your normal onboarding flow. Your code talks to Cloudflare behind the scenes. You'd only come look at this page if you wanted to see the full list, troubleshoot a specific customer, or check on something. The actual day-to-day work of adding and removing customers happens through your code, not through anyone clicking around in here.
Step 6: Show the Workers Routes page (the platform side)
Still in the tarheel.us zone. Navigate to: Workers Routes (under Workers & Pages or in the sidebar depending on dashboard version). Show the 6 route bindings.
Alright, one more thing I want to show you. Let me jump over to a page called Workers Routes — same Cloudflare zone, just a different section.
So this page shows you which website addresses are connected to which piece of platform code. I've got six addresses listed here. Four are the fake customer sites I showed you a minute ago. The other two are puppy-co.org and www.puppy-co.org. Here's what I want you to notice: every single one of these six addresses connects to the same piece of code. It's the same Worker we talked about, named hostingco-platform-demo. One piece of platform code, handling six different customer websites.
That's the whole architecture, summarized on one page. One piece of platform code can handle any number of customer websites. The code itself is literally five lines — it looks at the incoming web address, figures out which customer it's for, and serves the right content. The code doesn't change when you add new customers. The platform code stays exactly the same whether you have 10 customers or 100,000. You just keep adding new entries to the Custom Hostnames page (which we looked at earlier), and everything else happens automatically.
At your scale, this is what makes the math work. Adding your ten thousandth customer doesn't require any new infrastructure, any new code, any new config. It's one API call, one new entry on this page essentially, and you're done. The cost scales linearly with usage, not with complexity.
Step 7: Close the demo, transition back to the call flow
Stop the screenshare. Hand back to the call flow (WordPress layering or back to Mayah).
Okay, I'll stop sharing. That's the pattern at small scale. Your version would be the same architecture with your customer database, your branding rules, your provisioning logic, and your scale. The Cloudflare side stays the same shape no matter how many customers you have. Now — what I wanted to mention before handing back to Mayah is some WordPress specific stuff worth layering on top, because you're hosting so much of it.
From here, you flow into the existing WordPress block in your call script (Bot Management, Advanced Rate Limiting, zero day patching).
Customer-Specific Notes: Scale, Licensing, Migration
Raw notes you gathered. Treat the pricing and feature specifics as starting points to verify with Mayah and deal desk before quoting anything in writing.
Scale: 100,000 hostnames
The customer is projecting 100,000 customer hostnames at scale. That number drives the commercial conversation more than anything else, because SSL for SaaS pricing is per-hostname with volume tiers. A few things worth knowing.
Rough pricing reference (verify with deal desk): Per-hostname pricing has historically been in the range of approximately $0.50 per hostname per month at lower volumes, with volume discounts at scale. For 100K hostnames, the per-hostname rate is significantly lower than the list price — that's a deal desk conversation, not a list-price one. Do not quote a specific number on the call. Defer to Mayah and deal desk.
Migration: how does the customer move 100K end-customers onto Cloudflare for SaaS?
This is a real question they will ask. The honest answer is they have two paths.
- Manual test first. Start with two or three hostnames added manually to validate the setup, certs, fallback origin behavior, and any edge cases unique to their stack. That's the de-risk phase. Takes a day.
- API at scale. Once the pattern is validated, the Custom Hostnames API can onboard hostnames in bulk. The customer's existing database becomes the source of truth, and a migration script iterates through it, calling the API to add each one. Cloudflare handles cert issuance, validation, and routing automatically.
The fallback origin only gets set once on the SaaS zone, so as new hostnames get added during migration, they automatically route correctly. No per-hostname routing config needed.
Wildcard Custom Hostnames (Advanced feature)
Wildcard support (e.g., *.customerdomain.com as a single Custom Hostname instead of per-subdomain entries) is part of SSL for SaaS Advanced, not the base SaaS tier. Worth flagging because if the customer's end-customers commonly have multiple subdomains (www, blog, shop, etc.), wildcard support changes their per-customer hostname count significantly and impacts pricing.
SSL for SaaS Advanced — what it adds
The Advanced tier adds capabilities beyond the base SaaS offering. The most relevant pieces for this customer:
- Custom Metadata. Lets the customer attach metadata to each Custom Hostname (customer tier, plan, internal IDs, region, etc.) that can be read at the edge for routing logic or analytics. Highly useful for a multi-tenant platform that needs to differentiate behavior per customer.
- Custom Fallback Origin per hostname. Instead of one global fallback origin for all Custom Hostnames on the zone, Advanced allows different customers to route to different backends. Critical if they want to shard customer traffic across multiple backend regions or environments.
- Wildcard Custom Hostnames (as above).
For this deal specifically: Custom Metadata is the killer feature. A platform managing 100K customers will absolutely need per-hostname metadata at the edge to do tiered routing, plan-based feature gating, or any customer-specific logic. That alone is usually enough to justify SSL for SaaS Advanced.
Apex domain support (and why it has an additional cost)
What "apex" means. The apex of a domain is the bare domain itself, no subdomain prefix. So for customerbrand.com, the apex is customerbrand.com. The non-apex versions would be www.customerbrand.com or shop.customerbrand.com or any other subdomain.
Why apex is tricky. There's a quirk in DNS that goes back to the original spec. You can use a CNAME record on a subdomain (so www.customerbrand.com can CNAME to your platform), but you technically can't use a CNAME at the apex of a domain. The apex has to be an A record or AAAA record pointing at a specific IP address. For a SaaS platform serving customer domains, this creates a real problem because customers want both customerbrand.com and www.customerbrand.com to work, and you can only easily route the www version through a CNAME.
How Cloudflare solves it — two paths.
- CNAME Flattening (free). If the customer is using Cloudflare DNS for their domain, Cloudflare automatically "flattens" a CNAME at the apex behind the scenes. The customer just adds a CNAME, and Cloudflare DNS handles the apex case dynamically. No extra cost.
- Dedicated IP for Apex Proxying (paid). If the customer is NOT using Cloudflare DNS (they're on GoDaddy, Route 53, or another provider), CNAME flattening doesn't apply. The apex has to be an A record pointing at a real IP. Cloudflare for SaaS can give the customer a dedicated IP address to A-record their apex at. This is a separate paid feature.
Why this matters for the customer. If all of their end-customers use Cloudflare DNS, apex support is essentially free. If some end-customers use other DNS providers (which is almost certainly the case), the customer has to either provide them a dedicated IP (paid) or steer them to www-only.
The common workaround. Many platforms tell customers to use www.customerbrand.com as the canonical hostname and just set up an apex-to-www redirect at the customer's registrar. That avoids the apex IP cost entirely. Webflow, Shopify, and many others handle it this way. The customers who insist on real apex support are usually larger brands who care about marketing optics ("our customers should be able to type customerbrand.com directly without the www"). Smaller customers typically don't care.
The real question for the customer: Do they want to support apex domains as a feature of their hosting platform, or steer end-customers to www-only? That's a product decision more than a technical one. It affects pricing (per the dedicated IP cost), complexity, and customer experience. For most hosting platforms serving small-to-medium businesses, www-only is the right call. For platforms hosting big brands, apex support is table stakes.
Pocket answer if they ask "what is apex support?"
The apex of a domain is the bare version, with no www. So for customerbrand.com, the apex is just customerbrand.com itself. DNS has a quirk where you can't really CNAME the apex like you can for a subdomain — it has to be an IP address. So if your customers want their bare domain to work on your platform, and they're not using Cloudflare DNS, they'd need us to give them a dedicated IP they can point that bare domain at. It's a separate cost on top of the per-hostname pricing. Most platforms steer customers to use www instead to skip the issue, but it depends on what experience you want to give your customers.
How to handle these in the call
These are all
commercial and deal-structure topics, not technical demo content. If your platform asks any of these during the demo or technical conversation, the right move is:
- Acknowledge the question is important and you have the technical answer (use the notes above as a guide).
- Tell them the specific pricing and tier structure is Mayah's lane, and you'll make sure she covers it in the commercial portion of the call.
- Hand the thread to Mayah, or note it for her to follow up if she's not on the call live.
Before Monday: Sync with Mayah on these specific items so you both walk in with the same answer. Especially the per-hostname pricing reference and whether deal desk has already modeled out the 100K commit. If she's not aligned with you on these numbers, the customer will get conflicting answers.