Why the Design Phase is Non-Negotiable
We live in a world obsessed with instantaneous results. With AI becoming so prevalent can we afford to skip the design phase?
Eamon McKiernan
Recent Learnings in Cloudflare, Next.js and Headless Architecture
On paper, pairing Cloudflare with Next.js and a modern Headless CMS sounds like the ultimate agency stack: blazing-fast edge performance, ironclad security, and total flexibility. Recently we have been playing around with this theory, here are our findings.
Eamon McKiernan
In production a single misconfigured proxy rule or WAF toggle can bring down your website.
After migrating and hardening a dozen production environments across Cloudflare, Vercel, DigitalOcean, AWS and decoupled CMS setups, we’ve documented the exact friction points—and how to engineer around them.
The "Orange Cloud" vs. "Grey Cloud" Proxy Rules
The iconic Cloudflare "Orange Cloud" (Proxy On) promises instant DDoS protection, web application firewalling, and CDN caching. But toggling it blindly across every DNS record is one of the fastest ways to break your client's integrations.
The SSL Validation Trap
Many third-party platforms—such as HubSpot, Mailgun, or Figma Sites—require your client to point a CNAME or A record to their servers. These platforms then automatically issue and renew SSL certificates on your behalf.
If you proxy these records, Cloudflare masks the origin server behind its own IP pool. The third-party platform's automated certificate manager can no longer reach the true origin to validate domain ownership resulting in the third-party endpoint dropping offline.
Rule of Thumb: If a third-party manages its own SSL for a subdomain, keep that DNS record Grey Clouded (DNS Only) unless the provider explicitly supports Cloudflare CNAME flattening or custom proxy setups.
Vercel Best Practice
When running Next.js on Vercel behind Cloudflare, the standard recommendation is to keep DNS records unproxied. To run Cloudflare in front of Vercel securely:
- Create a CNAME pointing your root or subdomain to Vercel's DNS target (
cname.vercel-dns.com). - Toggle the Cloudflare proxy ON.
- Accept that Vercel and Cloudflare are competitors and Vercel will permanently throw an “Invalid Configuration” error.
As long as your Cloudflare SSL is set to Full (Strict), the site will work perfectly, but Vercel will complain about it in the UI.
Preventing the Infinite Redirect Loop
The dreaded ERR_TOO_MANY_REDIRECTS error almost always stems from a mismatch between Cloudflare's edge SSL setting and your origin server's HTTPS enforcement.
If Cloudflare’s SSL/TLS mode is set to Flexible, Cloudflare connects to your origin server (Vercel or your CMS) via unencrypted HTTP. However, modern frameworks like Next.js and Headless CMS engines automatically detect HTTP requests and issue a 301 Redirect to upgrade the connection to HTTPS.
Cloudflare receives this redirect, attempts to fetch the HTTP page again, and triggers an infinite loop.
- The Fix: Always set Cloudflare’s SSL/TLS encryption mode to Full (Strict) before enabling the Orange Cloud. This forces Cloudflare to encrypt traffic end-to-end and present a valid, trusted SSL certificate at the origin.
Next.js 16 Interception
When you put Cloudflare in front of your Next.js website, Cloudflare acts like a middleman. Because of this, Next.js can get confused and mistake Cloudflare for the actual visitor—hiding the real user’s location and IP address.
To fix this, you just need a small helper file (like a proxy.ts or middleware file) right at the "front door" of your app. This file catches the visitor information coming from Cloudflare, translates Cloudflare's unique labels into standard web labels, and passes them along so the rest of your app can read them.
By translating Cloudflare's special label (cf-connecting-ip) into a standard web label (x-forwarded-for) as soon as traffic arrives, your security rules, visitor analytics, and app features will work accurately without locking your code permanently to Cloudflare.
By mapping cf-connecting-ip to x-forwarded-for at the application entry point, your server actions, rate-limiters, and analytics tools continue to function accurately without deep framework coupling to Cloudflare-specific APIs.
Finding the "Goldilocks" WAF Configuration (Cloudflare Pro)
Cloudflare’s Web Application Firewall (WAF) is immensely powerful, but running it on its default or maximum aggressiveness settings will inevitably break legitimate application features. Here is how to find the sweet spot for agency client builds.
The sweet settings
Super Bot Fight Mode
• Definitely Automated Traffic: Block
• Static Resource Protection: Off
OWASP Core Ruleset
• Paranoia Level: Level 1 (PL1)
• Anomaly Score Threshold: 40 (Prevents false XSS)
Custom Bypass Rules
• Uptime Monitor User-Agents: Skip WAF (Prevents false down-alerts)
Super Bot Fight Mode: The Static Resource Trap
Toggling Super Bot Fight Mode on Cloudflare Pro plan environments slashes bad actor server load instantly.
Set Definitely Automated Traffic to Block. This drops malicious scrapers, vulnerability scanners, and automated credential-stuffing bots before they hit your origin CPU.
However, leave "Static Resource Protection" turned OFF.
If Static Resource Protection is enabled, Cloudflare evaluates automated requests attempting to fetch static assets (.jpg, .png, .svg, .css). This creates two major agency headaches:
- Broken Social Previews: OpenGraph scraping bots from Slack, LinkedIn, iMessage, and Twitter will be challenged or blocked when attempting to fetch link preview images.
- Missing Email Assets: Email clients (like Apple Mail or Outlook proxy servers) fetching newsletter logos or hero images hosted on your domain will be blocked, causing images to render as broken icons in client inboxes.
Fixing Uptime Monitor False Alarms
Nothing destroys client trust faster than getting an emergency notification that a site is down when it's actually completely healthy.
When you enforce strict bot rules, global uptime monitoring services (like Better Stack, Datadog, Pingdom, or UptimeRobot) will inevitably trigger bot defenses from their regional scanning nodes (particularly from European or Asian data centers). Cloudflare issues a JS Challenge or 403 block to the monitor, triggering a false "Site Down" critical alert.
- The Solution: Create a dedicated Custom WAF Rule at the top of your rule stack:
- Field:
User Agent - Operator:
contains - Value: Your uptime monitor’s unique User-Agent string (e.g.,
BetterStack/1.0) - Action:
Skip→ SelectWAF Managed RulesandSuper Bot Fight Mode.
- Field:
This creates a targeted security exception for your monitoring infrastructure without opening a wide IP hole in your firewall.
Summary: The Hardened Stack
Hardening Cloudflare in front of modern Next.js and Headless CMS applications isn't about toggling every security switch to maximum—it's about understanding the boundary between the edge, your application code, and third-party integrations.
By strictly adhering to these baseline rules:
- Enforce Full (Strict) SSL and use
_vercelTXT verification for CNAME proxying. - Explicitly restrict trusted proxies to verified Cloudflare IP ranges.
- Intercept edge headers using a root
proxy.tslayer in Next.js 16. - Tune WAF rules (PL1, Anomaly Threshold 40) and disable Static Resource Protection to keep social previews and CMS workflows functional.
...you eliminate the vast majority of edge deployment failures before they reach production. Investing the time to standardize these edge rules across your agency boilerplate will save your engineering team hundreds of hours in emergency DevOps support down the line.
