What is each product actually for?

Pages hosts a site. Workers run code at the edge. R2 stores objects without egress fees. They are not alternatives to each other; they are three layers, and most confusion comes from comparing a host to a compute primitive as if you had to choose.

When is Pages the right host for a Next.js app?

When the app is mostly static or lightly dynamic and the framework features it uses are supported there. The constraint is compatibility rather than capability: Next features that assume a Node runtime need checking, and discovering a gap after migrating is an expensive way to learn.

Workers or Next.js middleware?

Middleware when the logic belongs to the application and ships with it. Workers when the logic must exist independently of the app, applies across several origins, or must run even when the application is down. Duplicating middleware into a Worker means two places to change one rule.

When does R2 beat S3?

When egress dominates the bill, which is the usual case for public media. R2 removes egress charges, so a site serving many large assets sees the difference immediately. For low-traffic private storage the saving is small enough that either is fine.

What is Workers KV good for?

Read-heavy configuration and lookups at the edge where eventual consistency is acceptable: feature flags, redirect maps, routing tables. It is not a database, and using it as one produces the classic bug where a write is not visible where it was expected.

When do Durable Objects earn their complexity?

When you need strong consistency and coordination at the edge, such as a counter or a shared session that several clients mutate. That is a real need and a narrow one. Most applications reaching for them want a database and have not tried one.

Is D1 a replacement for Postgres?

Not for most applications. It suits small, edge-local relational data with modest write volume. A multi-tenant business application with real relational needs, row-level policies, and analytical queries belongs on Postgres, and the effort to work around that is larger than the latency saved.

How do bindings change what Workers can do?

They connect a Worker directly to storage and other services without network round trips or credentials in code, which is what makes edge compute practical rather than merely possible. A Worker fetching over the public internet loses most of the latency advantage that justified it.

How does the cost compare to a Postgres-plus-platform stack?

Cheaper for static and read-heavy media, comparable for modest compute, and not the deciding factor for an application with real database needs. Cost differences at small scale are small enough that operational fit should decide, and it usually points at the stack the team already knows.

What is the decision tree in one pass?

Serving files, use storage plus the CDN. Running application logic, use your application. Needing logic before routing or independent of the origin, use a Worker. Needing relational data with policies, use Postgres. Most stacks need two of these, not all of them.

What is the risk of adopting the whole ecosystem?

Coupling. Each piece is good and the combination is hard to leave, particularly when data lives in edge-native stores with no direct equivalent elsewhere. That is an acceptable trade made deliberately and an unpleasant surprise when it happened one service at a time.

What should a small business actually use?

DNS, CDN, and the security features, which are the highest-return parts and require no architectural commitment. Storage when media volume justifies it. Everything else only when a specific problem names it, because each addition is another system to understand during an incident.

Cloudflare DevOps How-to

Cloudflare Pages vs Workers vs R2: Which One to Use in 2026

Cloudflare has 30+ products. Three of them cover 80% of what most SMB sites need.

John Cravey with AIFounderApr 26, 20266 min readUpdated Sep 11, 2026

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.

Free estimate · 2 minutes

Read the playbook. Now see it for your business.

The posts are the mechanism. The estimate below sketches the version we'd actually ship for your business, at your scale. About a minute, no opt-in.

#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.

Answers

Frequently asked questions

What is each product actually for?: Pages hosts a site. Workers run code at the edge. R2 stores objects without egress fees. They are not alternatives to each other; they are three layers, and most confusion comes from comparing a host to a compute primitive as if you had to choose.
When is Pages the right host for a Next.js app?: When the app is mostly static or lightly dynamic and the framework features it uses are supported there. The constraint is compatibility rather than capability: Next features that assume a Node runtime need checking, and discovering a gap after migrating is an expensive way to learn.
Workers or Next.js middleware?: Middleware when the logic belongs to the application and ships with it. Workers when the logic must exist independently of the app, applies across several origins, or must run even when the application is down. Duplicating middleware into a Worker means two places to change one rule.
When does R2 beat S3?: When egress dominates the bill, which is the usual case for public media. R2 removes egress charges, so a site serving many large assets sees the difference immediately. For low-traffic private storage the saving is small enough that either is fine.
What is Workers KV good for?: Read-heavy configuration and lookups at the edge where eventual consistency is acceptable: feature flags, redirect maps, routing tables. It is not a database, and using it as one produces the classic bug where a write is not visible where it was expected.
When do Durable Objects earn their complexity?: When you need strong consistency and coordination at the edge, such as a counter or a shared session that several clients mutate. That is a real need and a narrow one. Most applications reaching for them want a database and have not tried one.
Is D1 a replacement for Postgres?: Not for most applications. It suits small, edge-local relational data with modest write volume. A multi-tenant business application with real relational needs, row-level policies, and analytical queries belongs on Postgres, and the effort to work around that is larger than the latency saved.
How do bindings change what Workers can do?: They connect a Worker directly to storage and other services without network round trips or credentials in code, which is what makes edge compute practical rather than merely possible. A Worker fetching over the public internet loses most of the latency advantage that justified it.
How does the cost compare to a Postgres-plus-platform stack?: Cheaper for static and read-heavy media, comparable for modest compute, and not the deciding factor for an application with real database needs. Cost differences at small scale are small enough that operational fit should decide, and it usually points at the stack the team already knows.
What is the decision tree in one pass?: Serving files, use storage plus the CDN. Running application logic, use your application. Needing logic before routing or independent of the origin, use a Worker. Needing relational data with policies, use Postgres. Most stacks need two of these, not all of them.
What is the risk of adopting the whole ecosystem?: Coupling. Each piece is good and the combination is hard to leave, particularly when data lives in edge-native stores with no direct equivalent elsewhere. That is an acceptable trade made deliberately and an unpleasant surprise when it happened one service at a time.
What should a small business actually use?: DNS, CDN, and the security features, which are the highest-return parts and require no architectural commitment. Storage when media volume justifies it. Everything else only when a specific problem names it, because each addition is another system to understand during an incident.

Question we did not answer? Ask us directly and we will answer it here.

Tagged#Cloudflare #DevOps #How-to

Written by

John Cravey

Founder

Founder of Frontend Horizon. Writes most of the long-form work on the FH blog.