← route

LSN 01/10 EDGE 8 MIN TIER FREE

What Cloudflare actually is

The mental model: a global proxy that sits in front of everything you put on the internet, with a pile of optional products that plug into that position.

Cloudflare started in 2009 as a service that absorbed DDoS attacks on behalf of small websites. Today it is a sprawling stack, but the core has not changed: a network of points-of-presence in roughly 300 cities, each one acting as a reverse proxy between visitors and origins.

Almost every Cloudflare product is something that runs at that proxy. That single fact explains the rest of the catalog.

The shape of a request

When someone in Mumbai visits yoursite.com and that site is on Cloudflare, the request does not go directly to your server. It goes to whichever Cloudflare data center is closest, in milliseconds. That data center then:

  1. Resolves DNS for the hostname (your records live in Cloudflare’s DNS).
  2. Checks the cache. If the requested asset is in cache, it returns it without ever contacting your origin.
  3. Runs any Workers you have bound to that route.
  4. Applies WAF, bot, and rate-limit rules.
  5. If still needed, forwards the request to your origin server.
  6. Caches the response on the way back for the next visitor.

Your origin can be a VPS, a static site on Cloudflare Pages, a Worker, or a service behind a Cloudflare Tunnel. The proxy does not care.

you visitor CLOUDFLARE EDGE · ~300 cities DNS resolve Cache hit? Workers run code WAF / Bot filter srv origin
The proxy sits in the path. Every other Cloudflare product is something that plugs into one of these boxes.

What plugs into the proxy

Because Cloudflare already sits in the request path, adding a new capability usually means turning on a feature, not standing up a new service. A short tour of the catalog viewed through this lens:

  • DNS is the substrate. Your records live here.
  • CDN / Cache is the proxy storing static responses.
  • WAF, Bot management, Rate limiting are filters applied as requests flow through.
  • Pages lets the proxy serve static sites directly. No origin needed.
  • Workers let you run code at the proxy on each request.
  • R2, KV, D1 are storage primitives Workers can read and write.
  • Access challenges visitors at the proxy and lets the request through only after they authenticate.
  • Tunnel lets your origin reach out to the proxy from inside a firewall, so no inbound ports need to be open.

You opt into each of these individually. Most sites use DNS plus the free CDN and never touch the rest. Once you start adding more, they share the same dashboard, same DNS, and same identity model.

What Cloudflare is not

A few clarifications, because the brand sometimes implies more than it delivers:

  • Not a database. D1 exists, but it is SQLite at the edge, not a managed Postgres. KV is eventually consistent. R2 is object storage. For a traditional relational workload, pair Cloudflare with a hosted database somewhere else, or accept the constraints of these primitives.
  • Not a CMS or page builder. Pages hosts whatever you build. The content authoring is your problem.
  • Not a domain registrar by default, though Cloudflare Registrar exists and is covered in the next lesson.
  • Not a mail provider. Email Routing forwards mail to an existing inbox; it does not host mailboxes.

Why the free tier is generous

The proxy fleet exists either way. Adding one more domain to it costs Cloudflare almost nothing in marginal terms. The free tier captures users early and pulls some of them into the paid products (Pages Functions usage, Workers paid plans, R2 storage, Access seats, Argo, Load Balancing, enterprise SLA). This is worth understanding because it means you can run real production traffic for $0 if you stay inside the free quotas, and the upgrade path is feature-driven rather than traffic-driven.

In the rest of these lessons, the framing is always the same: where is this feature in the request path, what does it cost, and what is the smallest thing you need to do to use it.