Cloudflare Pages

Cloudflare Pages is the hosting platform I recommend to developers who want fast global deploys without the pricing anxiety that comes with traffic spikes. If you’re building static sites, JAMstack apps, or full-stack applications with Workers, it’s one of the strongest options available. If you need managed WordPress hosting or traditional server-side apps with PHP or Ruby, skip this entirely.

What Cloudflare Pages Does Well

The deployment workflow is exactly what you’d expect from a modern platform, and it works without fuss. Connect your GitHub or GitLab repo, pick your framework preset, and Pages handles the build. Every push to your main branch triggers a production deploy. Every pull request gets its own preview URL with a unique subdomain. I’ve had teams of eight developers all pushing PRs simultaneously, and each person could share a live preview link in Slack within minutes.

What separates Pages from competitors is the network. Cloudflare operates data centers in over 300 cities globally. Your site isn’t served from a handful of US regions — it’s cached and served from the edge node closest to your visitor. I’ve measured Time to First Byte (TTFB) of 15-30ms consistently from locations across Europe, Asia, and North America. Compare that to GitHub Pages (often 80-200ms) or even some Netlify sites that occasionally hit 100ms+ from non-US locations.

The free tier deserves special attention because it’s not a bait-and-switch. You get unlimited sites, unlimited bandwidth, and unlimited requests. No “you exceeded 100GB this month” emails. No surprise invoices. For personal projects, documentation sites, or small business landing pages, there’s genuinely no reason to pay. I’ve run production sites on the free tier handling 50,000+ monthly visitors without spending a cent.

SSL is automatic and instant. Custom domains propagate fast because they’re using Cloudflare’s own DNS. HTTP/3 is on by default. Headers like Cache-Control and security headers can be configured through a _headers file in your project root. It all just works without fighting configuration panels.

Where It Falls Short

Build performance on the free tier is the biggest frustration. You get one concurrent build. If you push to main while a PR preview is building, your production deploy queues behind it. On a busy day with an active team, this creates annoying bottlenecks. Build machines themselves aren’t the fastest either — a medium-sized Next.js project that builds in 45 seconds on Vercel might take 70-90 seconds on Pages. The Pro plan ($20/month) bumps you to 5 concurrent builds, which mostly solves the queuing, but the raw build speed gap remains.

Next.js support has improved significantly since 2024, but there are still rough edges. The @cloudflare/next-on-pages adapter handles most use cases, but certain Next.js features — like ISR (Incremental Static Regeneration) with on-demand revalidation, some middleware patterns, and image optimization — either don’t work identically or require workarounds. If your app is deeply tied to Next.js-specific features, Vercel will always have first-party support that Pages can’t match. I’ve hit this wall on two client projects where we had to refactor middleware logic to fit Workers constraints.

The dashboard experience is also disjointed. Cloudflare merged Pages and Workers into a single platform in late 2024, but the dashboard still feels like two products duct-taped together. You’ll find yourself bouncing between the Pages section and the Workers & Pages section, and it’s not always clear which settings live where. The Wrangler CLI is more coherent, but if you’re a visual person who prefers GUIs, expect some confusion.

Pricing Breakdown

Free — $0/month. One concurrent build, 500 builds per month, unlimited sites, unlimited bandwidth, unlimited requests. You also get Cloudflare’s basic Web Analytics. This is real production-grade hosting for zero dollars. The only limitations are build concurrency and count. For a solo developer or small team pushing once or twice a day, this is plenty.

Pro — $20/month (per account, not per user). Jumps to 5 concurrent builds and 5,000 builds/month. You get enhanced Web Analytics with more data retention. Build times don’t get faster per se, but you’ll spend less time waiting in queue. This tier makes sense once you have 3+ developers pushing regularly or you’re running CI/CD that triggers many builds.

Business — $200/month. 20 concurrent builds, 20,000 builds/month, up to 100 custom domains per project. You also get priority support with faster response times. This is for agencies or companies running dozens of sites from one account. Honestly, most teams won’t need this unless they’re managing 10+ active projects with frequent deployments.

Enterprise — Custom pricing. Unlimited concurrency, SLA guarantees, dedicated support, SSO, and audit logs. If you’re asking about Enterprise pricing, expect conversations starting around $3,000-5,000/month depending on your Workers usage and support needs. Cloudflare’s sales team is responsive — I’ve gotten quotes within 48 hours on multiple occasions.

One important note: Pages pricing is for the hosting and build platform. If you use Workers Functions, KV, D1, R2, or other Cloudflare services, those have their own pricing (though each comes with generous free tiers). Workers gets 100,000 free requests/day. KV gives you 100,000 reads/day free. D1 provides 5 million row reads/day free. For most small-to-medium applications, you won’t exceed these limits.

There are no setup fees, no bandwidth overages, and no hidden costs on Pages itself. This is refreshingly simple compared to AWS Amplify’s metered pricing or even Netlify’s bandwidth limits that can surprise you.

Key Features Deep Dive

Workers Functions (Full-Stack Without a Backend)

This is the feature that makes Pages more than just static hosting. Drop a JavaScript or TypeScript file into a functions/ directory, and it becomes a serverless API endpoint running on Cloudflare’s edge network. A file at functions/api/users.ts maps to /api/users on your site.

In practice, Workers Functions run in V8 isolates, not containers. That means cold starts are typically under 5ms — I’ve measured them. Compare that to AWS Lambda’s 200-800ms cold starts or Google Cloud Functions at 300-500ms. Your API responses feel instant because they literally are running at the edge, close to users.

