Cloudflare’s product list is overwhelming. The marketing site lists thirty-plus services and the dashboard adds new ones every quarter. For most SMB sites, three products cover the use cases that matter: Pages for hosting static or Next.js sites, Workers for edge functions, and R2 for cheap object storage. Here’s how to decide which one fits your problem.
Cloudflare Pages: when it’s the right host
Cloudflare Pages hosts static sites and modern frameworks (Next.js, Astro, SvelteKit) with git-push deploys. Free tier covers most SMB use cases — 500 builds/month, unlimited bandwidth, custom domain support. It competes directly with Vercel and Netlify, and on the SMB sites where we’ve compared them, it’s roughly equivalent in DX and slightly cheaper at scale.
When Pages wins: static-or-mostly-static sites without complex server features. When it loses: anything that needs Node-only APIs, long-running server logic, or a database connection pool. Pages uses Workers under the hood, so you’re in the Workers runtime — Deno-flavored, edge-only, no persistent connections.
Pages vs Vercel for Next.js
Both work. Vercel’s Next.js integration is tighter (it’s their framework) so some features (ISR, middleware) work without configuration. Pages requires the `@cloudflare/next-on-pages` adapter, which is solid but requires understanding the difference between Node-runtime and Edge-runtime routes. For straightforward Next sites, Vercel is less friction. For sites already deep in the Cloudflare ecosystem (R2, Workers, KV), Pages is the cleaner fit.
Cloudflare Workers: when edge logic earns its keep
Workers run TypeScript/JavaScript on Cloudflare’s edge network. They’re the right tool for logic that needs to happen at the edge — before your origin sees the request — and doesn’t need Node-only APIs.
- URL rewrites based on request data (geo, headers, cookies) at the edge.
- A/B test variant selection that persists in a cookie across cached requests.
- Custom auth checks at the edge before letting requests through to the origin.
- Response manipulation: injecting analytics scripts, modifying HTML for personalization, etc.
- Cron-scheduled jobs (one Worker can be configured to run on a cron schedule).
Workers vs Next.js middleware
Big overlap. Both run at the edge, both have access to request headers, both can rewrite URLs. The difference: Next.js middleware is tightly coupled to your Next app — it deploys with it, it runs on your Vercel or Coolify edge layer. Workers are a separate deploy and run on Cloudflare’s edge regardless of where your origin lives.
We use Workers when the logic needs to run in front of multiple origins or in front of a site we don’t own the framework of (a client’s WordPress site we’re adding edge personalization to). For sites we control end-to-end, middleware is simpler.
Cloudflare R2: when S3 is overkill
R2 is Cloudflare’s S3-compatible object storage. The headline feature: no egress fees. Storing 1TB on R2 costs $15/month (storage) and zero per GB out, versus S3’s $23/month storage plus $90 for the first 1TB egressed. For sites that serve a lot of media, the savings compound fast.
R2 vs Supabase Storage is the choice we’re making most often. Both work. Supabase is integrated with the rest of our stack (auth, RLS, edge functions). R2 is cheaper at high volume and is faster from the Cloudflare edge. Decision rule: under 50GB total, use Supabase. Over 200GB or with hot images served globally, R2.
R2 + Cloudflare Images: the image stack for high-volume sites
For sites that serve a lot of user-uploaded photos (a real-estate client, a portfolio gallery, anything UGC-heavy), pair R2 with Cloudflare Images. R2 stores the originals; Cloudflare Images handles resizing, format conversion, and delivery from the edge. The combination is competitive on cost with running your own next/image pipeline and is dramatically simpler to maintain.
The decision tree
- Static or mostly-static site that we already chose to host on Cloudflare? → Pages.
- Need edge logic in front of a site whose framework we don’t fully control? → Workers.
- Need cron jobs at the edge? → Workers (with Cron Triggers).
- Need to store a lot of media and serve it globally? → R2 + Cloudflare Images.
- Want one integrated platform across DB, auth, storage, edge? → Supabase + Next.js. Stay there.
- Building a media-heavy app that needs to scale beyond what Supabase Pro covers? → Mix: Supabase for relational data, R2 for media.
Workers KV: when you need at-edge key-value
Workers KV is a key-value store with values cached at the edge. Reads are sub-10ms from any region. Writes are eventually-consistent across regions (up to 60s propagation). It’s the right tool for things like: feature-flag values that need to read fast from every edge, user-session tokens, API keys for outbound calls. Wrong tool for: anything you’d run a SQL query against.
Workers Durable Objects: when you need strong consistency
Durable Objects give you single-instance, strongly-consistent state on Workers. Use case: collaborative documents, multiplayer games, rate-limit counters, distributed locks. Not for general app data. We use them sparingly on one client’s app for room-level state in a real-time feature; everywhere else, Postgres is the right fit.
Cloudflare D1: the SQL database
D1 is Cloudflare’s SQLite-on-the-edge. It’s genuinely interesting — strong consistency, sub-10ms reads from edge, free tier covers SMB workloads. We haven’t moved any FH client to D1 because Supabase + Postgres covers what we need and Postgres has more headroom. If you’re starting from scratch and want a Cloudflare-native stack, D1 is worth a look. If you have an existing Postgres workload, the migration cost rarely pays for itself.
Cost comparison: Cloudflare ecosystem vs Supabase + Vercel
For an SMB site at typical traffic: Cloudflare stack (Pages + R2 + Workers + Images) ≈ $25–60/month. Supabase + Vercel stack ≈ $45–105/month. The Cloudflare stack is cheaper at low/mid volume; the Supabase+Vercel stack is cheaper at very-high volume because of pricing model differences. For most SMB workloads, either is reasonable; pick on familiarity and integration, not price.
What we run today across the FH client book
- Every site: Cloudflare DNS + CDN + WAF + Turnstile. Always.
- Most sites: Coolify-hosted Next.js behind Cloudflare. Supabase for data.
- One retail client: R2 for product images (50GB+ growing), Cloudflare Images for transformation.
- Zero clients on Cloudflare Pages currently — we’ve looked at it twice and stayed on Coolify both times for the operational familiarity. We may revisit.
- Zero clients on D1 — Supabase covers our use cases.
Pulling it together
Cloudflare has 30+ products. You need three or four. Start with DNS + CDN + Turnstile, add R2 when storage gets expensive elsewhere, add Workers when you have a genuine edge-logic problem that doesn’t fit middleware. Skip the rest until they solve a real problem you’re experiencing. If you want a second opinion on which pieces of Cloudflare make sense for your stack, book a consultation — most setups can be simplified, not expanded.
