Cloudflare is best understood not as "a CDN" but as a programmable network that sits between your users and your origin, plus a growing platform for running code and storing data at the edge. For most developers the wins are real and immediate — free TLS, a fast global CDN, DNS you don't have to babysit, and a serverless runtime with almost no cold start. The catches are just as real: the Workers runtime isn't Node.js, some of the newer data products are still maturing, and aggressive defaults can cache or block things you didn't mean to. This post is the pros/cons breakdown I wish I'd had before I leaned on it in production.
What does Cloudflare actually give you for free?
The free tier is unusually generous, and it's why so many side projects start here. You get unproxied and proxied DNS, automatic TLS certificates, unmetered CDN bandwidth for cacheable assets, and basic DDoS protection that you don't configure. Point your domain's nameservers at Cloudflare, flip a record to "proxied" (the orange cloud), and your site is behind their network in a few minutes.
On top of that sits the developer platform:
- Workers — JavaScript/TypeScript/WASM functions that run in V8 isolates at the edge. Because isolates aren't containers, startup is effectively instant, which sidesteps the cold-start problem you fight on traditional serverless.
- Pages — Git-connected hosting for static sites and framework front ends, with Workers wired in for server-side logic.
- R2 — S3-compatible object storage with no egress fees, which is the single feature that pulls people off S3.
- KV, D1, Durable Objects, Queues — edge key-value store (eventually consistent), a serverless SQLite database, strongly-consistent stateful objects, and a message queue.
- Zero Trust, Tunnel, Turnstile — private access to internal apps, outbound-only tunnels that expose a local service without opening a port, and a privacy-friendlier CAPTCHA alternative.
The takeaway: Cloudflare's free tier is enough to run a real, globally-distributed app end to end, not just a static landing page.
Where does Cloudflare bite in production?
Nothing here is free of trade-offs, and the sharp edges tend to show up after you've already committed.
The biggest one is that Workers is not Node.js. It's a web-standards runtime (Fetch, Web Crypto, streams). Node compatibility has improved a lot, but libraries that assume the full Node API, native addons, or long-lived TCP connections can still break or need a compat flag. Treat "runs on my laptop" as no guarantee it runs on Workers.
Second, CPU time per request is bounded, not wall-clock time. You can await a slow database for a while, but heavy synchronous compute (image processing, big crypto loops) will hit a limit. That budget is larger on paid plans than free, but it exists on both.
Third, the newer data products are younger than they look. D1 and Durable Objects are genuinely useful, but they're less battle-tested than Postgres or DynamoDB, and their consistency and scaling models are specific enough that porting an existing app is rarely a copy-paste job. KV being eventually consistent surprises people who treat it like a database.
Fourth, aggressive defaults cut both ways. Caching rules can serve stale content or cache something dynamic; the WAF and bot-fight settings can block legitimate API clients or your own automation. And there's concentration risk: when Cloudflare has a bad day, a large slice of the internet has a bad day with it, and you're along for the ride.
The takeaway: Cloudflare removes a lot of ops work, but it does it by making opinionated choices you have to learn — the surprises are configuration and runtime-model surprises, not billing surprises.
When should you reach for Workers vs. Pages vs. a normal server?
Here's the decision table I use.
| Use case | Best Cloudflare fit | Why | Watch out for |
|---|---|---|---|
| Static/JAMstack site or SPA | Pages | Git deploys, previews, free hosting | Server logic still runs as Workers under the hood |
| Lightweight API / auth proxy / redirects | Workers | Near-zero cold start, runs everywhere | Not full Node; CPU budget per request |
| Large file storage + downloads | R2 | No egress fees vs. S3 | Fewer ecosystem integrations than S3 |
| Simple relational data for an edge app | D1 | SQLite, cheap, edge-native | Younger than Postgres; think about scale early |
| Coordinated state (rate limits, presence, chat rooms) | Durable Objects | Strong consistency, single-owner per key | New mental model; test it before you rely on it |
| Existing Node monolith with native deps | Keep your server, put Cloudflare in front | Avoids a rewrite | You lose edge execution, but keep the CDN/WAF |
The takeaway: use Cloudflare's compute when the work is small, stateless, and latency-sensitive; keep a traditional server when you need the full Node ecosystem or heavy compute, and still front it with Cloudflare's network.
How do you actually deploy something on it?
The tooling is wrangler, Cloudflare's CLI. A minimal Worker that adds an API in front of R2 looks like this:
npm install -g wrangler
wrangler login
wrangler init my-edge-api
// wrangler.jsonc
{
"name": "my-edge-api",
"main": "src/index.ts",
"compatibility_date": "2026-01-01",
"r2_buckets": [
{ "binding": "ASSETS", "bucket_name": "my-bucket" }
]
}
// src/index.ts
export interface Env {
ASSETS: R2Bucket;
}
export default {
async fetch(request: Request, env: Env): Promise<Response> {
const url = new URL(request.url);
const key = url.pathname.slice(1); // strip leading "/"
if (!key) {
return new Response("Provide an object key in the path", { status: 400 });
}
const object = await env.ASSETS.get(key);
if (object === null) {
return new Response("Not found", { status: 404 });
}
const headers = new Headers();
object.writeHttpMetadata(headers);
headers.set("etag", object.httpEtag);
headers.set("cache-control", "public, max-age=3600");
return new Response(object.body, { headers });
},
};
wrangler deploy
That's a globally-distributed, cached file-serving API with no server to patch and no egress bill. Notice what's not here: no express, no fs, no long-lived process — the whole thing is a fetch handler, and that constraint is the price of the edge model.
For a different shape of problem — exposing a local service without opening a firewall port — cloudflared gives you an outbound-only tunnel:
cloudflared tunnel --url http://localhost:3000
That prints a public HTTPS URL that proxies to your local port, which is handy for demoing work, testing webhooks against a local server, or wiring up a homelab service through Zero Trust.
The takeaway: the happy path is genuinely short, but every example above is shaped by the runtime — you design for the edge, you don't lift-and-shift onto it.
Is the paid tier worth it, and when?
The free tier carries real projects a long way. You generally start paying when you cross request/usage limits on Workers, need higher CPU budgets, want WAF custom rules and better bot management, or need R2/D1 capacity beyond the free allotments. As of mid-2026 the compute and storage products use usage-based pricing with a low monthly floor on the paid Workers plan, and R2's no-egress model is what makes the math attractive versus S3 for download-heavy workloads — but confirm current numbers on Cloudflare's pricing page before you commit, because tiers move.
The honest build-vs-buy read: if your workload is edge-friendly, Cloudflare is one of the cheapest ways to run it, and the free tier means you can validate before spending anything. If your workload needs a real Node runtime, a mature relational database, or heavy compute, don't contort it to fit — run it on a normal host and use Cloudflare only for the network layer.
The takeaway: pay when you hit usage limits or need advanced security features, not to "unlock" the platform — most of the platform is already free.
Bottom line
Reach for Cloudflare first if you're building something latency-sensitive, static, or edge-shaped: static sites and SPAs on Pages, lightweight APIs and proxies on Workers, download-heavy storage on R2. Front any existing app with its CDN, DNS, and WAF regardless — that part is nearly all upside. Be cautious about betting a data-heavy or Node-dependent backend entirely on Workers/D1/Durable Objects today; prototype it, but keep a traditional server in your back pocket. The platform's real cost isn't money — it's learning its runtime model and defaults well enough that they stop surprising you.
Top comments (0)