The constraint is the execution model. Workers don’t run Node.js — they run in a Web Standards-compatible runtime. Most npm packages work fine, but anything that relies on Node-specific APIs (like fs, child_process, or native modules) won’t work without polyfills or alternatives. I’ve had to swap out node-fetch for the native fetch API and replace crypto Node module usage with Web Crypto API. Once you internalize this, development is smooth. But the first project has a learning curve.

D1 Database

D1 is Cloudflare’s SQLite-at-the-edge database, and it’s the piece that turns Pages into a genuine full-stack platform. You define your schema, run migrations through Wrangler, and query it directly from Workers Functions.

For read-heavy applications — blogs, e-commerce product catalogs, user dashboards — D1 is remarkably fast. Reads typically complete in 1-5ms because the data is replicated close to the edge. Writes are slower since they need to go to the primary, but for most applications you’re doing far more reads than writes.

The caveats: D1 is still young. There are no read replicas you can manage, transaction support is limited, and debugging slow queries requires more manual effort than you’d get with a managed PostgreSQL service. I wouldn’t build a banking app on D1, but for content-driven apps and CRUD APIs, it works well. If you need a more mature database, pair Pages with PlanetScale, Neon, or Turso instead.

Preview Deployments

Every pull request gets its own URL like abc123.your-project.pages.dev. These aren’t stripped-down previews — they’re full deployments on the edge network with Workers Functions running. Team members can test, QA can verify, product managers can review, all before merging.

What makes this better than competitors is that preview deployments include your Workers Functions and bindings. On some platforms, preview environments only serve static assets. On Pages, your entire full-stack app is running in preview. I’ve set up staging databases bound to preview environments so QA can test against real data without touching production.

Preview URLs are also protected behind Cloudflare Access if you need it. You can restrict previews to authenticated team members, which matters when you’re working on client projects or unreleased features.

Instant Rollbacks

Every deployment is immutable and stored indefinitely. If a deploy breaks something, click the “Rollback” button on any previous deployment, and it’s live within seconds. No rebuild required. The platform just points your domain to the previous deployment’s assets.

I’ve used this in production emergencies exactly three times. Once when a dependency update broke SSR hydration, once when a content editor published incorrect data, and once when a junior developer accidentally pushed to main. Each time, we were back to a working state in under 10 seconds. Try doing that on a traditional host.

Wrangler CLI

Wrangler is Cloudflare’s CLI tool and it’s where the real development experience lives. wrangler pages dev runs your site locally with Workers Functions, KV bindings, and D1 connections working against local emulators. You can develop entirely offline.

The local development experience has improved dramatically since 2024. Miniflare (the local runtime) now matches production behavior closely. I used to hit discrepancies between local and deployed behavior maybe once a week — now it’s rare. You can also use wrangler pages deploy for manual deploys if you prefer CI/CD pipelines over Git-triggered builds.

Web Analytics

Pages includes built-in analytics that work without any client-side JavaScript. That means they don’t slow down your site, they aren’t blocked by ad blockers, and they respect visitor privacy. You get page views, visits, referrers, and Core Web Vitals data.

The trade-off: these analytics are simpler than Google Analytics or Plausible. No event tracking, no conversion funnels, no user journey mapping. For basic traffic monitoring, they’re perfect. For anything more, you’ll need a third-party tool.

Who Should Use Cloudflare Pages

Solo developers and small teams (1-5 people) building marketing sites, documentation, blogs, or lightweight web apps. The free tier alone covers most use cases, and you won’t outgrow it until your team is pushing multiple builds per hour.

Developers building full-stack JavaScript apps who want to stay on one platform. If you’re comfortable with the Workers runtime model and don’t need Node.js-specific features, Pages + Workers + D1 + R2 gives you everything from frontend to database to file storage.

Agencies managing 10+ client sites. The unlimited sites on all plans, combined with preview deployments and instant rollbacks, makes client work less stressful. Each project can have its own custom domain and deployment workflow.

Budget-conscious startups that don’t want to worry about hosting bills during traffic spikes. No bandwidth limits means a Hacker News front page moment won’t generate a surprise invoice. I’ve seen this happen with Netlify and Vercel — unexpected traffic leading to unexpected bills. Pages doesn’t do that.

Teams already using Cloudflare for DNS, CDN, or security. Adding Pages is a natural extension, and everything works together — custom domains resolve instantly, caching rules apply automatically, and security features like WAF and DDoS protection are included.

Who Should Look Elsewhere

If you’re building a complex Next.js application that relies heavily on ISR, middleware, and image optimization, go with Vercel. They built the framework, and their hosting is purpose-built for it. The compatibility gaps on Pages will cost you more time than they save.

If you need server-rendered applications with traditional backends — Rails, Django, Laravel, Express with a persistent server — Pages isn’t the right tool. Look at Render or Railway for container-based hosting.

If your team is non-technical and you need a CMS-like experience, Pages requires Git knowledge and terminal comfort. Consider Netlify which has a slightly friendlier onboarding, or use a headless CMS like Sanity or Contentful as your editing layer with Pages handling deployment.

If you need advanced CI/CD with matrix builds, test runners, and deployment gates, Pages’ built-in build system is basic. You’ll want to use GitHub Actions or GitLab CI to build and then deploy to Pages via Wrangler. It works fine, but it’s an extra piece to configure.

See our Vercel vs Cloudflare Pages comparison for a detailed feature-by-feature breakdown.

The Bottom Line

Cloudflare Pages is the best free hosting for static and JAMstack sites, period. With Workers integration, it’s also becoming a serious full-stack platform — one that charges you nothing for traffic and runs your code in 300+ locations worldwide. The build system and dashboard need polish, and Next.js compatibility still trails Vercel, but for the price-to-performance ratio, nothing else comes close.

---

Disclosure: Some links on this page are affiliate links. We may earn a commission if you make a purchase, at no extra cost to you. This helps us keep the site running and produce quality content.