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

# 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 https://example.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.