Vercel vs Cloudflare Pages for Next.js: Build Limits, Edge Functions, and Real Pricing
You've built a Next.js app and now you're staring at two deployment options that both promise zero-config deploys and global edge performance. The problem is that once you hit real traffic or a large team, the free tier differences start mattering in ways the marketing pages don't make obvious.
This article breaks down Vercel and Cloudflare Pages from the perspective of someone shipping a Next.js project, not a static brochure site. Expect concrete numbers, honest trade-offs, and a clear recommendation depending on your situation.
- How build limits and concurrency compare on free and paid tiers
- What edge functions actually look like on each platform for Next.js
- Where the real pricing cliff edges are
- Which platform wins for specific workloads: SSR-heavy apps, static sites, and high-traffic APIs
- Common gotchas that bite teams after they've already deployed
The Platforms at a Glance
Vercel is built by the team that maintains Next.js. That relationship is tight enough that new Next.js features (App Router, Server Actions, Partial Prerendering) are designed with Vercel's infrastructure in mind first. Cloudflare Pages started as a static site host and has been adding compute capability through its Workers runtime ever since.
Both support custom domains, HTTPS by default, Git-based deployments, and preview URLs per branch. The meaningful differences show up in runtime behavior, pricing structure, and how well each platform maps to Next.js's server-side features.
Build Limits: What You Get on Free Tiers
Vercel's Hobby plan allows 100 GB-hours of function execution per month and 6,000 build minutes. Deployments are limited to one concurrent build. For a solo developer, this is comfortable. For a small team pushing multiple branches throughout the day, you'll feel the single-concurrency limit quickly.
Cloudflare Pages' free tier is notably more generous on the build side: 500 builds per month with unlimited bandwidth and no hard cap on build minutes in the same way Vercel counts them. Concurrent builds are also limited on the free plan, but the raw build count ceiling is higher for active teams.
On paid plans, Vercel's Pro tier ($20/member/month) raises the function execution limit significantly and unlocks multiple concurrent builds. Cloudflare's paid Workers and Pages plans are priced per request and compute unit rather than per seat, which changes the math depending on your traffic shape.
Edge Functions and Next.js Compatibility
This is where the platforms diverge most sharply, and it's the most important section if you're using anything beyond a static export.
Vercel Edge Functions
Vercel runs its Edge Functions on the V8 isolate runtime (the same underlying model as Cloudflare Workers). In the context of Next.js, this means export const runtime = 'edge' on a Route Handler or Middleware works exactly as documented. Server Actions, React Server Components, and streaming responses all behave as Next.js's own documentation describes, because Vercel built those primitives together with the framework.
Node.js API routes that don't use the edge runtime run as serverless Lambda-style functions on AWS infrastructure. Cold starts on those are measurable β typically a few hundred milliseconds after inactivity. Edge functions have near-zero cold start times.
Cloudflare Pages Functions
Cloudflare Pages uses the Workers runtime, which is fast and globally distributed. The challenge is that the Workers runtime is not a Node.js environment. It's a subset of Web APIs. This creates friction with Next.js because the framework assumes certain Node.js globals and modules are available at runtime.
Cloudflare has published an adapter β @cloudflare/next-on-pages β that transforms Next.js output into something the Workers runtime can run. It works for many use cases, but it has explicit compatibility limitations. Not every Next.js feature is supported. Server Actions have had partial support with caveats. The App Router is supported but some behaviors differ from the reference Vercel implementation.
If your app uses the Pages Router and doesn't rely on Node.js-specific packages in its server code, Cloudflare Pages is a realistic option. If you're building with the App Router and heavy server-side features, you'll need to test carefully.
Real Pricing: Where the Bills Show Up
Both platforms have cost structures that look affordable until a specific usage pattern triggers the expensive part.
Vercel's pricing traps
The per-seat model on the Pro plan means a five-person team pays $100/month before any usage. Function execution overages are billed on top of that. If you're running an API-heavy Next.js app with many server-rendered routes, function invocation counts accumulate fast. Bandwidth overages are another line item that surprises teams coming from platforms that bundle bandwidth.
The Enterprise tier is the only option for features like single sign-on, audit logs, and advanced deployment controls. There's no middle ground between Pro and Enterprise, which pushes funded startups into custom contract territory earlier than expected.
Cloudflare's pricing traps
Cloudflare Workers on the free plan allows 100,000 requests per day with a CPU time cap per invocation. The paid Workers Paid plan ($5/month) raises the request limit significantly and changes CPU billing to a per-million-requests model. This is attractive for high-request, low-compute workloads.
The trap is Durable Objects and KV storage. If your app uses these primitives for state (which you may need to replace Next.js's assumptions about Node.js cache behavior), costs can rise in ways that aren't obvious from the top-level pricing page. Read operations on Workers KV are cheap; write operations and storage at scale add up.
Performance: Cold Starts and Global Distribution
Both platforms distribute assets globally through their CDN. The performance difference for static assets is negligible in practice.
For dynamic compute, Cloudflare's Workers run in over 300 locations worldwide. Vercel's edge network is smaller but covers all major regions. For most applications, both will deliver sub-100ms response times for cached content.
Cold starts are more meaningful for server-rendered routes. Vercel's Node.js serverless functions (non-edge) have the classic cold start problem. Cloudflare Workers have no meaningful cold start because isolates don't spin up a full process. If you can fit your server logic into the edge runtime on either platform, you avoid the problem entirely.
Developer Experience
Vercel's DX is difficult to beat. The dashboard is polished, preview deployments are seamless, log streaming works well, and the integration with Next.js means you rarely hit configuration walls. vercel dev runs a local environment that closely mirrors production behavior including edge middleware.
Cloudflare's tooling has improved substantially. wrangler is the CLI you use to deploy and test Workers and Pages projects. It's capable, but the mental model of managing Worker scripts alongside Pages deployments adds cognitive overhead. The local emulation via wrangler pages dev works, but matching the exact production behavior of the Workers runtime locally requires careful setup.
For teams that live in Git and prefer minimal configuration, Vercel wins on day-to-day friction. For teams comfortable with infrastructure-as-code and who want more control over their runtime environment, Cloudflare's model is more composable.
Common Pitfalls
- Assuming full Next.js compatibility on Cloudflare: The
@cloudflare/next-on-pagesadapter has a compatibility matrix. Check it before committing to a migration, especially for App Router features. - Ignoring Vercel function timeouts: Hobby plan functions time out at 10 seconds. Pro extends this, but long-running server operations need explicit attention. Background jobs don't belong in serverless functions regardless of platform.
- Underestimating Vercel bandwidth costs: If you're serving large files or high-res images through Next.js Image Optimization, bandwidth meters fast. Offload large static assets to object storage with a CDN in front.
- Using Node.js-only packages in edge routes on Cloudflare: Any
importof a package that relies onfs,crypto(Node.js built-in, not the Web Crypto API), ornetwill fail silently or loudly in the Workers runtime. Audit dependencies before deploying. - Missing the Cloudflare Pages build cache behavior: Build caches on Cloudflare Pages are less predictable than Vercel's. If your build times are creeping up, check whether the cache is actually being used between deployments.
When to Choose Vercel
Choose Vercel when you're building an App Router application with Server Components, Server Actions, or streaming. If you want the path of least resistance from next build to production, Vercel is that path. It's also the right call for teams that need preview deployment URLs as a first-class workflow feature β the UX around that is tight.
The cost is justifiable for teams that bill clients or have revenue, where the per-seat model is a predictable operational expense. Solo developers on the Hobby plan can run surprisingly capable apps for free if they stay within function execution limits.
When to Choose Cloudflare Pages
Cloudflare Pages is the stronger choice for static sites, statically generated Next.js apps, or projects where server-side behavior is limited to simple API routes that don't need Node.js-specific modules. The free tier is genuinely useful for high-build-frequency projects, and the Workers runtime's performance at scale is excellent.
If you're already using Cloudflare for DNS, WAF, or R2 storage, keeping deployments on the same platform simplifies your architecture and billing. Teams building high-request-volume APIs that can run in the edge runtime will find the per-request pricing model cheaper than Vercel's function execution model at scale.
Wrapping Up
Neither platform is objectively better. The right answer depends on your Next.js feature usage, team size, and traffic shape. Here are the concrete next steps:
- Audit your Next.js features: List every server-side feature your app uses (Middleware, Server Actions, RSC streaming) and check the
@cloudflare/next-on-pagescompatibility table if Cloudflare is on the table. - Estimate your function invocation count: Pull your current request logs or use analytics to get a monthly request number, then run that through Vercel's and Cloudflare's pricing calculators with realistic assumptions.
- Test a preview deployment on both: Both platforms support connecting a repo with minimal setup. Deploy a staging branch to each and run your test suite against it before making a final call.
- Factor in team size over 12 months: If your team is growing, Vercel's per-seat cost compounds. Model what the bill looks like at five, ten, and twenty members before committing.
- Set up billing alerts on day one: Both platforms support spending notifications. Configure them before your first production deployment, not after your first unexpected invoice.
π€ Share this article
Sign in to saveRelated Articles
Affiliate Reviews
PlanetScale vs Upstash for Rate Limiting at Scale: Latency, Cost, and Limits Tested
8m read
Affiliate Reviews
PlanetScale vs Nile for Multi-Tenant Postgres: Isolation, Limits, and Real Costs
3m read
Affiliate Reviews
Courier vs Knock for In-App Notifications: Free Tiers, Channel Limits, and Real Pricing
8m read
Comments (0)
No comments yet. Be the first!