Cloudflare

Status: 🟩 COMPLETE (🟦 LIVING — Cloudflare ships new platform features almost weekly) Last updated: 2026-06-19 Plain-English tagline: A network company that started as a security + CDN layer in front of websites, then expanded into a full hosting platform — runs on its own globally-distributed edge that touches nearly every internet user within 50ms.

---

In plain English

Cloudflare is the internet’s quiet utility company. Roughly 20% of all websites on the internet sit behind it in some way — its CDN, its DNS, its DDoS protection, or all three. If you’ve ever waited for a “checking your browser” page or seen a 1.1.1.1 prompt in your network settings, you’ve touched Cloudflare.

The original product (2010): put Cloudflare’s network in front of any website. Visitors connect to Cloudflare instead of your origin. Cloudflare absorbs DDoS attacks, caches static content globally, and adds HTTPS for free. Your origin server gets quieter, faster, safer.

Since 2020, Cloudflare has steadily become a full hosting platform in its own right:

• Cloudflare Pages — static site hosting (Vercel/Netlify equivalent)
• Cloudflare Workers — serverless functions at the edge, V8 isolates with sub-millisecond cold starts
• Cloudflare R2 — S3-compatible storage with no egress fees
• Cloudflare D1 — managed SQLite database at the edge
• Cloudflare KV — eventually-consistent key-value store
• Cloudflare Queues — message queues
• Cloudflare Images — image storage + optimization
• Cloudflare Stream — video hosting + transcoding
• Cloudflare Durable Objects — strongly-consistent stateful objects with global addressing
• Cloudflare AI Gateway / Workers AI — LLM proxying and inference at the edge

The 2026 reality: you can build a complete production webapp using nothing but Cloudflare’s products. That wasn’t true even three years ago.

---

Why it matters

Three reasons Cloudflare is worth knowing, even if you don’t host on it:

1. It’s likely already in your stack. Vercel uses Cloudflare for parts of its infrastructure. Many DNS hosts proxy through Cloudflare. Any “checking your browser” page you’ve ever seen was Cloudflare. Knowing how it behaves matters even when you didn’t pick it.

2. It has the deepest free tier on the internet. Cloudflare’s free plan for DNS, CDN, DDoS, and Workers is genuinely production-ready. No bandwidth charges. No build-minute limits on Pages. The economics are aggressive on purpose.

3. The platform is becoming a real Vercel/Netlify alternative. For a webapp built on Workers + D1 + R2 + Pages, you can get global edge presence, no cold starts, no egress fees, and a coherent developer experience — at a price point that’s hard for competitors to match.

The trade-off: Cloudflare’s developer ergonomics are still catching up. Vercel optimizes for “fastest path from idea to live site.” Cloudflare optimizes for “lowest cost and best raw network performance.” Both are valid; the right one depends on what you’re building.

---

The two ways you encounter Cloudflare

As a layer in front of an existing site

This is the original Cloudflare and still the most common usage. You change your domain’s nameservers to Cloudflare. From that point:

• All DNS queries hit Cloudflare’s resolvers
• Visitors connect to Cloudflare’s edge first
• Cloudflare proxies the request to your origin (Vercel, AWS, your VPS, wherever)
• Cloudflare handles caching, SSL, security, bot management — invisibly

Visitors never connect to your origin directly. They go through Cloudflare every time.

Two key DNS controls:

• Proxied (orange cloud icon) — traffic goes THROUGH Cloudflare. You get the protection but your origin IP is hidden.
• DNS-only (grey cloud icon) — Cloudflare just resolves the DNS record but doesn’t sit in the request path. Your origin IP is visible.

The orange cloud is what gives you the value. The grey cloud is for records that shouldn’t be proxied (like MX records for email — proxying these would break mail delivery).

As a hosting platform itself

The newer model. Instead of putting Cloudflare in front of “your real host,” Cloudflare IS the host. You deploy:

