Cloudflare for SaaS custom hostnames: the price, and the DNS record it still needs

Cloudflare bills this product per custom hostname served. The published packaging (per developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/, retrieved 2026-10-06) includes the first 100 hostnames on the Free, Pro and Business zone plans, charges $0.10 per additional hostname per month up to 50,000, and moves volumes beyond that to Enterprise. Worked through, that is:

That is the custom-hostname line only, computed from the published rate. A customer who adds a hostname and never completes setup still counts: per Cloudflare's quotas and billing page, each custom hostname counts toward usage until you delete it, pending ones included. The quota is described as a soft limit, with a separate enforcement threshold on non-Enterprise plans.

Cloudflare says the product is bundled with non-Enterprise plans, and its getting-started guide begins by adding your zone on a Free plan. The zone plan's own price was not retrieved for this page, so the table excludes it; check Cloudflare for what else your account is billed for.

DoDomain is priced on a different unit, which is why the two bills do not overlap. The table below prices three scenarios on each side's own meter: new domains per month for DoDomain, domains live at once for Cloudflare.

List prices, monthly billing. DoDomain counts a domain once, in the month it first verifies; re-checks and drift monitoring are free on every plan, so live domains add nothing. One-click setup starts on Pro — a cheaper plan above is the guided-records flow. Cloudflare's column is the custom-hostname fee only. It excludes the zone plan, Enterprise-only features (custom certificates, wildcard custom hostnames, mTLS), apex proxying or BYOIP, and anything above 50,000 hostnames, which is Enterprise pricing.

DoDomain does not compete with that hostname rate; the point of the table is that the two lines are different, and a product serving 20,000 domains and adding 2,000 a month pays both. See pricing.

Cloudflare for SaaS runs two separate validations, both documented in its own pages. The first proves your customer owns the hostname. That can happen before the routing record exists, using a TXT record or an HTTP token, or in real time once the customer adds the record that points the hostname at your target. Cloudflare notes the real-time path may cause some downtime and that its retries follow a backoff schedule: 75 retries over seven days, after which a hostname that never validates is deleted.

The second is certificate validation. Per Cloudflare the method is http, txt or email, and wildcard certificates require TXT. Each hostname gets two certificates, ECDSA and RSA, with 90-day validity and renewal 30 days before expiry.

Both validations answer one question: may Cloudflare issue and serve this hostname. Neither creates the record in your customer's DNS account, and neither reports next month whether the customer deleted it. The status values give you some of that: a hostname that no longer points at the fallback origin is marked Moved, and a hostname that stays Moved for more than seven days is Deleted. The documented webhooks we found cover certificate events, so a customer breaking their own record reaches you by polling the status or by noticing the traffic stop.

Cloudflare documents a few constraints that shape the integration. Custom hostnames over 64 characters need cloudflare_branding turned on, a hostname equal to your SaaS zone name is not allowed, and hostnames that use another CDN are not compatible. A customer whose domain is already on Cloudflare cannot control Argo, Early Hints, client-side security, Spectrum or wildcard DNS for the managed hostname, and pre-validation is not supported in that case.

The general Cloudflare API limit is 1,200 requests per five minutes per user or account token, and a breach blocks calls for five minutes. We found no custom-hostname-specific limit beyond that. If you onboard in bursts, a queue in front of the hostname-create call is cheaper than learning about the limit in production.

Customers type the bare domain. Cloudflare's normal setup is CNAME-only, and it says that if a customer needs to use an A record you need apex proxying. The plans page row is "Apex proxying/BYOIP", listed as a paid add-on for Enterprise (per developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/, retrieved 2026-10-06). A customer whose DNS provider flattens a CNAME at the apex can still point it at your target, and Cloudflare's own docs describe that as offered through CNAME flattening. So serving acme.com itself is a tier decision only on the IP-based path.

On the DNS side it is not a tier decision at all. Apex records — A, AAAA, TXT and MX at @ — are guided and verified on every DoDomain plan, including Free, and on every connect path. On Pro and Scale the Cloudflare one-click path writes them through the user's own OAuth grant.

Being precise about the apex, because it matters and because it also limits us: a CNAME can never exist at a zone apex — that is RFC 1034 §3.6.2 and RFC 2181 §10.1, not a product decision — and DoDomain does not write the non-standard ALIAS/ANAME records some providers offer instead. What it does is know which providers have that feature, tell your customer the right thing for theirs, and verify the result. The apex guide is the honest, provider-by-provider version.

A proxy's job starts when a request arrives. If your customer edits their zone six months from now and the record stops pointing at you, no request arrives — so the first signal is usually the customer, unless you poll Cloudflare's hostname status.

DoDomain keeps reading authoritative DNS after go-live: every 10 minutes for a connection's first day, then hourly for a week, then every 6 hours, with suspected drift confirmed on three consecutive checks before you are told. connection.failed names the exact failing records; connection.verified fires again with a recovery signal when they come back. Both are HMAC-SHA256-signed and both are on every plan, Free included.

