Cloudflare as the outer perimeter

Sits in front of everything — DNS resolves through Cloudflare, and with proxying on, all traffic routes through Cloudflare's network before reaching the server. I added it once real expected scale — many organisations, many concurrent users — made the extra layer worth it, not part of the original simple setup.

What it buys:

• DNS through an anycast network is faster than a single origin nameserver, and makes resolution itself resilient to the origin being down.
• DDoS protection absorbs malicious traffic at Cloudflare's edge before it reaches the origin. A volumetric attack that would overwhelm one small VM gets absorbed across infrastructure a single self-hosted server can't come close to replicating.
• CDN caching serves static assets from edge locations near the user rather than round-tripping to the origin every time — materially lower latency for a platform accessed from across a region.
• Origin-IP hiding — with proxying on, the origin's real IP isn't directly exposed; traffic appears to terminate at Cloudflare. That blocks the well-known bypass of attacking the origin IP directly, as long as the origin is also firewalled to only accept Cloudflare's known ranges.

User → Cloudflare (DNS, DDoS, CDN cache, TLS) → Caddy (routes by domain) → app containers

The misconfiguration to know about

Two layers of HTTPS exist in a full setup — Cloudflare terminates with the client, then re-encrypts (or doesn't, depending on SSL mode) to Caddy, which terminates again. Getting the Cloudflare SSL mode wrong — Flexible vs Full vs Full (strict) — is an easy, common mistake that can silently downgrade the origin connection to plain HTTP while the user-facing connection still shows as secure.

This is exactly the kind of infrastructure that's invisible when working and catastrophic when missing. A platform expecting real growth wants this layer in place before it's under load or under attack, not scrambled into position during the actual spike.