I led the Cloudflare implementation sitting in front of our hybrid estate: some applications in our own data centres, some in GCP, one colo rack that predates most of the current team. None of the vendor architecture diagrams match what you actually run into. This is roughly the order we worked through it, plus the parts nobody mentions upfront.
Onboarding the domain
Adding a domain in the dashboard takes about five minutes. Getting to the point where you can safely do that took weeks.
First problem: the zone file we started with didn't match reality. We pulled records straight off the existing authoritative servers and compared them against the change management history, and a good chunk of what turned up wasn't in any ticket at all. Fifteen years of ad-hoc changes will do that to a zone, and nobody had looked at the whole thing end to end in a long time.
Cutover timing wasn't a single decision either. Customer-facing apps got a proper maintenance window, with the TTL dropped to 300 seconds a day ahead so a rollback wouldn't take six hours to propagate if something went wrong. Internal-only zones just got flipped during business hours, no drama.
Certificates caused more grief than the DNS work did, if I'm honest. If you're moving from a CA-issued origin cert to a Cloudflare edge cert, get the new one issued and validated before the cutover window, not during it. We had one domain where DCV was still racing DNS propagation at 11pm on a Friday. Learned that one the hard way, only needed to once.
Partial DNS vs Full DNS
| Partial (CNAME) | Full (NS delegation) | |
|---|---|---|
| Who's authoritative | Your existing DNS provider | Cloudflare |
| What's protected | Only the records you CNAME in | Every record, by default |
| Fits well with | Domains still tied to on-prem DNS/AD integration | Domains you're free to move outright |
| Blind spots | Anything not explicitly proxied stays exposed | None, but you own all DNS ops now |
| Feature parity | Reduced, some features need full zone control | Full |
We ran both, and not as a hedge, some domains genuinely needed to stay Partial. A handful were still tangled up with an internal DNS estate running split-horizon records for legacy MPLS routing, and nobody was going to rearchitect that on our schedule. Everything the app teams owned outright went Full DNS, mostly because it's less to manage day to day and you get DNSSEC and zone-wide analytics without extra plumbing.
The catch with Partial is it only protects what you remember to CNAME in. Anything you miss just sits on the origin, fully exposed, and nothing in the dashboard flags that for you. We added a quarterly check for this after finding two forgotten records during an audit that had apparently been sitting unprotected for over a year. Nobody noticed because nothing had gone wrong yet, which is exactly the problem.
Onboarding BYOIP
A few of our older applications, mostly email relays and a couple of B2B integrations, had partners who'd hardcoded our IPs into their own firewall allowlists instead of doing DNS lookups properly. Re-IPing all of that was its own multi-month project we didn't have room for, so we brought the prefix to Cloudflare instead and kept the reputation that came with it.
- Confirm the prefix is a valid RIR allocation and get a signed LOA authorizing Cloudflare to announce it.
- Register a ROA naming Cloudflare's ASN, or everything stalls at RPKI validation. We lost most of a week here because our RIR account had gone stale and nobody still employed remembered the login.
- Cloudflare advertises the prefix via anycast once the LOA and ROA agree.
- Cut traffic over gradually, watch BGP convergence and origin health checks, then decommission the old announcement once it's quiet.
Budget four to six weeks, and almost none of that is technical work, it's RIR tickets and internal approvals sitting in someone's inbox. If the space carries real reputation, it's worth doing. If the only reason is "we want to keep our own IPs," push back on that a bit before committing the time, because Cloudflare's own address space is perfectly fine for most apps.
Magic Transit vs direct origin connections
Most of what we run is a plain HTTP/S app, so proxying through Cloudflare straight to origin covers it, cheap, simple, WAF and bot management come along for free. That was the default, and it should probably be the default for most people reading this.
Magic Transit only came into play for the pieces that don't fit that shape: a VPN concentrator, the SIP trunk our contact centre runs on, and an entire /24 sitting behind a hardware load balancer we weren't going to touch. Magic Transit works at the network layer, GRE tunnels and anycast, so it covers the whole subnet regardless of protocol without asking the application to change how it terminates traffic.
If someone's asking about a single web app, proxy it and move on. If they're asking about a subnet, a non-HTTP protocol, or infrastructure where you don't control the termination point, that's a slower and more expensive conversation, and it's better to have it early than after you've already promised a delivery date.
For the origins that couldn't take a public IP at all, mostly internal admin tools, we used Cloudflare Tunnel rather than opening new firewall rules. One less thing to explain to the pen testers next time round.
Security policy, monitoring and fine-tuning
Go-live is the easy part. Whether the WAF is doing anything useful six months later depends entirely on how much tuning discipline survives after the project team has moved on to the next thing.
Every new managed ruleset went into Log mode first, no exceptions. That first week of logs is what told us which internal scanners and old API clients were about to get blocked by a rule nobody had actually reviewed, and let us fix it quietly instead of finding out from a support ticket.
Rate limits are set per endpoint, not per zone. A single zone-wide number either does nothing or takes out the login page the day marketing runs a promo nobody told security about. We found out the second way once, which is one time too many.
Authenticated Origin Pulls turned out to be the biggest gap in the whole as-is audit. The origin was still accepting direct connections on more than one app, meaning the WAF sitting in front of it wasn't doing much at all. Fixed that everywhere the origin was public-reachable.
Logpush went to the SIEM from day one, not after the first incident. I'd made that mistake once already on a different platform years back and had no interest in repeating it here.
Bot management scores get revisited monthly rather than left alone. Traffic patterns shift, and a threshold that looked right at launch is usually stale by the next quarter.
The honest version of tuning is this: week one produces false positives, someone files a ticket about a partner integration getting blocked, and the only thing that makes that a five-minute fix instead of a war room is already having the log-mode data sitting there.
None of this rolled out as one clean template applied five times over. Every domain, every BYOIP prefix, every call between Magic Transit and a plain proxy got decided against what was actually running behind it, which is slower than following a playbook but is also the only reason any of it held up once real traffic hit it.
Working through a similar rollout? Get in touch.