Cloudflare Just Built a Next.js Replacement in One Week With AI — And It Could Free Thousands of Developers From Vercel's Bills

If you have ever built a serious web application with Next.js, you know the moment. Everything is working beautifully in development. You are ready to deploy. And then you look at Vercel's pricing page.

For small projects and side hustles, Vercel's free tier is generous enough. But the moment your application gets real traffic, needs proper team collaboration, or requires advanced features like ISR caching and edge functions at scale, the bills climb fast. Vercel's Pro plan starts at $20 per month per team member. Enterprise pricing is custom, meaning expensive. And because Next.js was built by Vercel, deploying it anywhere else has always involved a painful compatibility dance with tools like OpenNext that require constant maintenance as Next.js versions change.

For years, developers have wanted a clean escape route. Last week, Cloudflare built one in seven days, with AI, for $1,100 in API tokens.

What Is vinext?

Vinext (pronounced "vee-next") is Cloudflare's open-source, drop-in replacement for Next.js. It implements the Next.js API surface that is routing, server rendering, React Server Components, server actions, caching, middleware but builds everything on top of Vite, the build tool that powers most of the modern frontend ecosystem outside of Next.js.

The installation and migration is deliberately minimal:

npm install vinext

Replace next with vinext in your package.json scripts. Your existing app/, pages/, and next.config.js stay exactly as they are. Then:

vinext dev        # Development server with hot module replacement
vinext build      # Production build
vinext deploy     # Build and deploy directly to Cloudflare Workers

That last command — vinext deploy — is the one that matters most. A single command takes your Next.js application and puts it on Cloudflare Workers, one of the cheapest and most globally distributed serverless platforms available. No adapter configuration. No reverse-engineering Turbopack output. No OpenNext whack-a-mole every time Next.js ships a new version.

This is not a wrapper around Next.js. It is a full reimplementation of what Next.js does, built from scratch on different foundations.

The Vercel Problem, Explained

To understand why this matters, you need to understand the lock-in that has built up around Next.js over the past several years.

Next.js is the most popular React framework by a significant margin. It introduced features like server-side rendering, static site generation, API routes, and most recently React Server Components, features that fundamentally changed how React applications are built. Millions of developers have learned these patterns. Millions of production applications are built on them.

The problem is that Next.js was built by Vercel, and its internal architecture has been deeply optimised for Vercel's own infrastructure. The build toolchain, Turbopack, is bespoke. The output format is proprietary. When you try to deploy a Next.js application anywhere other than Vercel, you are fighting against an architecture that was not designed for you.