• Pages for static sites and SSR frameworks (Next.js on Cloudflare via the OpenNext adapter, Astro, SvelteKit, etc.)
• Workers for serverless code that runs at the edge
• R2/D1/KV for data

There’s no origin server elsewhere. Your code lives inside Cloudflare’s network.

---

Workers — the heart of the platform

Cloudflare Workers run JavaScript / TypeScript / WASM at every edge location globally. The runtime is V8 isolates (the same engine Chrome uses) rather than containers, which gives them a unique property: near-zero cold starts, typically under 5ms. A Lambda cold start might be 500ms; a Worker cold start is invisible.

// worker.ts
export default {
  async fetch(request: Request): Promise<Response> {
    return new Response("hello from " + request.cf?.country);
  },
};

What makes Workers different from AWS Lambda / Vercel Functions:

Property	Workers	Lambda-style functions
Runtime	V8 isolates	Containers
Cold start	< 5ms	100–2000ms
Memory limit	128MB	up to 10GB
CPU time per request	50ms free / 30s paid	minutes
Available APIs	Web standards + Cloudflare bindings	Full Node.js (or chosen runtime)
Pricing	per request + per CPU-ms	per invocation + per ms × memory
Location	every edge city, globally	one region (unless you replicate)

For request-handling code that’s stateless and short, Workers are the most efficient runtime on the market. For long-running tasks (heavy AI inference, big file processing, queue workers), you still want classic functions or dedicated servers.

---

The Cloudflare data stack

The interesting move of the last few years: Cloudflare has built a coherent data platform at the edge.

Product	Shape	Use case
D1	SQLite-based SQL database	Relational data; replaces Postgres for many small apps
R2	S3-compatible object storage	Files, images, backups. Zero egress fees — huge for media-heavy apps
KV	Eventually-consistent key-value store	Caching, session data, feature flags
Durable Objects	Strongly-consistent stateful objects, globally addressable	Realtime collaboration, websockets, coordination
Queues	Message queues	Background work, retries
Vectorize	Vector database	Embeddings for RAG
Hyperdrive	Postgres connection pooler at the edge	Speed up your existing Postgres from Workers

Each integrates natively with Workers via bindings — you don’t manage connection strings; you declare the resources you need and they appear as objects in your Worker.

# wrangler.toml
name = "my-app"
main = "src/worker.ts"
 
[[d1_databases]]
binding = "DB"
database_name = "app-db"
 
[[r2_buckets]]
binding = "MEDIA"
bucket_name = "app-media"
 
[[kv_namespaces]]
binding = "CACHE"
id = "abc123"

Then in code:

export default {
  async fetch(req, env) {
    const result = await env.DB.prepare("SELECT * FROM posts").all();
    await env.CACHE.put("key", "value");
    const file = await env.MEDIA.get("path/to/file.png");
    return Response.json(result);
  },
};

No connection strings. No SDK setup. The runtime gives you bound resources directly.

---

Pages — Cloudflare’s hosting for sites

Cloudflare Pages is the static site / SSR equivalent of Vercel/Netlify. The pitch:

• Connect a Git repo
• Cloudflare builds on push
• Output is deployed to every edge city
• Preview URLs for every branch
• Custom domains in one click (especially smooth if your domain is at Cloudflare)
• Pages + Workers integrate natively — server routes are Workers

For Next.js, Cloudflare Pages historically lagged Vercel. As of 2026, the OpenNext adapter has made the gap much smaller. Most Next.js features now work on Pages. Some bleeding-edge features still lag by 6–12 months.

For Astro, SvelteKit, Remix, Eleventy, Hugo, etc., Pages is excellent and often better than competitors.

---

A concrete example: a small webapp on pure Cloudflare

Domain:        registered + DNS at Cloudflare (free)
Static site:   Astro deployed to Pages (free)
API:           Workers (10M requests/month free)
Database:      D1 (5GB free, 100K writes/day free)
File storage:  R2 (10GB free, zero egress)
Cache layer:   KV (100K reads/day free)

