Cloudflare for SaaS: custom hostnames, customer SSL and pricing explained
How Cloudflare for SaaS puts your customers' own domains on your app with managed certificates, and what it costs at 50, 500 and 5,000 hostnames.
You run a SaaS product, and a customer asks to reach their account at app.theircompany.com instead of theircompany.yourapp.com, with a valid padlock in the browser. Then ten more customers ask. Cloudflare for SaaS is the Cloudflare feature built for this: it accepts traffic for your customers’ domains, gets a TLS certificate for each one and forwards the requests to your application.
Custom domains are one of the first “enterprise” requests a young SaaS product receives, because a customer’s brand on the address bar matters to them. This guide explains the moving parts, the setup and the price. For the bigger picture of how a request travels from a browser to a SaaS vendor’s servers, see SaaS in cloud computing; for the basic model, What is SaaS?.
Custom hostnames in plain terms
Think of the reception desk in a shared office building. Letters arrive addressed to forty different companies, and the desk accepts all of them, checks each one, and carries it to the right floor. Nobody outside needs to know that the forty companies share one building.
Cloudflare for SaaS is that desk for web traffic. The vocabulary is short:
- Custom hostname: a domain your customer owns, such as
app.theircompany.com, that you add to your own Cloudflare zone. - Fallback origin: the server where Cloudflare sends traffic for all custom hostnames by default. Cloudflare’s documentation says custom hostnames “are routed to a default origin server called fallback origin.”
- CNAME target: a hostname on your domain, such as
customers.yourapp.com, that your customers point their DNS at. - Domain control validation (DCV): the check a certificate authority runs to confirm the domain really points at you before it issues a certificate.
The customer keeps their domain and their DNS provider. They add one record. You do the rest from your Cloudflare account or its API.
How the setup works
Cloudflare’s getting started guide describes four steps, in this order.
- Create the fallback origin. Add a proxied DNS record (A, AAAA or CNAME) that points at your application, and mark it as the fallback origin. The docs say it “must be proxied.”
- Create a CNAME target. Add a proxied CNAME, often a wildcard such as
*.customers.yourapp.com, that points at the fallback origin. Cloudflare calls this step “optional, but highly encouraged,” because it gives customers a stable name to point at. - Add the custom hostname. In the dashboard or through the API, enter the customer’s hostname and choose options such as the minimum TLS version and the validation method.
- Ask the customer to add a CNAME. At their DNS provider, the customer points
app.theircompany.comto your CNAME target.
Before the customer switches DNS, check that the hostname’s status and its SSL status both read active. Switching earlier sends their users to a page with a certificate error.
Who handles the certificates
You have two options, per Cloudflare’s certificate management page. Cloudflare can manage “all the certificate issuance and renewals on your behalf,” or you can upload certificates you already hold when you need to control the private keys.
With managed certificates, the certificate authority still has to validate each domain. The API offers three methods: http, txt and email. HTTP validation works once the hostname already points at your CNAME target. TXT validation means the customer adds a DNS text record, and it is required for wildcard hostnames. A third option, delegated DCV, has the customer add a one-time DNS record so that future renewals validate without them (validation methods).
The choice shapes your onboarding email. HTTP validation asks the customer for one record, but only after they point their domain at you. TXT validation asks for two records, but you can have the certificate ready before the switch.
What it costs
Cloudflare publishes the price on its plans page, as of October 2026:
| Zone plan | Custom hostnames included | Each additional hostname | Maximum |
|---|---|---|---|
| Free, Pro, Business | 100 | $0.10 | 50,000 |
| Enterprise | Custom | Custom pricing | Unlimited (contact sales above 50,000) |
So the price is $0.10 per additional custom hostname (Cloudflare plans page), on top of whatever plan your zone is on. The plans page does not state a billing period for that fee, so check how it appears on your own Cloudflare invoice before you budget.
Example: every customer of your SaaS product uses one custom hostname. On a Free, Pro or Business zone, the first 100 hostnames are included and each one after that is $0.10:
| Customers with a custom domain | Billable hostnames | Hostname fee | Fee averaged over all customers |
|---|---|---|---|
| 50 | 0 (inside the 100 included) | $0 | $0 |
| 500 | 500 - 100 = 400 | 400 x $0.10 = $40 | $40 / 500 = $0.08 |
| 5,000 | 5,000 - 100 = 4,900 | 4,900 x $0.10 = $490 | $490 / 5,000 = $0.098 |
The average fee per customer approaches $0.10 as you grow, because the 100 free hostnames matter less each time. At 5,000 customers it is just under 10 cents per customer, whatever the billing period turns out to be on your invoice. The real limits are elsewhere. Above 50,000 hostnames you need an Enterprise contract, and each hostname adds support work when a customer’s DNS is wrong.
When to use it, and the alternatives
Cloudflare for SaaS fits when you have, or expect, dozens to thousands of customer domains and do not want to run certificate issuance yourself. It also puts Cloudflare’s network in front of every customer domain, which is the “reception desk” doing its other job: filtering traffic before it reaches your servers.
You have other routes. You can run your own reverse proxy and request certificates from a public certificate authority such as Let’s Encrypt through the ACME protocol. Several CDNs and hosting platforms sell their own custom-domain features. The trade-off is the usual one for a SaaS buyer: a per-unit fee in exchange for not owning the operational work. With fewer than 100 custom domains on a Cloudflare zone, the per-hostname fee is zero, so the question is mostly about lock-in and operations, not cost.
Common mistakes
- Adding your own zone name as a custom hostname. Cloudflare’s docs say plainly: “Do not configure a custom hostname which matches the zone name.” Why it happens: you test with your own domain first. Instead: test with a second domain you own.
- Telling the customer to switch DNS too early. Their users see a certificate warning until validation finishes. Why it happens: the onboarding email lists the CNAME first. Instead: wait until both statuses read
active, or use TXT or delegated validation so the certificate exists before the switch. - Choosing HTTP validation for a wildcard. Wildcard hostnames require TXT validation. Why it happens: HTTP is the default you clicked through. Instead: decide per hostname type, and document it in your onboarding guide.
- Leaving hostnames of departed customers in place. You keep paying for them, and a customer domain that still points at you after they leave is a support and security loose end. Why it happens: offboarding scripts delete the account, not the hostname. Instead: remove the custom hostname in the same offboarding step and tell the customer to remove their CNAME.
Sources
- Cloudflare, Cloudflare for SaaS: plans, checked October 2026.
- Cloudflare, Get started with Cloudflare for SaaS, checked October 2026.
- Cloudflare, Certificate management and Validate certificates, checked October 2026.
In three sentences
Cloudflare for SaaS lets your customers point their own domains at your application while Cloudflare validates, issues and renews a certificate for each one. Setup is a fallback origin, a CNAME target, one custom hostname per customer and one DNS record on the customer’s side. On Free, Pro and Business zones the first 100 hostnames are included and each extra one costs $0.10, so 5,000 customer domains mean 4,900 billable hostnames and a $490 fee.
