Frank
My Go-To Providers · Part 3 of 3Every request that touches anything I run hits Cloudflare first. Before my Hetzner box even knows there’s traffic coming, Cloudflare has already inspected it, decided whether to pass it through or slam the door, and in some cases answered it entirely without bothering the origin server at all. That’s not an accident, that’s the whole point.
I didn’t plan to go this deep with Cloudflare. I started with free DNS management because I was cheap and their nameservers were fast. Then I noticed I could get SSL for nothing. Then I found Workers. Then Pages. Each feature pulled me one step further in until one day I looked up and realized Cloudflare was doing more heavy lifting for my stack than I ever consciously decided to give it. That’s the highest compliment I know how to pay a piece of infrastructure.
One Registrar, One DNS Panel, Zero Chaos
I used to scatter domains across whatever registrar had the best coupon code that month. Namecheap for some, Google Domains for others, a couple strays living at GoDaddy from decisions I’d rather not explain. Managing DNS across four different dashboards while debugging a misconfigured subdomain at midnight is a special kind of misery.
Cloudflare fixed that by being both cheap and the best DNS management tool I’ve ever used. They sell domains at cost, no markup, no dark patterns, no “privacy protection” upsell that should’ve been free to begin with. Now everything lives in one account. Every domain, every subdomain, every A record and CNAME and MX entry I care about is in the same place, editable from the same interface, auditable from the same change log.
The DNS propagation speed matters too. Changes I make in the Cloudflare dashboard resolve in seconds to a minute or two. Not hours. When I’m deploying something new or fixing a routing mistake, that speed is the difference between a quick fix and a long night.
I keep my DNS records clean and documented by habit now, something the old multi-registrar mess never encouraged. When everything’s in one panel, you actually look at it. You notice the orphaned CNAME pointing at a service you cancelled eight months ago. You clean it up. The discipline follows the tooling.
SSL Termination and the Perimeter I Don’t Have to Think About
Before Cloudflare, SSL was a chore I didn’t handle well. Certbot renewals that worked until they didn’t. Certificates that expired because I forgot to check. One time a cron job failed silently and a project I was proud of spent a weekend throwing browser warnings at the three people who visited it. Not my finest hour.
Now Cloudflare terminates SSL at the edge, full stop. Every domain on my account gets HTTPS automatically. I set the SSL/TLS mode to Full (Strict) on anything that matters, that means the connection between the browser and Cloudflare is encrypted, and so is the leg between Cloudflare and my Hetzner origin. I provision a certificate on the origin too, either a Cloudflare Origin Certificate (free, good for 15 years) or a Let’s Encrypt cert if I want belt-and-suspenders.
The Cloudflare Origin Certificate approach is what I use most now. It’s a certificate signed by Cloudflare’s own CA, trusted by their edge but not by browsers directly, which means it only works if traffic is actually flowing through Cloudflare, which is exactly how I want my setup to behave. If someone somehow got my server’s IP and tried to hit it directly, they’d get an untrusted cert warning instead of a clean connection to my production app. That’s a feature, not a limitation.
The other perimeter basics I have enabled on everything:
-
- HSTS via Cloudflare’s edge headers, so browsers know to always expect HTTPS
-
- Minimum TLS version set to 1.2, I don’t care about supporting ancient clients
-
- Automatic HTTPS rewrites to catch any mixed-content stragglers
-
- Bot Fight Mode turned on, because I’m not running a charity for credential stuffers
None of this required me to write a line of code or touch a config file on my server. That’s what I mean when I say Cloudflare is the perimeter I don’t have to think about.
Caching Rules That Actually Do the Work
The free tier caching is fine out of the box for static assets. Images, CSS, JavaScript, Cloudflare caches those at the edge without me doing much. But where I’ve gotten real mileage is in building custom caching rules for the specific shapes of my apps.
Most of what I run involves some mix of authenticated routes and public-facing content. The trick is telling Cloudflare exactly which is which. A blanket “cache everything” rule is a fast way to serve one user’s dashboard to the next person who loads the page. So I write explicit rules:
- Cache everything on routes like
/static/,/assets/, and any URL pattern I know is fully public and content-addressed - Bypass cache on anything under
/api/,/dashboard/, or any route that sets anAuthorizationheader or session cookie - Custom TTLs on marketing pages and docs where content changes rarely, I’ll set edge cache TTL to 24 hours and let it ride
Cloudflare’s Page Rules and the newer Rules engine both let me express this logic without touching my app code. My origin server doesn’t have to participate in the caching decision; the edge just handles it based on patterns I defined once.
The result is that a meaningful percentage of requests to my public-facing projects never reach Hetzner at all. That’s good for latency (Cloudflare’s edge is closer to most users than my Helsinki box is), good for origin load, and good for my sanity.
Workers and Pages: Logic at the Edge
This is where Cloudflare stops being defensive infrastructure and starts being a platform I actively build on.
Workers are small JavaScript (or WASM) functions that run on Cloudflare’s edge network, over 300 locations worldwide. The latency characteristics are different from anything running on a single server. A Worker executes close to the user, not close to my server. That changes what you reach for it to do.
I use Workers for things like:
-
- Request routing and rewriting, sending traffic to different origins based on URL patterns, headers, or geographic signals without changing my app
-
- A/B testing scaffolding, splitting traffic between two versions of something at the edge before it ever touches app logic
-
- Authentication checks, lightweight token validation that can short-circuit a request before it hits the origin
-
- Redirect tables, managing a long list of permanent redirects without burning server cycles on 301 responses
Pages is Cloudflare’s static site and JAMstack hosting platform, and I use it for things that don’t need a persistent server at all, marketing sites, documentation, simple tools that can run entirely in the browser. Deploy from a Git repo, get a *.pages.dev subdomain for free, attach a custom domain, done. The build pipeline handles the deploy and the CDN handles the delivery.
The thing I appreciate most about Pages is that it removes an entire category of infrastructure decision. I don’t need a Hetzner box for a documentation site. I don’t need to think about uptime or capacity for something that’s purely static. Cloudflare just… holds it.
Workers and Pages also integrate cleanly with KV (key-value storage) and D1 (Cloudflare’s SQLite-at-the-edge offering) if a project grows to need some state without needing a full database. I haven’t leaned hard on those yet, but they’re there when the shape of a project calls for it.
Why the Stack Starts Here
The reason Cloudflare sits at the front of everything I run isn’t just that each individual feature is good, it’s that they compose. My domain registration feeds my DNS, which routes through my SSL termination, which applies my caching rules, which sometimes hands off to a Worker before anything ever hits Hetzner. Each layer knows about the others. Managing all of it through a single dashboard means fewer places for things to fall out of sync.
For a solo operator building and running real things without a team behind them, that composability is worth more than any individual feature on the list. I’m not trying to stitch together five different vendors to build a perimeter. I have one vendor that does the whole perimeter, and I’ve got the cognitive budget I saved to spend on the actual product.
In Part 4, we’ll head inside the ranch, specifically to the moment when a user decides to pay for something. Stripe is how I take that money without losing my mind or too much of my margin, and there’s more nuance to that integration than I expected when I first wired it up.