Total monthly cost at small scale: $0
Total monthly cost at moderate scale: ~$5-15 (mostly request volume)

That’s a full-stack webapp on a global edge network, for less than a coffee per month. The compromise: you must accept Cloudflare-specific patterns (D1 isn’t Postgres; KV isn’t Redis; Workers aren’t full Node). For projects designed around these constraints, the result is impressive.

---

Security features — the layer that started it all

Even if you don’t use Cloudflare’s hosting, you might use its protections:

Feature	What it does
DDoS protection	Absorbs volumetric attacks at the edge. Cloudflare’s network can swallow attacks of hundreds of Tbps.
WAF (Web Application Firewall)	Rules + ML to block SQL injection, XSS, exploit attempts. Free tier has basic rules; paid has OWASP rule sets.
Bot management	Distinguish humans, friendly bots, and malicious bots.
Rate limiting	Throttle per-IP or per-pattern.
Turnstile	A CAPTCHA replacement — usually invisible to humans, blocks bots. Free, drop-in.
Access (Zero Trust)	Replace VPNs. Put auth in front of any URL with Cloudflare Access policies.
Tunnel	Expose a local service publicly without opening ports — useful for self-hosting at home.

For a small webapp under random low-grade attack, putting Cloudflare in front is the single most cost-effective defense. Free, mostly invisible, very effective.

---

Cloudflare’s open DNS resolver: 1.1.1.1

Aside from products, Cloudflare runs a public DNS resolver at 1.1.1.1 (and 1.0.0.1, plus IPv6 equivalents). It’s free for anyone to use, prioritizes privacy (no logs, no selling data), and is fast.

You can change your laptop or router’s DNS to 1.1.1.1 and your DNS lookups go through Cloudflare instead of your ISP. Often faster, often more private than ISP-default resolvers.

---

Common gotchas

• Free tier is generous, but “unlimited” usually means “until abuse.” Cloudflare reserves the right to throttle or contact you if usage looks anomalous on the free plan. For legitimate site usage, this never happens. For things like streaming a TB of video off a free Pages site, expect outreach.

• “Full” vs “Flexible” SSL. In the Cloudflare dashboard SSL settings, Flexible encrypts only between user and Cloudflare, leaving origin traffic plain HTTP — historically a major footgun. Always use Full (strict) when your origin supports HTTPS, which it always does on modern hosts.

• Caching everything by default vs nothing by default. Cloudflare caches static assets aggressively (CSS, JS, images) but skips HTML by default. If you want HTML cached at the edge, configure a Page Rule or Cache Rule explicitly.

• Workers are not Lambda. Limited memory (128MB), limited CPU time per request, no native filesystem, no native Node modules. Many libraries don’t work. Plan accordingly.

• D1 is SQLite, not Postgres. Different SQL dialect for some functions, no JSONB, no pgvector, no advanced extensions. Good for small/medium apps; not a Postgres replacement.

• D1 writes are eventually consistent across regions. Reads in the same region as the write are immediate; reads elsewhere can lag briefly. Plan critical reads to use the primary region or be tolerant of stale data.

• KV is eventually consistent (up to 60 seconds globally). Don’t use it for things that must be immediately consistent worldwide; use Durable Objects for that.

• R2 has zero egress fees but operations cost money. A million reads is roughly $0.36 in 2026. For high-traffic media, R2 is dramatically cheaper than S3; for transactional workloads with lots of small reads, costs can add up.

• Bindings only exist in Workers. Outside the Worker runtime, you have to use HTTP APIs to talk to R2/D1/KV. That’s slower and more authentication overhead. Designs that mix Cloudflare and non-Cloudflare compute often regret it.

