Cloudflare for SaaS: Enterprise Controls for Custom Hostnames
Cloudflare for SaaS, launched in beta earlier this year, extends the company's full product suite to any provider that wants to wrap Cloudflare's edge around its own customers. The core of that offering—SSL for SaaS—handles the Public Key Infrastructure (PKI) heavy lifting so SaaS providers don't have to issue or manage certificates for every end customer.
Today, the company is rolling out a set of Enterprise-grade enhancements to both Cloudflare for SaaS and SSL for SaaS, aimed at giving providers more granular control over routing, IP allocation, certificate handling, and per-hostname behavior.
Solving the Apex Problem
The typical SaaS onboarding flow has a customer point a CNAME record at a subdomain owned by the SaaS provider. That lets the provider change backend IPs without asking the end customer to update anything. But CNAME records cannot coexist with other DNS records at the zone apex (per RFC 1912), which forces most customers to use a subdomain like www.example.com rather than example.com—unless their DNS provider supports CNAME flattening.
Since SaaS providers have no control over their customers' DNS providers, Cloudflare has introduced Apex Proxying. This SSL for SaaS feature allocates a dedicated set of IP addresses to the SaaS provider, who passes them to customers as A or AAAA records. End customers can then proxy traffic from the apex of their zone without needing CNAME support.
Bring Your Own IPs for SaaS
For customers who want more flexibility than a single static IP pair, Cloudflare's existing Bring Your Own IP (BYOIP) offering can be extended to SaaS use cases. BYOIP lets a provider bring its own IP range to be announced at Cloudflare's edge, then allocate that entire range across multiple custom hostnames.
Rather than being limited to a handful of addresses, a provider can distribute all 256 IPs in its range—grouping customers or assigning dedicated IPs per customer as needed.
Per-Customer Origin Routing
By default, all custom hostnames route to a single fallback origin. Enterprise customers now have the option to designate a custom origin—an IP address or load balancer defined in the zone—for any individual custom hostname. This previously required emailing an account manager to request custom edge logic. It's now configurable directly in the UI or via the API, giving providers the ability to group customers by origin or scale application infrastructure independently.
Wildcard Custom Hostnames
Many end customers want protection not just for their root domain but for everything beneath it. Cloudflare for SaaS now supports wildcard custom hostnames, which extends a hostname's configuration from something like blog.example.com to the next level of subdomains, such as *.blog.example.com.
Enterprise customers can enable wildcard support by checking a box when creating a custom hostname in the dashboard or by setting wildcard: "true" in the API request.
More Control Over TLS Certificates
SSL for SaaS was built to eliminate certificate lifecycle management for providers, but "one size fits all" is rarely the case in enterprise TLS. Cloudflare has added options for customers who need to retain control over key material or must use a specific certificate authority.
CSR Support and Custom Certificates
Providers that can't allow Cloudflare to generate private keys on their customers' behalf—common in industries like banking with strict CA requirements—can now upload a customer's certificate directly to a custom hostname with a single API call.
Alternatively, providers can generate a Certificate Signing Request (CSR) for a custom hostname, use it to order a certificate from their own or their customer's CA, and then upload the resulting certificate for use at Cloudflare's edge. This lets the provider keep private key material out of the hands of its own staff while still supporting the CAs its customers demand.
Custom Metadata for Per-Hostname Logic
Providers that need hostname-specific behavior can add custom metadata to an individual custom hostname and then read that data from a Cloudflare Worker. Common use cases include attaching a customer_id field to each hostname to forward in a request header to the origin, or setting headers like HSTS on a per-customer basis.
What's Next
Cloudflare plans to announce new analytics capabilities tomorrow, which will give providers deeper visibility into their customers' traffic and a way to share that data back with the end customers. Enterprise customers interested in any of these features should contact their account team for access.
