Documentation

Custom tracking hostnames (not built) guide

A custom tracking hostname would let a customer CNAME stats.customer.com to AnalyticFast and collect on that name with a certificate we do not have to issue by hand. The Cloudflare product for that is Cloudflare for SaaS (custom hostnames). It is not simple, and this workstream does not implement it. No API client, schema, or dashboard for it was added. Customers who need to dodge blockers should use a first-party rewrite instead: Cloudflare Worker, Vercel and Netlify, or Next.js.

What the product actually requires

Checked 2026-10-26 against:

• Overview: https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/
• Getting started (updated 2026-06-19): https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/start/getting-started/
• Plans (updated 2026-08-14): https://developers.cloudflare.com/cloudflare-for-platforms/cloudflare-for-saas/plans/
• Create custom hostname API: https://developers.cloudflare.com/api/resources/custom_hostnames/methods/create/

Setup is per SaaS zone, then per customer hostname:

1. Add a zone and enable Cloudflare for SaaS.
2. Create a proxied DNS record and designate it as the fallback origin. Traffic for every custom hostname goes there unless a custom origin is set.
3. Optionally add a CNAME target such as customers.example.com for customers to point at.
4. For each hostname, choose certificate validation and hostname validation, create the custom hostname, and poll until both status and ssl.status are active. The create response often omits the DCV token; the docs say to GET the hostname again.
5. The customer creates a CNAME to the target. Apex records are not supported unless Enterprise apex proxying is purchased. Wildcard custom hostnames are Enterprise-only.

A hostname is not ready when the TLS handshake happens to succeed. The docs say production traffic should wait for both status fields plus DNS.

That is an onboarding state machine (pending validation, active, moved, deleted), a fallback origin we operate, certificate renewal, and a Worker route that trusts the Host header and maps it to a site. None of that exists in this codebase. The domain allowlist today is the page URL inside the event, not the request host.

Price

The plans table lists, for Free, Pro and Business:

The table does not print a billing period next to $0.10. This note does not assume one. Enterprise adds wildcard hostnames, custom certificates, a selectable CA, and apex proxying as a paid add-on.

100 hostnames would cover an early install. Past that, 400 extra hostnames are 400 × $0.10 on the published unit price, before the zone plan itself. The cap at 50,000 is a product limit, not just a bill.

Why it stays a recipe gap

• wrangler.jsonc is lead-owned. Turning this on also needs a Cloudflare zone, a fallback origin, and API tokens that are not Worker bindings we can add here.
• Each customer hostname needs validation polling, failure handling, and deletion when a site is removed. That is new schema and a cron, plus a public onboarding step.
• The collector would have to accept events because of the request Host, which is a second allowlist and a new way to attach traffic to the wrong site if a hostname is reused.
• Apex and wildcard names are Enterprise-only, so the common "tracking.customer.com" case is the only one a non-Enterprise zone can do, and customers still have to edit DNS.
• A path rewrite on the customer's own platform solves the same ad-blocker problem without us holding their certificates.

Do not add custom hostnames until a lead explicitly takes the zone, the API token, and the hostname lifecycle.