The Cloudflare CDN (CF CDN) works by sitting in front of your site as a reverse proxy on a global anycast network: you point your DNS at Cloudflare, and every request then travels through the nearest Cloudflare data center, which serves cached content directly from the edge and only reaches back to your origin when it has to. Unlike traditional CDNs, there are no URLs to change - switching DNS is the whole setup - and understanding the reverse-proxy model explains both its benefits and its limits.
CDN usually means a separate domain you serve assets from. Cloudflare’s model is different - it proxies your whole site - and that difference is why it is both easier and more powerful than it looks.
Table of contents
- Anycast and the reverse proxy
- Zero-config by DNS
- What tiered cache does
- What the CDN does not do
- Where RunxBuild fits
- FAQ
Anycast and the reverse proxy
A CDN is a network of servers placed at exchange points between networks so content sits physically close to users. Cloudflare’s version runs on anycast: the same IP addresses are announced from data centers in hundreds of cities, so a request is routed to whichever edge is nearest the user, cutting the round-trip time.
The model is a reverse proxy. Cloudflare receives the request, and either answers from its cache or forwards it to your origin and caches the response on the way back. Because every request passes through Cloudflare first, the same infrastructure that caches also provides DNS, DDoS protection, and a WAF at the edge - all on the path, not bolted on.
Zero-config by DNS
The thing that makes Cloudflare’s CDN unusual is setup. Traditional CDNs require you to rewrite asset URLs to a CDN hostname. Cloudflare instead becomes your DNS, so you just change your nameservers, and your existing URLs are served through the CDN unchanged.
That is why the on-ramp is a few minutes: no code changes, no URL rewriting, no separate asset domain. Flip DNS and the site is proxied. The trade is that Cloudflare is now in the path for everything, which is the source of its power (edge security and caching for the whole site) and the thing to be deliberate about (it sees and can act on all your traffic).
What tiered cache does
Caching at a single edge is good; caching naively across hundreds of edges can be wasteful, because each location independently fetching from your origin means many origin requests for the same object. Cloudflare’s Tiered Cache arranges edges in a hierarchy, so a lower tier fetches from an upper-tier cache that already holds the object rather than hitting your origin.
The effect is fewer origin requests and better cache hit ratios, which both speeds up delivery and reduces load and bandwidth on your origin. For you this means the origin serves a small fraction of total traffic once the cache is warm - the edge absorbs the rest, which is the entire point of a CDN.
What the CDN does not do
Caching at the edge accelerates cacheable content - static assets, images, and responses you allow to be cached. It does not magically speed up uncacheable, dynamic, per-user responses: those still travel to your origin and back, so a slow origin or a slow database is still slow through the CDN.
The common misconception is that putting a CDN in front fixes performance. It fixes delivery of cacheable content and reduces origin load, but a dynamic page that takes a second to render at the origin takes that second plus the proxy hop. The CDN is one half of performance; an efficient origin is the other, and the CDN cannot substitute for it.
Where RunxBuild fits
A CDN handles edge delivery; the origin behind it is where the dynamic work happens, and a slow origin undercuts the whole setup. RunxBuild is where that origin lives: you deploy a static site or a service from a GitHub repo, with 120GB of bandwidth included on static sites before any per-GB charge, plus runtime logs and metrics so you can see which requests are hitting the origin versus being served from the edge.
Put Cloudflare’s CDN in front for caching and edge security, and keep the origin fast and observable on RunxBuild - the static front end served largely from cache, the dynamic service efficient enough that the uncacheable requests the CDN forwards are quick. That division is the performant setup.
How this fits the rest of the stack
The cost of a project is the sum of its line items, not the headline number, and the RunxBuild hosting calculator is the right place to add them up: the service, the database, the storage, the bandwidth, each a separate figure. Model it before committing, not after the first invoice. The RunxBuild dashboard is where the running project shows its real usage in one place.
Useful related references:
FAQ
How does the Cloudflare CDN work?
It acts as a reverse proxy on a global anycast network. You point your DNS at Cloudflare, so every request goes to the nearest Cloudflare data center, which serves cached content from the edge and only forwards to your origin when needed. The same path also provides DNS, DDoS protection, and a WAF.
Do I need to change my URLs to use Cloudflare CDN?
No. Unlike traditional CDNs that require rewriting asset URLs to a CDN hostname, Cloudflare becomes your DNS, so changing your nameservers is the whole setup and your existing URLs are served through the CDN unchanged, which is why it takes only a few minutes.
What is Tiered Cache?
A hierarchy of Cloudflare edge caches where a lower tier fetches from an upper-tier cache that already holds an object instead of hitting your origin. This reduces the number of origin requests and improves cache hit ratios, speeding delivery and cutting load and bandwidth on your origin.
Does a CDN speed up dynamic pages?
Not directly. A CDN accelerates cacheable content and reduces origin load, but uncacheable, per-user, dynamic responses still travel to your origin and back. A slow origin or database is still slow through the CDN, so an efficient origin is the other half of performance that the CDN cannot replace.
Does Cloudflare CDN protect against attacks?
Yes, because every request passes through Cloudflare first, the same edge provides DDoS protection and a WAF alongside caching. That on-path position is what lets it filter malicious traffic before it reaches your origin, provided your origin is firewalled so it cannot be reached directly.