OpenNext has been the community's answer to this for the past two years. It reverse-engineers Next.js's build output and reshapes it for other platforms such as Cloudflare, AWS Lambda, Netlify. But reverse-engineering means fragility. Every Next.js version update potentially breaks the adapter. The teams maintaining OpenNext (including Cloudflare's own engineers ) have described the process as "whack-a-mole." Fix one thing, another breaks.

Vercel's own first-class adapters API is in progress, and Cloudflare has been collaborating with the Next.js team on it. But even with adapters, the bespoke Turbopack toolchain remains. And during development, next dev runs exclusively in Node.js meaning if your application uses Cloudflare-specific APIs like Durable Objects, KV, or AI bindings, you cannot test that code in development without workarounds.

Vinext eliminates all of these problems at the root.

The Numbers Are Not Marketing

Cloudflare published benchmark results comparing vinext against Next.js 16, using a shared 33-route App Router application. The methodology is transparent. Full details and historical results are public at benchmarks.vinext.workers.dev.

Production build time:

Client bundle size (gzipped):

Cloudflare is explicit that these benchmarks measure compilation and bundling speed, not production serving performance, and that the test fixture is a single app rather than a representative sample. The direction, however, is significant. Vite's architecture and especially Rolldown, the Rust-based bundler coming in Vite 8, has structural performance advantages over Turbopack that show up clearly in the numbers.

For a developer running builds dozens of times a day, a 4x speed improvement is not a statistic. It is time back in your day.

The Feature That Is Genuinely New

ISR ( Incremental Static Regeneration ) and caching are already working in vinext via Cloudflare KV. App Router and Pages Router both work on Cloudflare Workers with full client hydration. But the feature that stands out as genuinely novel is something Cloudflare is calling Traffic-aware Pre-Rendering.

In Next.js, if you want to pre-render pages at build time, which makes them load instantly for users because the HTML is already generated , you have to enumerate every page you want pre-rendered using generateStaticParams(). For a large e-commerce site with 100,000 product pages, this means your build touches every one of those pages. Builds scale linearly with page count. This is why large Next.js sites end up with 30-minute build times.

Traffic-aware Pre-Rendering approaches this differently. Cloudflare is already the reverse proxy sitting in front of your website. It already knows which pages actually get traffic. So instead of pre-rendering everything, vinext queries Cloudflare's zone analytics at deploy time and pre-renders only the pages that actually get visited:

vinext deploy --experimental-tpr

Building...
Build complete (4.2s)

TPR: Analyzing traffic for my-store.com (last 24h)
TPR: 12,847 unique paths — 184 pages cover 90% of traffic
TPR: Pre-rendering 184 pages...
TPR: Pre-rendered 184 pages in 8.3s → KV cache

Deploying to Cloudflare Workers...

The power law of web traffic means that for most large sites, 90% of visits go to a small fraction of pages. Traffic-aware Pre-Rendering identifies that fraction automatically, pre-renders those pages in seconds, and lets everything else be served on-demand via ISR. Pages that suddenly go viral get picked up on the next deploy. No generateStaticParams(). No coupling your build to your production database. No 30-minute builds.

It is experimental today but the concept is sound and it demonstrates what becomes possible when your build tool and your CDN are made by the same company.

One Engineer. One Week. $1,100 in AI Tokens.

Here is the part of this story that deserves its own conversation because it says something important about where software development is heading.

A project like vinext would normally take a team of engineers months, if not years. Several teams have attempted to build a proper Next.js alternative. Cloudflare tried before and did not finish. The scope, two routers, 33+ module shims, server rendering pipelines, RSC streaming, file-system routing, middleware, caching , is genuinely enormous.

This time, one engineering manager directing AI completed it in under a week.

The first commit landed on February 13. By the end of that evening, both the Pages Router and App Router had basic SSR working. By the next afternoon, the App Router Playground was rendering 10 of 11 routes. By day three, vinext deploy was shipping apps to Cloudflare Workers with full client hydration. The rest of the week was hardening: edge cases, test coverage, API surface expansion.

The entire codebase was written by AI. But it passes 1,700+ Vitest unit tests and 380 Playwright end-to-end tests. TypeScript type checking runs via tsgo. Linting runs via oxlint. CI runs all of it on every pull request. API surface coverage sits at 94% of Next.js 16.

The total cost was approximately $1,100 in Claude API tokens.

What made this possible where previous attempts failed? Steve Faulkner, the Cloudflare engineering manager who led the project, points to four things aligning simultaneously: Next.js is exceptionally well-documented, so the AI knew the target API inside out. Next.js has an elaborate test suite, giving a mechanical specification to verify against. Vite is an excellent foundation that handled the hard parts of frontend tooling. And current AI models can sustain coherence across a codebase this complex in a way that earlier models simply could not.

Faulkner is also candid about what the human still had to do. Architecture decisions, prioritisation, recognising when the AI was headed down a dead end, that was all him. The AI did not steer. It executed under direction. But the gap between what a skilled human directing AI can produce in a week and what a team of engineers could produce in months has compressed dramatically. Vinext is a data point that the software industry will be processing for some time.

What This Means for Developers in Kenya and Africa

For developers building on Vercel in Kenya, the economics of vinext are worth sitting with directly.

Cloudflare Workers' free tier includes 100,000 requests per day. The paid plan, Workers Paid, costs $5 per month for 10 million requests, then $0.30 per million after that. Cloudflare KV, R2, and Durable Objects ( the services that replace Vercel's edge caching and storage) are priced at fractions of what equivalent AWS or Vercel services cost. There are no egress fees on R2, as we covered in our piece on Cloudflare's Local Uploads feature.

For a Kenyan startup or indie developer running a Next.js application on Vercel's Pro plan at $20 per seat per month, vinext is not just a technical alternative. It is a significant cost reduction on infrastructure that is already a meaningful line item when you are operating in a market where margins are thin and dollar-denominated bills are paid in shillings.

There are caveats. Vinext is experimental. It does not yet support static pre-rendering at build time, though ISR covers most dynamic use cases. Some Next.js features are explicitly not supported and will not be, because they are tied to Vercel-specific infrastructure. If you are running a large production Next.js application with complex requirements, wait for more battle-testing before migrating. The README is honest about limitations, which is a good sign.

For new projects, however, vinext is already a credible choice. CIO.gov, a US government website managed by National Design Studio, is already running vinext in production. The fact that a government web team considered it production-ready within a week of its public release says something about the quality of the test coverage.

The Bigger Pattern

We have written several pieces recently about Cloudflare's moves in the developer infrastructure space that is R2 Local Uploads cutting cross-region write latency for African developers, Markdown for Agents enabling AI systems to read web content cleanly, WebMCP enabling AI agents to take actions on websites. Vinext fits into a pattern that is becoming increasingly clear.

Cloudflare is systematically building an alternative to every major proprietary piece of the web development stack. R2 instead of S3. Workers instead of Lambda. KV instead of DynamoDB for edge data. Pages instead of Netlify. And now vinext instead of Next.js on Vercel.

Each individual piece is compelling on its own. Together, they represent a coherent vision of a web development platform that is open, portable, and priced for developers who are not operating at enterprise scale. For developers in Kenya and across Africa, where infrastructure costs are felt more acutely because they are paid in local currencies against dollar-denominated bills, that vision is not abstract. It has real economic implications.

Vinext is experimental today. In six months, if the project matures at the pace it has already demonstrated, it could become the default deployment target for a significant portion of new Next.js projects. Not because it is better than Vercel in every dimension. Vercel's developer experience is genuinely excellent. But because for most applications, the Cloudflare alternative will be good enough and substantially cheaper.

Good enough and substantially cheaper has a way of winning.