Why I moved from Vercel to Cloudflare Pages
Vercel is the easiest way to deploy a Next.js app. I used it for a while and genuinely liked it. But as my projects grew, I started feeling uneasy about the pricing model, the bandwidth costs, and the fact that Next.js and Vercel are owned by the same company. So I moved everything to Cloudflare Pages.
It was not painless, but I would do it again.
What Vercel gets right
Credit where it is due. Vercel nails the developer experience for Next.js. You connect a GitHub repo, push a commit, and your app is live. Preview deployments for every pull request, automatic HTTPS, serverless functions that just work. Zero config for the common case.
For a solo developer shipping a side project, Vercel's free tier is generous and the time-to-deploy is basically zero. I still think it is a great choice if you are starting out or building something small.
What pushed me to leave
Three things stacked up over time.
Pricing gets uncomfortable at scale. Vercel's free tier is fine for hobby projects, but once you start getting real traffic, the costs climb fast. Bandwidth is metered, serverless function invocations are metered, and the jump from the free tier to the Pro plan is steep. I found myself checking the usage dashboard more than I wanted to.
Bandwidth charges feel wrong in 2025. Cloudflare does not charge for bandwidth. At all. Vercel charges per GB after your included amount. When you are serving images, fonts, and static assets to users globally, that adds up. Paying for bandwidth in an era where CDNs like Cloudflare give it away for free started to feel like a bad deal.
The vendor lock-in question. Vercel makes Next.js. That means the most advanced Next.js features tend to work best (or only) on Vercel's platform. Server Actions, ISR, edge middleware, the caching layer. Some of these have subtle behavior differences when you run them elsewhere. I do not think Vercel is acting in bad faith here, but the incentive structure makes me nervous. If I build deeply on Vercel-specific Next.js features, migrating later becomes harder, not easier.
The solution: OpenNext and Cloudflare Pages
OpenNext is an open-source project that adapts the Next.js build output so it runs on platforms other than Vercel. The @opennextjs/cloudflare adapter specifically targets Cloudflare Pages and Workers.
What it does under the hood: Next.js produces a .next build folder that expects Vercel's infrastructure (their serverless runtime, their CDN, their caching layer). OpenNext takes that build output and rewires it to work with Cloudflare's Workers runtime instead. Static assets go to Cloudflare's CDN, server-side routes become Workers functions, and the whole thing deploys as a single Cloudflare Pages project.
The setup is straightforward. Install the adapter, update your build config, and deploy with wrangler or through the Cloudflare Pages dashboard connected to your Git repo. It took me an afternoon to migrate my first project, including fixing the edge cases.
pnpm add @opennextjs/cloudflareYou add an open-next.config.ts at the project root, adjust your build command, and you are deploying to Cloudflare.
What Cloudflare gives you
The hosting story on Cloudflare is compelling even beyond the Next.js piece.
No bandwidth charges. This is the headline. Cloudflare Pages includes unlimited bandwidth on every plan, including the free tier. For content-heavy sites, this alone can save real money.
A generous free tier. 500 builds per month, unlimited static requests, 100,000 Worker invocations per day on the free plan. For most personal projects and even moderate-traffic apps, you will never pay anything.
The broader platform. Once you are on Cloudflare, you get access to Workers for edge compute, KV for key-value storage, D1 for SQLite at the edge, R2 for S3-compatible object storage, and Queues for async processing. All of this integrates naturally with your Pages project. You are not just getting a host; you are getting an infrastructure platform.
Global CDN included. Cloudflare operates one of the largest CDN networks in the world. Your static assets are cached at hundreds of edge locations by default. No extra configuration needed.
The honest downsides
I would be lying if I said the migration was all upside. There are real tradeoffs.
OpenNext is not feature-complete. Some Next.js features do not work perfectly through the OpenNext adapter. ISR (Incremental Static Regeneration) has limitations. Certain middleware patterns behave differently. The gap is closing with every release, but if you rely on bleeding-edge Next.js features, you might hit rough edges.
Debugging is harder. Vercel's logging and function traces are excellent. The Cloudflare Workers debugging experience is improving, but it is not at the same level yet. When something goes wrong in a server-side route, tracking it down takes more effort.
The ecosystem is younger. Vercel has years of Next.js-specific tooling, integrations, and community knowledge. The OpenNext community is growing fast, but you will find fewer Stack Overflow answers and blog posts when you get stuck. You need to be comfortable reading source code and GitHub issues.
Some features just work better on Vercel. Image optimization, for example. Vercel's built-in image optimization is seamless with next/image. On Cloudflare, you need to set up Cloudflare Images or handle optimization yourself. It is solvable, but it is extra work.
Was it worth it
For me, yes. I sleep better knowing my hosting costs are predictable, my bandwidth is not metered, and I can move my apps to another platform if I ever need to. The OpenNext project gives me confidence that I am not stuck, and the Cloudflare platform gives me tools I actually want to use.
If you are running a small hobby project, Vercel is still great. Do not overthink it. But if you are running multiple projects, serving real traffic, or you just want more control over your stack, Cloudflare Pages with OpenNext is worth the migration effort.
Sources
- OpenNext for Cloudflare - the adapter that makes Next.js work on Cloudflare Pages
- Cloudflare Pages documentation - official docs for Cloudflare Pages
- OpenNext GitHub repository - source code and issue tracker
- Cloudflare Workers pricing - details on the free tier and paid plans
Related posts
Why I built Omnibase: a universal database MCP server
I got tired of copy-pasting query results between DataGrip and AI agents. So I built an MCP server that gives AI agents secure, direct access to any database.
Delta libraries: how diffing works and which library to use
What delta libraries do, how diff algorithms work under the hood, and a practical comparison of the most popular options in the JavaScript ecosystem.
Offline-first apps: harder than it sounds
Building apps that work without internet is one of those things that seems straightforward until you actually try it. Here is what makes it hard and how to approach it.
Enjoying the blog? Subscribe via RSS to get new posts in your reader.
Subscribe via RSS