Vercel vs Cloudflare Pages for Next.js: Build Limits, Edge Functions, and Real Pricing

June 09, 2026 8 min read 44 views
Two stylized server nodes connected by glowing edge network lines on a minimal gradient background representing cloud deployment comparison

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-pages adapter 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 import of a package that relies on fs, crypto (Node.js built-in, not the Web Crypto API), or net will 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:

  1. Audit your Next.js features: List every server-side feature your app uses (Middleware, Server Actions, RSC streaming) and check the @cloudflare/next-on-pages compatibility table if Cloudflare is on the table.
  2. 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.
  3. 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.
  4. 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.
  5. 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 save

Comments (0)

No comments yet. Be the first!

Leave a Comment

Sign in to comment with your profile.

πŸ“¬ Weekly Newsletter

Stay ahead of the curve

Get the best programming tutorials, data analytics tips, and tool reviews delivered to your inbox every week.

No spam. Unsubscribe anytime.