Skip to content

getting-started.mdx

Latest commit

 

History

History
110 lines (74 loc) · 3.94 KB

getting-started.mdx

File metadata and controls

110 lines (74 loc) · 3.94 KB
Raw
title Configuring Cloudflare for SaaS
pcx_content_type get-started
products
cloudflare-for-saas
sidebar
order
2
head
description Get started with Cloudflare for SaaS

import { Example, Render } from "~/components";

<Render file="get-started-prereqs" params={{ one: "on a Free plan." }} product="cloudflare-for-platforms" />

Initial setup


1. Create fallback origin

2. (Optional) Create CNAME target

The CNAME target — optional, but highly encouraged — provides a friendly and more flexible place for customers to route their traffic. You may want to use a subdomain such as customers.<SAAS_PROVIDER>.com.

Create a proxied CNAME that points your CNAME target to your fallback origin (can be a wildcard such as *.customers.saasprovider.com).

Type Name Target Proxy status
CNAME .customers proxy-fallback.saasprovider.com Proxied

Per-hostname setup

Check when a custom hostname is ready

A custom hostname uses separate validation flows for hostname activation and certificate issuance.

API field What it means Ready value
result.status Cloudflare has validated the hostname and can proxy traffic for it. active
result.ssl.status Cloudflare has issued and deployed the certificate for the hostname. active

Treat a custom hostname as ready for production traffic when:

  • result.status is active.
  • result.ssl.status is active.
  • The hostname's DNS record points to your SaaS target.

A successful TLS handshake can happen before result.ssl.status changes to active if Cloudflare can present another matching certificate. Use the Custom hostname details endpoint as the source of truth for onboarding state. For more information, refer to Certificate and hostname priority.

3. Have customer create CNAME record

To finish the custom hostname setup, your customer needs to set up a CNAME record at their authoritative DNS that points to your CNAME target 1.

Your customer's CNAME record might look like the following:

mystore.example.com CNAME customers.saasprovider.com

This record would route traffic in the following way:

flowchart TD
accTitle: How traffic routing works with a CNAME target
A[Request to <code>mystore.example.com</code>] --> B[<code>customers.saasprovider.com</code>]
B --> C[<code>proxy-fallback.saasprovider.com</code>]
Loading

Requests to mystore.example.com would go to your CNAME target (customers.saasprovider.com), which would then route to your fallback origin (proxy-fallback.saasprovider.com).

:::caution If your customer needs to use an A record to point to the SaaS target, you will need to get apex proxying. By default, using an A record to point to the target is not a supported setup. :::

Service continuation

Footnotes

  1. ↩