On this page DoDomain gets the record into the customer's DNS and proves it, and Cloudflare serves the traffic. So the record in the session points at Cloudflare's edge through your CNAME target. Cloudflare lets you use a friendlier name such as customers.saasprovider.com as the target, which is a proxied record in your own zone that resolves to your fallback origin. The sample uses that shape, with your own name in place of the placeholder.

Add the custom hostname in Cloudflare first, then mint the session with the same target. The customer never sees Cloudflare's name for your origin, only the one record.

// 1. Your server: mint a connect session for the customer's domain.
import { DoDomain, verifyWebhook } from "@dodomain/node";
import { env } from "./env"; // your validated server env

const dodomain = new DoDomain({ secretKey: env.DODOMAIN_SECRET_KEY });
const session = await dodomain.sessions.create({
  domain: "customer.com",
  records: [
    { type: "CNAME", host: "app", value: "customers.yourapp.com" },
  ],
  returnUrl: "https://yourapp.com/settings/domains",
});

// 2. Your page: open the connect sheet with session.token.
import { showDoDomain } from "@dodomain/connect";

showDoDomain({ token, onVerified: ({ domain }) => markDomainLive(domain) });

// 3. Your webhook route: DoDomain calls it once the record is live at the
//    domain's authoritative nameservers, and again if it ever breaks.
if (!verifyWebhook(env.DODOMAIN_WEBHOOK_SECRET, rawBody, signatureHeader)) {
  return new Response("bad signature", { status: 400 });
}

From Pro up, the session picks the path on its own: a Cloudflare-hosted domain gets the OAuth one-click, a provider that has enabled DoDomain's Domain Connect templates gets a signed apply, and every other provider gets step-by-step records for that provider's dashboard. On the free plan every provider gets the step-by-step records. The full walkthrough is in the quickstart.

The integration is small because the handoff is narrow. Add the custom hostname in Cloudflare for SaaS as you already do; take the record values Cloudflare tells you the customer must create; pass exactly those records to POST /api/v1/sessions and hand your user the returned connectUrl — a hosted page, or the @dodomain/connect widget embedded in your own onboarding.

Your customer then gets a real path instead of a record to copy: if their domain is on Cloudflare, a scoped OAuth approval on Cloudflare's own page writes it; if their provider has enabled our Domain Connect templates, a signed one-click apply writes it; otherwise they get their provider's dashboard link, its host-field quirks, and a live status per record.

When the signed connection.verified webhook reaches your server, the records are confirmed live at the domain's authoritative nameservers — that is your cue to activate the tenant. One-click setup starts on Pro; on Free the same session produces guided records.

• You need HTTPS on customer domains and have no edge: Cloudflare for SaaS is the cheapest published way in, and DoDomain does not replace it.
• Your customers' domains are already in your own Cloudflare account: the DNS step is yours to make and there is nothing to guide.
• Self-serve customers arrive on many registrars and stall at the record: add DoDomain. Keep Cloudflare for SaaS exactly as it is.
• You only onboard a handful of enterprise customers a year: a support engineer on a call is cheaper than any vendor.

The two run side by side with no shared state. If you later move off Cloudflare for SaaS, change the record value in your session payload and DoDomain guides the same customers through the new one.

On price, first. It publishes a low per-hostname rate, includes the first 100 hostnames, and the cost of getting started is a Free zone plus the hostname fee. DoDomain does not serve traffic, so there is nothing to weigh against it on that axis.

It runs on Cloudflare's own network, with WAF for SaaS under the current zone plan on the self-serve tiers and custom firewall rulesets on Enterprise. Per-hostname analytics, Argo, caching and Early Hints for SaaS exist as documentation sections, and a per-hostname custom origin is available on every plan.

Its documentation is deep. It covers certificate validation, the retry backoff, custom origins, custom certificates, certificate authority choice and a published API rate limit. Enterprise adds custom certificates, CSR support, wildcard custom hostnames and mTLS. It documents certificate-lifecycle events and per-hostname analytics.

Honest flip side. If your customers' domains are already inside your own Cloudflare account, the DNS step is yours to make and there is nothing to guide. If you only onboard a handful of enterprise customers a year, a support engineer on a call solves this more cheaply than any vendor. And if the record your customers must create is genuinely one CNAME on a provider they all share, a good copy-paste screen may be enough.

DoDomain earns its place when self-serve customers arrive on 20 different registrars and the DNS step is where they stall — and it never asks you to move traffic to find out, because it is never in the request path.

No card, no sales call — create an app, mint a session, and watch the first domain verify.

• Every custom-domain option compared
• Entri alternative
• customdomain.ai alternative
• DoDomain vs Domainee
• DoDomain vs SaaSKevin
• DoDomain vs SaaS Custom Domains
• With Approximated
• State of Domain Connect: which DNS providers support one-click