• The orange cloud (proxied) can break things. Some services don’t expect Cloudflare-style proxying — for example, SSH, FTP, or non-HTTP TCP services. Use the grey cloud (DNS-only) for those records.

• Wrangler is the CLI you need. npm install -g wrangler and use wrangler dev, wrangler deploy, wrangler tail. The web dashboard is fine for browsing; daily work happens in the CLI.

• wrangler.toml is critical. Bindings, env vars, routes, build settings all live here. Treat it as version-controlled infrastructure.

• Workers have a 30-second wall-clock limit (Paid: 5 minutes, Workers Unbound: 15 minutes). Heavy operations need to be split, queued, or moved off-Worker.

• Subrequest limits. A single Worker request can make up to 50 (free) or 1000 (paid) subrequests. If your Worker fans out to many external APIs, you can hit this.

• Page Rules vs Cache Rules vs Workers. Cloudflare has multiple ways to intercept and modify requests. They run in a defined order, but configuration is fragmented across UI sections. Document which mechanism you use for each rule.

• Account-wide vs zone-wide settings. Some settings are per-domain (“zone”), others apply to your whole Cloudflare account. The dashboard navigation isn’t always clear about which level you’re configuring.

• Cloudflare Pages and Workers have separate dashboards but the line is blurring. Pages projects can host Workers as their backend, and Workers can serve static assets. The mental model is converging in 2026 toward a single “Workers + Static Assets” product.

• Workers have no NUMA, no kernel-level network stack you control. Specific workloads (proxying raw TCP, complex networking) belong elsewhere.

• Email gotchas. Cloudflare DNS for your domain is independent of where email is hosted. MX records still need to point to your email provider (Google Workspace, Microsoft 365, etc.). Don’t accidentally proxy MX records — they shouldn’t have an orange cloud.

• Privacy nuance. Putting Cloudflare in front means Cloudflare can see all traffic. For most projects, this is fine. For privacy-critical contexts (legal, healthcare, journalism), audit the trust model carefully.

• Free plan changes by product. Workers paid plan kicks in at $5/month for 10M extra requests; D1 paid kicks in differently; Pages bandwidth is “unlimited” but flagged at extreme scale. Check the specific product’s pricing page rather than assuming “free Cloudflare” covers everything you’ll ever do.

---

When to choose Cloudflare

• You need DDoS protection or want a security layer in front of an existing site — almost always the right call, free, takes 10 minutes.
• You’re building a small webapp and want everything in one place at minimum cost — Pages + Workers + D1 + R2 is genuinely production-grade.
• You have high egress costs on S3 — R2’s zero-egress pricing can save serious money.
• You need edge functions with the fastest possible cold starts — Workers are unbeaten here.

When to choose something else

• You want the smoothest Next.js experience — Vercel still wins.
• You need a Postgres-shaped database with advanced extensions — D1 isn’t there yet; use Supabase or Neon.
• You have long-running compute — Workers’ time limits hurt.
• You’re already on AWS and don’t want a second vendor surface — staying in AWS may be simpler.

---

See also

• Vercel 🟩 🟦 — the primary alternative for app hosting
• Netlify 🟩 🟦 — the other primary alternative
• What is hosting? 🟩
• CDNs 🟩 — Cloudflare is the most well-known CDN
• Domains and DNS 🟩 — Cloudflare is the most common DNS host
• HTTPS 🟩 — free Universal SSL is Cloudflare’s signature feature
• Environment variables 🟩 — Workers env vars work via bindings
• Regions & edge 🟩 — Workers are the edge case
• OWASP Top 10 🟩 🟦 — Cloudflare’s WAF maps directly to OWASP rules
• Glossary: Cloudflare, WAF, DDoS

---

Sources

• Cloudflare docs — canonical reference
• Cloudflare Workers
• Cloudflare Pages
• Cloudflare D1
• Cloudflare R2
• Cloudflare Radar — public traffic and threat intelligence
• 1.1.1.1 — Cloudflare’s public DNS