DEV Community

Cover image for Cloudflare Pages Pricing 2026: Free Tier Limits, Workers Costs & When to Upgrade
Nayan Kyada
Nayan Kyada

Posted on Originally published at nayankyada.com

Cloudflare Pages Pricing 2026: Free Tier Limits, Workers Costs & When to Upgrade

Cloudflare Pages sits in almost every shortlist when teams are deciding where to host a Next.js or static site, mostly because the free tier sounds too good to be true. This post breaks down what the free plan actually covers, what each paid tier costs, and the specific usage thresholds that will push you toward an upgrade.

What the free tier actually includes

Cloudflare Pages Free gives you unlimited sites, unlimited bandwidth, and 500 builds per month with up to 20,000 files per deployment. Those numbers look generous compared to Vercel or Netlify, and for a straightforward static or edge-rendered site they hold up.

The limits that bite you in practice are different:

  • Concurrent builds: 1 (free) vs 5 (Pro). If you have multiple branches or preview deployments firing at once, a queue forms fast.
  • Build duration: 20 minutes maximum per build on free. A large Next.js project with many static pages can brush against this.
  • Workers invocations (for SSR): Cloudflare Pages uses Workers under the hood for server-side rendering via the @cloudflare/next-on-pages adapter. The free Workers tier allows 100,000 requests/day. That sounds like a lot until you factor in API routes, image transforms, and revalidation webhooks each counting separately.
  • Worker CPU time: 10 ms per invocation on the free tier. Complex GROQ fetches or middleware chains will exceed this silently, causing 1101 errors.
  • KV reads/writes: If you cache Sanity responses in Workers KV, free limits are 100,000 reads and 1,000 writes per day. Write-heavy revalidation patterns eat the write quota quickly.
  • D1 and R2: Not bundled in Pages free. You pay for these separately if you reach for them.

Cloudflare Pages pricing tiers in 2026

Plan Monthly Cost Builds/month Concurrent Builds Workers Requests/day CPU per request
Free $0 500 1 100,000 (shared free Workers) 10 ms
Pro $20 5,000 5 10 million (Workers Paid) 50 ms
Business $200 20,000 20 Workers Paid + priority 50 ms
Enterprise Custom Unlimited Custom Custom Custom

The jump from Free to Pro at $20/month is one of the lowest entry points in the hosting market. The bigger shift is that Pro includes Workers Paid, which changes the billing model entirely: instead of a hard daily cap, you get 10 million requests included and then pay $0.30 per additional million. CPU time becomes 50 ms per invocation, which covers most Next.js route handlers and middleware without hitting limits.

What actually triggers an upgrade

Three scenarios push teams off the free tier in practice:

1. SSR request volume. A site doing 150,000 page views per day will exceed the 100,000-requests/day Workers free quota well before peak, because each HTML page, each JSON API call, and each revalidation webhook is a separate invocation. Pro's 10 million included requests comfortably handles most production Next.js sites.

2. CPU-heavy middleware. The 10 ms CPU limit on free is the sneakiest constraint. Sanity GROQ fetches, JWT verification in middleware, or even a moderately sized next-intl locale negotiation can push past 10 ms. You won't always see an error — sometimes the Worker just returns a partial response. Upgrading to Pro's 50 ms limit fixes this without any code change.

3. Preview/branch builds. Agencies running one Pages project per client repo, with PR previews enabled, frequently saturate the single concurrent build slot. A five-minute wait for a preview link kills editor feedback loops. Pro's five concurrent builds resolves this; Business gets you twenty.

Workers Paid add-on vs bundled

If you only need the Workers request increase but not the Pro Pages features, you can add Workers Paid ($5/month base, 10 million requests included, $0.30/million after) to a free Pages project. This is useful for projects where the build pipeline is fine but SSR volume is the only problem. It is not well documented but it works — you enable Workers Paid in the account dashboard and it applies to Pages Workers automatically.

Comparing total cost: Cloudflare Pages vs Vercel vs Netlify

Hosting Free bandwidth cap SSR billing model First paid tier Concurrent builds (paid)
Cloudflare Pages Unlimited Workers invocations $20/mo 5
Vercel 100 GB Function invocations + GB-hours $20/mo (Pro, 1 member) Unlimited (queued)
Netlify 100 GB Function invocation seconds $19/mo 3

Cloudflare wins on bandwidth because there is no cap at any tier. Vercel's pricing becomes complicated once you add team seats — each additional member on Pro is $20/month, which stacks fast for agencies. Cloudflare Pages Pro is a flat $20 for the entire team with no per-seat charge.

Vercel has a materially better Next.js integration — ISR tag-based revalidation, PPR, and the revalidatePath / revalidateTag APIs all work natively. On Cloudflare Pages with @cloudflare/next-on-pages, some of these features require workarounds or are not supported yet. That gap is narrowing in 2026 but it is not closed.

Specific thresholds to watch before upgrading

  • CPU per invocation approaching 8 ms consistently: Upgrade before you start seeing 1101 errors under load.
  • Build queue wait time above 10 minutes: You have hit the concurrent build ceiling. Pro fixes this.
  • KV writes above 800/day: You are close to the 1,000/day free limit. Workers Paid removes this cap.
  • Monthly builds above 400: With 500 free, a busy CI pipeline with frequent merges will exhaust this in a 20-day sprint.

Bottom line

Cloudflare Pages free tier is genuinely useful for small sites, internal tools, and early-stage products. The unlimited bandwidth and generous build count are real advantages over Netlify and Vercel free plans. The $20 Pro upgrade makes sense the moment you run SSR at any meaningful volume or need more than one concurrent build. For Next.js projects specifically, validate your @cloudflare/next-on-pages compatibility requirements before committing — some ISR and caching patterns still need Vercel or a workaround.

Top comments (0)