# Cloudflare Connect

> Use Cloudflare Connect when StaticX should create DNS for a single site domain or make a customer domain the default for future site URLs.

Canonical: https://staticx.site/documentation/cloudflare-connect

Cloudflare Connect

## Let StaticX create DNS after the domain owner approves access.

 Cloudflare Connect is optional. Manual DNS still works with any provider and shows one CNAME record. Use Cloudflare Connect when the domain is already managed in Cloudflare and the owner wants StaticX to create the needed records automatically.

 

  How it works

## Three connect flows.

 

Step 01

### Single site domain

From Site → Settings → Domain, enter the custom domain and choose **Connect Cloudflare**. StaticX asks for DNS access, detects the matching domain automatically, and creates one exact CNAME for that site.

 

Step 02

### Publishing domain

From Settings → Publishing domain, connect a domain such as `example.com`. New sites can then use addresses like `site.example.com`. Existing site URLs stay unchanged.

 

Step 03

### Agents stay honest

API, CLI, and MCP flows cannot silently authorize Cloudflare. They should return manual DNS instructions or ask the user to approve Cloudflare Connect in the dashboard.

 

 

  Exact domains

## Exact custom domains

 Exact domains are the simplest flow. The user enters `app.example.com` or `www.example.com`. StaticX either returns one CNAME record for manual setup or, after Cloudflare authorization, creates that one CNAME in the matching zone.

 

 | Choice | What the user does | What StaticX does |
|---|---|---|
| Set up manually | Copies the one DNS record shown by StaticX. | Monitors DNS and activates SSL once the record points correctly. |
| Connect Cloudflare | Authorizes DNS access in the browser after entering the exact domain. | Detects the matching Cloudflare domain, creates one exact CNAME, and keeps the site domain status updated. |

  Publishing domains

## Publishing domains for new site URLs

 A publishing domain changes the default domain used when StaticX creates future site URLs. If the account enables `example.com`, new sites can be created as `launch.example.com` or `client.example.com`. Existing sites keep their current URLs until they are changed individually.

 After a publishing domain is active, each site can also switch its free subdomain between the StaticX default domain and any active publishing domain from **Site → Settings → Domain**. The subdomain label is unique per domain, so `launch.staticx.store` and `launch.example.com` can both exist, but two sites cannot share `launch.example.com`.

 

 Publishing domains require the domain to be active in Cloudflare because StaticX installs managed routing for generated subdomains. This avoids asking the user to create a DNS record for every future site. Switching back to the StaticX default only affects future site URLs; existing sites keep their current hosts until changed individually.

 

  What changes

## What StaticX changes

 StaticX keeps the two domain flows separate so permissions stay narrow and the UI stays predictable. A single site domain only needs one exact CNAME. A publishing domain needs managed wildcard routing so future generated subdomains can work without another DNS setup step.

 

 | Flow | Created by StaticX | Used for |
|---|---|---|
| Single site domain | One exact CNAME for the requested host. | Replacing one site’s generated `staticx.store` address. |
| Publishing domain | Managed wildcard DNS and routing resources in the selected zone. | Creating future sites as `site.example.com`, and letting existing sites move their generated subdomain onto that suffix from the site Domain tab. |

  Permissions

## Permissions and safety

 StaticX never asks for a Global API Key. The browser authorization uses the smallest configured Cloudflare OAuth scope for the selected job: DNS-only for exact site domains, and DNS plus routing permissions for publishing domains.

 

- StaticX-managed records are reused or updated safely.
- Existing customer-owned DNS records are not overwritten automatically.
- Disconnecting Cloudflare access does not remove live site URLs by itself.
- Deleting a StaticX-managed domain can optionally remove the DNS setup StaticX created.
- The user can revoke Cloudflare access from Cloudflare at any time.
 
  Operators

## Environment variables for operators

These values are server-side only. Never expose the OAuth client secret to browser code, public docs, MCP config, or agent prompts.

 

 ```
CLOUDFLARE_OAUTH_CLIENT_ID=
CLOUDFLARE_OAUTH_CLIENT_SECRET=
CLOUDFLARE_OAUTH_REDIRECT_URI=https://staticx.site/settings/domains/cloudflare/callback
CLOUDFLARE_OAUTH_SCOPES=
CLOUDFLARE_OAUTH_DOMAIN_DNS_SCOPES=
CLOUDFLARE_OAUTH_PUBLISHING_DOMAIN_SCOPES=
STATICX_EDGE_UPSTREAM_URL=https://fallback.staticx.store
STATICX_CLOUDFLARE_WORKER_PREFIX=staticx-proxy
```

Use `php artisan cloudflare:oauth-scopes` during setup to inspect available Cloudflare OAuth scopes for the connected application.

  Limitations

## Limitations

 Cloudflare Connect only works for domains managed in the customer’s Cloudflare account. Exact custom domains can still use manual DNS with any provider. Publishing domains are intentionally Cloudflare-only because StaticX has to route arbitrary future subdomains safely. CLI, API, MCP, and LLM instructions should not claim that they can complete Cloudflare authorization without the browser approval step.

[View on staticx.site](https://staticx.site/documentation/cloudflare-connect)