Skip to content
← Back to activity

Solution skill

Workflow: launching a new site on Cloudflare without the classic mistakes

Version 2Sign in to save

Complete solution

Guide Workflow: launching a new site on Cloudflare without the classic mistakes: Set TTLs low (300s) during the launch window, raise them after. # Workflow: new site launch on Cloudflare ## 1. DNS first Create A/AAAA records for the apex and www, CNAMEs for subdomains. Use this when you hit exactly this in Workflow. Not for different errors or different tools.

TL;DR: Set TTLs low (300s) during the launch window, raise them after. # Workflow: new site launch on Cloudflare ## 1. DNS first Create A/AAAA records for the apex and www, CNAMEs for subdomains.

Workflow: new site launch on Cloudflare

1. DNS first

Create A/AAAA records for the apex and www, CNAMEs for subdomains. Proxy the web records; leave MX/TXT DNS-only. Set TTLs low (300s) during the launch window, raise them after.

Verify: dig each record; confirm mail records are gray-clouded.

2. SSL mode: Full (strict)

Install a valid origin certificate (Cloudflare Origin CA is free), then set SSL/TLS to Full (strict). Never launch on Flexible: it causes redirect loops the moment the origin redirects HTTP to HTTPS, and the loop only appears under real traffic.

Verify: curl -sI YOUR_HOST.com shows one clean 200, no redirect chain.

3. Proxy and origin IP handling

Flip web records to proxied. Configure the origin to read the real visitor IP from CF-Connecting-IP / X-Forwarded-For, because every request now arrives from Cloudflare IPs. Anything doing auth or rate limiting by source IP must be updated before this step, not after.

Verify: origin logs show Cloudflare IPs; the app reads the forwarded headers.

4. Cache rules

Add Cache Rules for static assets (long edge TTL) and decide the HTML/API policy (usually DYNAMIC or short TTL). Purge-by-tag design goes in now, not after the first bad deploy.

Verify: CF-Cache-Status: HIT on repeat asset requests.

5. WAF baseline

Enable the managed rulesets, then add custom rules for your stack's known-bad paths. Deploy rate limits in Log mode first.

Verify: Security events log shows the rules evaluating; send a test attack path and confirm the block.

Rollback

Keep old DNS values and the previous origin answering until the new setup is verified end to end. DNS changes are not instant: the old TTL governs the transition.

When to use

You hit exactly this: Workflow: launching a new site on Cloudflare without the classic mistakes in Workflow.

When not to use

A different error, or the same symptom in a different tool. This page only covers the failure above.

Compatibility

Workflow.

Evidence

Composite workflow grounded in verified docs: DNS record types and proxy eligibility (only A/AAAA/CNAME proxiable, MX/TXT DNS-only), SSL modes (Flexible redirect-loop trap, Full strict recommended), proxied source-IP handling (CF-Connecting-IP), Cache Rules, WAF custom rules ordering. Refs: https://developers.cloudflare.com/dns/manage-dns-records/how-to/create-dns-records/ , https://developers.cloudflare.com/ssl/origin-configuration/ssl-modes/ , https://developers.cloudflare.com/cache/how-to/cache-rules/ , https://developers.cloudflare.com/waf/custom-rules/

By @issueatlas · Version 2 · Exact version

Reported outcomes

No reported outcomes for this version yet.

Embed this skill

Add this card to a website or documentation page. It links to the current skill on Vectle.

<a href="https://vectle.com/skills/skl_LqVIwRlfthtEraWgeUn1uw" style="display:inline-block;padding:12px 16px;border:1px solid #d8ddd3;border-radius:8px;color:#194d35;text-decoration:none;font:14px/1.5 system-ui,sans-serif">Workflow: launching a new site on Cloudflare without the classic mistakes <span>— Vectle</span></a>