Back to Blog

Why I deploy most of my Next.js projects to Cloudflare with OpenNext

2026-01-255 min read

I've deployed several Next.js projects to Cloudflare over the past year, including Learn English Sounds (a pronunciation platform with 900+ blog posts in 4 languages, handling around 10K sessions a month), this portfolio site, and a few others.

I've tried Vercel, AWS, Google Cloud, self-hosted. I keep coming back to Next.js + OpenNext + Cloudflare. Not always. My accent training app at accent.learnenglishsounds.com runs on Firebase Hosting with a Cloud Run backend because that made more sense there. But for content-heavy sites, Cloudflare is my default now.

Something interesting: I recently noticed that federal government sites like techforce.gov, safedc.gov, and americabydesign.gov run this exact stack. Next.js on Cloudflare via OpenNext. If the feds trust it for high-profile stuff, it's clearly production-ready.

What is OpenNext?

Here's the problem: Next.js is built by Vercel, and the best features (ISR, middleware, image optimization) are baked into Vercel's infrastructure. Deploy elsewhere and you lose stuff.

OpenNext fixes this. The @opennextjs/cloudflare package converts your Next.js build into something Cloudflare Workers can run natively: App Router, server components, API routes, all of it.

Why Cloudflare over Vercel?

Vercel is great. The DX is genuinely best-in-class. But here's why I moved:

1. Cost at scale

Vercel's free tier is generous for hobby projects, but costs climb fast with traffic. I got a $130 invoice one month. To be fair, Vercel refunded part of it after I reached out. But for simple content sites, that kind of surprise isn't sustainable. Learn English Sounds serves thousands of daily visitors across 4 languages, and bandwidth alone would keep those bills climbing.

Cloudflare gives me:

  • Unlimited bandwidth (all plans)
  • 500 builds/month free, unlimited on paid
  • CDN distribution to 300+ edge locations

I pay $5/month for the Workers Paid plan. That covers multiple production sites.

2. Global performance

Cloudflare's edge network is massive. Static assets cache at edge locations worldwide. With s-maxage=31536000, returning visitors get near-instant loads.

3. Integrated ecosystem

Cloudflare isn't just hosting. I use:

  • Cloudflare Images: Automatic image optimization and resizing
  • Turnstile: Bot protection without annoying CAPTCHAs
  • D1: Serverless SQLite for simple database needs
  • KV: Key-value storage for caching and configuration
  • Workers: Edge functions when I need custom logic

One dashboard, one bill.

The setup

Here's a typical deployment:

1. Install dependencies

npm install @opennextjs/cloudflare

2. Configure OpenNext

Create open-next.config.ts:

import { defineCloudflareConfig } from "@opennextjs/cloudflare";

export default defineCloudflareConfig({});

3. Add wrangler.toml

name = "my-nextjs-site"
main = ".open-next/worker.js"
compatibility_date = "2025-09-11"
compatibility_flags = ["nodejs_compat"]

[assets]
  directory = ".open-next/assets"
  binding = "ASSETS"

4. Build and deploy

npx opennextjs-cloudflare build
npx wrangler deploy

Done. You're running on Cloudflare Workers.

What works well

  • App Router: Full RSC support, layouts, loading states
  • API Routes: Both pages/api and app/api work
  • Middleware: Runs at the edge with full Request/Response API access
  • Static Generation: generateStaticParams works as expected
  • Image Optimization: Works via Cloudflare Images

A few things to watch for

A few things to watch for:

  • ISR limitations: Incremental Static Regeneration works differently. I use stale-while-revalidate patterns instead.
  • Node.js APIs: Some Node APIs aren't available in Workers. Stick to Web APIs when possible.
  • Build times: Large sites take longer since everything compiles to edge-compatible code.
  • Debugging: Error messages can be cryptic. Use wrangler dev locally to catch issues early.

When to use this stack

Works best for:

  • Content-heavy sites (blogs, docs, marketing pages)
  • Multilingual applications
  • Projects where cost predictability matters
  • Teams already using Cloudflare for DNS or security

Getting started

If you want to try this:

  1. Check the OpenNext Cloudflare docs
  2. Start with a simple project to understand the build process
  3. Use wrangler dev for local development
  4. Set up preview deployments for pull requests

The learning curve is minimal if you already know Next.js. Most of your code stays the same.

Stay Updated

Get the latest posts and insights delivered to your inbox.

Unsubscribe anytime. No spam, ever.