Vercel vs Cloudflare vs self-hosted Next.js: the 2026 cost+DX table

I've deployed Next.js applications on all three: Vercel for 4 projects, Cloudflare Pages for 2, and self-hosted (Docker on Railway/Fly) for 3. Each has a sweet spot. Each has a pricing cliff.

This is the comparison I wish existed when clients ask "where should we host this?" — real numbers, real gotchas, no affiliate links.

The table

Vercel: the default, for good reason

Vercel builds Next.js. The DX is unmatched — push to git, deployment in 45 seconds, preview deployments for every PR, analytics built in. Every Next.js feature works on day one because they ship the framework and the platform together.

Where I use it: Client projects where development speed matters more than hosting cost. Startups that need to ship fast, iterate weekly, and not think about infrastructure. 4 of my last 6 Next.js projects deployed on Vercel.

Where it gets expensive:

1. Per-seat pricing. $20/user/month on Pro. A 3-person team is $60/month for hosting. That's competitive with managed platforms but expensive compared to a $5/month VPS. For a solo founder, $20/month is fine. For a 10-person team, $200/month just for hosting starts to sting.

2. Function execution. The Pro plan includes 1000 GB-hours of serverless function execution. If you're running heavy API routes (image processing, PDF generation, data aggregation), you can blow through this. One client hit $85/month in overage charges from a PDF export feature that ran on every order.

3. Bandwidth at scale. 1TB included on Pro. For a content site or SaaS dashboard, that's plenty. For a media-heavy app serving video or large files, 1TB goes fast. We moved one client's file serving to Cloudflare R2 + a custom domain to avoid Vercel bandwidth charges.

4. Edge function limits. Edge functions have a 4MB bundle size limit and limited Node.js API support. If your middleware or API routes need heavy dependencies, you're pushed to Node.js serverless functions, which have cold starts.

The real cost for a typical SaaS MVP:

For a solo developer shipping an MVP, Vercel Pro + Neon free tier is hard to beat at ~$20/month.

Cloudflare Pages: the bandwidth play

Cloudflare's edge network is enormous and bandwidth is genuinely unlimited on all plans. If your Next.js app is primarily static content with some dynamic routes, Cloudflare Pages is significantly cheaper than Vercel at scale.

Where I use it: Marketing sites, documentation sites, and content-heavy applications where most pages can be statically generated. Two client projects: a multilingual portfolio site and a product documentation site.

Where it falls short:

1. Next.js compatibility gaps. Cloudflare uses the OpenNext adapter to run Next.js outside Vercel. Most features work, but some don't: Image Optimization requires a custom loader (Cloudflare Images or a third-party), next/font needs manual configuration, and some edge cases in App Router middleware behave differently. I spent 4 hours debugging a middleware redirect loop that only happened on Cloudflare.

2. Workers runtime limits. Cloudflare Workers use V8 isolates, not Node.js. If your API routes depend on Node.js-specific APIs (fs, crypto with certain algorithms, native modules), they won't work without adaptation. This is improving — Workers now support much of the Node.js API — but it's not 100%.

3. Build output size. Cloudflare has a 25MB limit on Worker bundle size (after compression). Most Next.js apps fit, but if you're bundling heavy dependencies (PDF libraries, image processors), you can hit this. The fix is usually moving that logic to a separate service.

4. Preview deployments. They exist but aren't as polished as Vercel's. No commenting on previews, no integration with Vercel's analytics. For teams that rely on PR-based review workflows, this matters.

The real cost for a content-heavy site:

For a content site with moderate dynamic features, Cloudflare is half the cost of Vercel.

Self-hosted: the control play

Self-hosting means running Next.js in standalone mode (output: 'standalone' in next.config.js), packaging it in a Docker container, and deploying to Railway, Fly.io, a VPS (Hetzner, DigitalOcean), or your own infrastructure.

Where I use it: Projects that need predictable billing, heavy server-side processing, or specific infrastructure requirements. Three client projects: a SaaS with background job processing (Railway), an internal tool behind a VPN (Hetzner VPS), and a high-traffic API (Fly.io with multi-region).

Where it shines:

1. Predictable billing. A $6/month Railway instance or a $5/month Hetzner VPS runs 24/7 with no per-request charges, no bandwidth surprises, no seat-based pricing. Your bill is the same whether you serve 1K or 100K requests/day (within the instance's capacity).

2. Full Node.js runtime. No edge function limits, no Worker compatibility issues. Your API routes can use any Node.js module, spawn child processes, access the filesystem. If you need sharp for image processing or puppeteer for PDF generation, self-hosting is the simplest path.

3. Background jobs. Vercel and Cloudflare are designed for request-response patterns. If you need cron jobs, queue workers, or long-running processes, self-hosting lets you run them alongside your app.

Where it hurts:

1. You own the ops. Deployments, SSL certificates, health checks, log management, scaling — all on you. Vercel handles all of this automatically. On Railway or Fly, most of it is handled. On a raw VPS, it's all manual.

2. No preview deployments by default. You need to build your own PR preview pipeline (GitHub Actions + dynamic subdomains) or skip it. Most teams skip it and miss the workflow benefit.

3. Slower deploy cycle. Docker builds take 2–5 minutes vs Vercel's 45 seconds. For teams that deploy 10 times/day, this adds up. For weekly deploys, it doesn't matter.

4. Cold starts on serverless platforms. If you self-host on a serverless container platform (Railway's autoscaling, Fly machines with auto-stop), you get cold starts when the container spins up. Typically 1–3 seconds, much worse than Vercel's Edge functions.

The real cost for a SaaS with background processing:

When to pick what

Pick Vercel when:

• You're a solo developer or small team shipping a Next.js app
• Development speed and DX matter more than hosting cost
• You use Next.js features heavily (ISR, middleware, image optimization, server actions)
• You want preview deployments and analytics without setup

Pick Cloudflare when:

• Your app is primarily static or edge-rendered
• Bandwidth is a significant cost factor
• You're comfortable with Workers runtime constraints
• You want the cheapest possible hosting for a production site

Pick self-hosted when:

• You need predictable, flat-rate billing
• Your app requires background processing, cron jobs, or heavy server-side compute
• You need full Node.js runtime without restrictions
• You want to avoid vendor lock-in with Vercel's platform

My default

For most client MVPs: Vercel Pro. The DX wins pay for themselves in developer hours saved. When a client needs background processing or hits Vercel's cost ceiling, we migrate to Railway — the standalone output makes this a 2-hour task.

Choosing a hosting stack for your Next.js project? Let's talk — I'll recommend based on your traffic pattern, team size, and feature requirements.