Personal study reference, not customer-facing. Covers how multi-tenant platforms serve customer-owned domains through Cloudflare's edge — Custom Hostnames, Fallback Origin, cert lifecycle, apex domain handling, Orange-to-Orange, and Enterprise-gated features. Includes major corrections: "SSL for SaaS Advanced" is not a real current product name, and "Custom Fallback Origin per hostname" was misclassified as an Enterprise feature — it's actually free on every plan including Free. Every fact below is sourced from live Cloudflare docs (full list at the bottom).
Naming note: "Cloudflare for SaaS" is the current name. "SSL for SaaS" is the old name for the same product (renamed years ago, not part of this session's recent 2026 rename wave) — you'll still see "SSL for SaaS" in the certificate-type label and Terms of Service. There is no current product named "SSL for SaaS Advanced" — that's informal/legacy shorthand. Gating is purely by account plan (Free/Pro/Business/Enterprise) plus two explicit Enterprise-only paid add-ons (Module 6).
There are two distinct ways traffic flows through Cloudflare to a backend, and the difference is the entire reason Cloudflare for SaaS exists.
Regular Workers/Routes behavior, no Cloudflare for SaaS involved. The domain lives in your own Cloudflare account, you bind a Worker or route directly to it, the edge routes traffic to your backend. Use case: your own marketing site, your own customer dashboard — domains you control, on any Cloudflare plan.
"Let's say your customer is Acme Coffee and they bought acmecoffee.com years ago. They sign up for your hosting service and want their site running on your infrastructure, but showing up as acmecoffee.com — not acmecoffee.yourplatform.com. Their domain stays their domain. They never create a Cloudflare account, never even know Cloudflare is in the picture."
acmecoffee.com — request hits Cloudflare's edge.The Fallback Origin is the part that makes this scale: configured once, every new customer's Custom Hostname automatically uses it — no per-customer routing config. Customer signs up, your code tells Cloudflare "add acmecoffee.com," Cloudflare handles cert issuance and validation, traffic starts flowing automatically.
| 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, your zone | No — their zone or registered elsewhere |
| Routing mechanism | Direct Worker/Route on the hostname | Custom Hostname → Fallback Origin → your backend |
| SSL certificate | Your zone's Universal SSL | Dedicated cert auto-issued per customer domain |
| Per-customer config | Each hostname is its own route | One API call, no routing config |
| Cloudflare product | Workers (any plan) | Cloudflare for SaaS (Free and above) |
A wildcard covers *.yourplatform.com — it does nothing for a customer's own domain, which would show a browser security warning. Customers bringing their own certificate is a support nightmare (CSR generation, annual renewal, breakage when they forget). Cloudflare for SaaS gives each customer domain its own dedicated, auto-renewing certificate — the customer adds one CNAME, you add one hostname, Cloudflare handles the rest.
| Status | Meaning |
|---|---|
| Pending | Pending hostname validation |
| Active | Completed hostname validation |
| Active re-deploying | Active, changes currently being processed |
| Blocked | Abuse-flagged, cannot be added |
| Moved | Not active after the full backoff schedule, or no longer points to the fallback |
| Deleted | Occurs after remaining in Moved status for 7+ days |
Hostname ownership validation and certificate validation are tracked as two separate fields (result.status vs. result.ssl.status) — they can be in different states at the same time.
Hostname ownership validation: TXT record, HTTP token, or CNAME (real-time). Certificate DCV: http, txt, or email, plus Delegated DCV for auto-renewal.
Correction to "zero manual steps": that's only true for real-time CNAME-based validation. TXT validation requires the customer to add a DNS record; HTTP validation requires serving a token file at their origin. Only CNAME/real-time validation requires zero extra customer action — at the cost of a brief downtime window during cutover.
The "SSL for SaaS" certificate type is issued via Let's Encrypt, Google Trust Services, or SSL.com. Selecting a specific CA is an Enterprise-only capability; other plans get Cloudflare's default CA auto-assignment (checked against the domain's CAA records).
One zone-wide default backend, configured once at Dashboard → SSL/TLS → Custom Hostnames → Fallback Origin. All Custom Hostnames on that zone route here unless overridden per-hostname (see below). The original Host header is preserved by default, so your backend can tell which customer a request is for.
This is not an Enterprise/"Advanced" feature. Per-hostname custom origin overrides — letting different customers route to different backends instead of all sharing one zone-wide Fallback Origin — is called Custom Origin Server, and as of May 2025 it is available on every plan including Free (previously Enterprise-only). If you've seen this described as a Business/Enterprise-gated or "Advanced" capability, that's outdated.
This matters for sharding customer traffic across multiple backend regions or environments — you no longer need Enterprise just to do that.
The apex of a domain is the bare domain itself (e.g. customerbrand.com, no www). DNS has a real quirk here: you can CNAME a subdomain, but the apex traditionally requires an A/AAAA record pointing at a specific IP.
| Method | Requirement | Cost |
|---|---|---|
| CNAME flattening | Customer's domain must be on Cloudflare DNS | Free, automatic — Cloudflare flattens the apex CNAME behind the scenes |
| Apex Proxying (current correct name — not "Dedicated IP for Apex Proxying") | For customers NOT on Cloudflare DNS | Enterprise-only paid add-on — not available to Pro/Business even as an upgrade; no public price, contact account team |
A second Enterprise-only mechanism, BYOIP (bring your own IP range), is listed alongside Apex Proxying as the two ways to support apex domains without Cloudflare-DNS CNAME flattening. No newer third option exists as of this writing.
Many platforms steer customers to use www.customerbrand.com as the canonical hostname with an apex-to-www redirect at the customer's registrar, avoiding the Apex Proxying cost entirely — a pattern used by several large hosting platforms. Customers who insist on real apex support are usually larger brands focused on marketing optics; smaller customers typically don't push back on www-only.
Pocket answer: "The apex is the bare version of a domain, no www. DNS has a quirk where you can't CNAME the apex the way you can a subdomain — it needs an IP address. If your customer isn't on Cloudflare DNS and wants their bare domain to work, that requires a dedicated IP through Apex Proxying, which is an Enterprise add-on. Most platforms steer customers to www instead to skip the issue entirely."
A customer who already has their own Cloudflare account is not a blocker — it's a real, named, documented, supported configuration.
O2O is officially supported. It's the specific routing configuration where traffic passes through two Cloudflare zones in two different accounts: the customer's own zone first, then the SaaS provider's zone. Settings on the customer's zone apply first, then settings on the SaaS provider's zone apply second. Cloudflare sets an HTTP header, cf-connecting-o2o: 1, to signal this. Multiple SaaS providers can even hold an active Custom Hostname for the same domain simultaneously — routing is determined purely by where the customer's DNS CNAME currently points.
Pre-validation (TXT and HTTP token methods) is not supported for O2O hostnames — only real-time (CNAME-based) validation works, since there's no non-Cloudflare→Cloudflare cutover step to pre-validate against. If a migrating customer is already on Cloudflare, plan for real-time validation, not pre-validation.
No "Advanced" tier exists by name — these are discrete Enterprise-gated capabilities, some bundled, some separately priced add-ons.
| Feature | Gating |
|---|---|
| Custom Metadata | Enterprise-only paid add-on |
Wildcard Custom Hostnames (e.g. *.customerdomain.com as one entry) | Enterprise — bundled into the plan, not a separately listed add-on |
| Apex Proxying / BYOIP | Enterprise-only paid add-on (Module 4) |
| Selectable CA, custom (uploaded) certificates + CSR support, mTLS enforcement, SNI Rewrite for custom origin, custom WAF rulesets | Enterprise-only |
| Custom Origin Server (per-hostname backend override) | All plans including Free (Module 3 — commonly mis-stated as Enterprise-only) |
Lets you attach metadata to each Custom Hostname (customer tier, plan, internal IDs, region) that's readable at the edge via cf.hostname.metadata — used for tiered routing, plan-based feature gating, or differentiated security policy per customer (Module 7).
New use case as of October 2026: Custom Metadata is now also the mechanism for enabling Markdown for Agents on a per-custom-hostname basis — letting individual tenant sites opt into agent-friendly Markdown responses without affecting the whole SaaS zone.
Zone-level security config applies to every Custom Hostname by default. Per-customer differentiation requires Custom Metadata.
Configure WAF, Bot Management, or Rate Limiting once at the zone level and every Custom Hostname inherits it automatically — no per-customer setup needed for a single, uniform policy. For tiered protection (e.g. premium customers get stricter bot rules than free-tier customers), use Custom Metadata to tag hostnames and reference that tag in Ruleset Engine expressions:
lookup_json_string(cf.hostname.metadata, "security_level") eq "low"Plan gating on the security side specifically: Free/Pro/Business get standard WAF rules per their existing zone plan; Enterprise additionally gets the ability to create and apply fully custom firewall rulesets scoped by hostname metadata.
Per-customer bot/security analytics in your own dashboard (not just enforcement) requires Logpush plus your own data pipeline — real engineering effort on the platform's side, not something Cloudflare surfaces per-tenant out of the box.
| Free | Pro | Business | Enterprise | |
|---|---|---|---|---|
| Availability | Yes | Yes | Yes | Contact account team |
| Hostnames included | 100 | 100 | 100 | Custom |
| Price per additional hostname | $0.10 | $0.10 | $0.10 | Custom pricing |
| Pay-as-you-go hostname cap | 50,000 (raised from 5,000, May 2025) | — | ||
Correction: the plan floor is Free, not Pro — Cloudflare for SaaS is available on every plan. And the real public per-hostname rate is $0.10/month, not the ~$0.50 figure sometimes quoted informally — strike that number, it doesn't match current public pricing. No public volume-tier discount schedule exists; Enterprise pricing is explicitly custom/contract-negotiated, so assume real volume discounts exist at scale but don't quote a specific number without deal desk.
Cloudflare's own documentation recommends migrating "in phases" and provides a downloadable example migration plan, plus a specific "Zero-downtime migration" API runbook for a single hostname (create → pre-validate → pre-issue cert → confirm active → cut over the CNAME). There is no officially named 3-pattern taxonomy ("bulk API / staged rollout / customer-initiated") in Cloudflare's docs — that's useful SE field framing below, not an official doc citation.
Most real migrations combine staged rollout for technical validation, then bulk API for the main wave, with customer-initiated as a fallback for stragglers or unusual DNS setups.
A real, still-live demo environment exists: a fictional hosting platform at platform-demo.tarheel.us serving several fake tenant sites on subdomains, plus a genuinely separate, externally-registered domain — puppy-co.org — actually onboarded as a real Custom Hostname. That's the strongest part of any live demo, since it's indistinguishable from a real customer's production setup rather than a mockup — the URL bar contains no trace of the platform's own domain. Dashboard proof points to show: the Custom Hostnames list (Active status, SSL Active, real CA-issued cert), the Fallback Origin setting, and the Workers Routes page showing multiple hostnames bound to one piece of platform code.
"Notice the URL — it doesn't contain any part of my platform's domain. That's a completely separate domain, registered independently, pointing at my platform via a Custom Hostname. Cloudflare automatically issued and validated an SSL cert for it. No human set that up — a new customer signing up on a real platform would see their own domain live, with HTTPS, typically within about a minute end to end."
"Do we need a Pro or Business plan to use Cloudflare for SaaS?"
No — it's available starting on Free. 100 hostnames included, $0.10/month per additional hostname, same rate across Free/Pro/Business. Enterprise pricing is custom/contract.
"Can different customers route to different backends, or do they all have to share one origin?"
They can route differently — that's Custom Origin Server, and it's free on every plan including Free (since May 2025). Don't tell a customer they need Enterprise just for per-hostname origin overrides.
"Our prospective customer already has their own Cloudflare account. Is that a problem?"
No — that's Orange-to-Orange (O2O), a fully supported, documented configuration. The only real adjustment: use real-time (CNAME) validation instead of pre-validation (TXT/HTTP token), since pre-validation isn't supported for O2O hostnames.
"What does apex domain support actually cost?"
Free if the customer's domain is on Cloudflare DNS (CNAME flattening, automatic). If not, Apex Proxying is an Enterprise-only paid add-on with no public price — contact the account team. Many platforms avoid the cost entirely by steering customers to www with a registrar-level redirect.
"Is there an 'SSL for SaaS Advanced' plan we should be quoting?"
No such named product exists today. The relevant gating is per-feature at the Enterprise plan level — Custom Metadata and Apex Proxying/BYOIP are separate paid add-ons, Wildcard Custom Hostnames is bundled into Enterprise, and several other capabilities (selectable CA, custom certs, mTLS) are Enterprise-only without being branded as a distinct "Advanced" tier.
"How do we give premium customers stricter bot protection than free-tier customers on the same platform?"
Custom Metadata (Enterprise paid add-on) — tag each Custom Hostname with a tier/plan value, then reference that tag in a Ruleset Engine expression to vary WAF/Bot Management/Rate Limiting rules per customer.
Click a question to reveal the answer. No peeking before you commit to one.
Older — it was renamed from "SSL for SaaS" years ago, not part of this session's 2026 rename wave. The old name still appears in the certificate-type label and Terms of Service.
No — gating is purely by account plan (Free/Pro/Business/Enterprise) plus two explicit Enterprise-only paid add-ons (Custom Metadata, Apex Proxying/BYOIP). There's no distinctly branded "Advanced" tier.
No — this is Custom Origin Server, and as of May 2025 it's available on every plan including Free. It used to be Enterprise-only; don't tell a customer they need to upgrade just for this.
Free — 100 hostnames included, $0.10/month per additional hostname, same rate on Free/Pro/Business. Not Pro as sometimes assumed.
Three — Let's Encrypt, Google Trust Services, and SSL.com. Selecting a specific CA is Enterprise-only; other plans get automatic default-CA assignment.
No — only real-time CNAME-based validation is truly zero-touch. TXT validation requires the customer to add a DNS record; HTTP validation requires serving a token file at their origin.
Apex Proxying (not "Dedicated IP for Apex Proxying") — an Enterprise-only paid add-on with no public price. CNAME flattening is the free alternative, but only works if the customer's domain IS on Cloudflare DNS.
No — this is Orange-to-Orange (O2O), a fully supported, officially documented configuration. The only real adjustment: pre-validation (TXT/HTTP token) isn't supported for O2O — use real-time CNAME validation instead.
cf-connecting-o2o: 1
Custom Metadata (Enterprise paid add-on) — tag each Custom Hostname with a tier value, then reference cf.hostname.metadata in a Ruleset Engine expression to vary WAF/Bot Management/Rate Limiting per customer. Without it, security policy is uniform across all hostnames on the zone.
Enabling Markdown for Agents on a per-custom-hostname basis, letting individual tenant sites opt into agent-friendly Markdown responses without affecting the whole SaaS zone.
No — current public self-serve pricing is $0.10/hostname/month for additional hostnames beyond the included 100. The $0.50 figure doesn't match current public pricing and should be dropped from SE-facing material.
No — that's useful SE field framing, not an official doc citation. Cloudflare's actual documentation recommends phased migration generally and provides a specific single-hostname "Zero-downtime migration" API runbook — it doesn't name these three patterns as a taxonomy.
Yes — Cloudflare routes based purely on where the customer's DNS CNAME currently points, so this is explicitly supported, not a conflict.