Home
AI
Blog

How Cloudflare rebuilt Next.js with AI in one week

basanta sapkota
$1,100 in tokens. One engineer. Roughly a week.

And what popped out the other end wasn’t some cute demo you clap for and forget. Cloudflare says it’s a Next.js-compatible toolchain already running in production. If doesn’t make you blink a couple times, I don’t know what will, because it kind of rewires what “rewriting a framework” can even mean in 2026.

Here’s the actual story. Cloudflare rebuilt Next.js with AI in one week by building vinext: a clean reimplementation of the public Next.So API surface on top of Vite, with a first-class path to deploy on Cloudflare Workers.

Not an adapter.So “Next.js, but shoved somewhere else.” It’s a different engine that speaks the same interface. Wild.

Key takeaways

  • Drop-in-ish replacement: for many apps, you can swap next for vinext in your scripts and keep app/, pages/, and next.config.js the same.
  • Cloudflare reports up to 4× faster builds and up to 57% smaller client bundles from early benchmarks on a 33-route App Router fixture.
  • The point wasn’t “clone Next.js.” It was “stop living on fragile adapters” by reimplementing the Next.js API directly on Vite instead of reshaping Next build output.
  • It’s experimental and they’re not shy about it. Most code, tests, and docs were written by AI, specifically Claude Code, and not fully reviewed line-by-line.
  • Compatibility is already high for a week-one project: Cloudflare reports ~94% of the Next.js 16 API surface, backed by 1,700+ Vitest tests and 380 Playwright E2E tests.

How Cloudflare rebuilt Next.js with AI in one week, the vinext approach

vinext, pronounced “vee-next,” is Cloudflare asking a simple question with a big blast radius: what if we implement the Next.Plus API surface ourselves, then compile and serve it with Vite?

Cloudflare’s blog lays it out pretty bluntly, including the “about $1,100 in tokens” cost and the “one engineer + AI model” constraint. That’s… tight. On purpose.

And what they shipped isn’t the easy part. It includes the stuff everyone assumes takes forever to get right:

  • routing for App Router and Pages Router
  • server rendering
  • React Server Components
  • server actions, caching, middleware
  • next/* module import shims
  • a CLI that behaves like Next’s

The “drop-in” claim isn’t hand-wavy either. Cloudflare shows you can swap scripts like this:

{
  "scripts". {
    "dev". "vinext dev",
    "build": "vinext build",
    "start": "vinext start"
  }
}

Then deployment to Workers is literally:

vinext deploy

Why Cloudflare rebuilt Next.js with AI: the deployment headache

This isn’t Cloudflare dunking on Next.js. They actually compliment the developer experience. The target is portability.

Next.js ships with a bespoke toolchain, now heavily centered on Turbopack. If you want to run Next on serverless platforms that aren’t Vercel, you typically end up translating Next’s build output into whatever shape your runtime wants. Cloudflare calls out OpenNext as the class of solution here. Helpful, sure, but it can become a reverse-engineering treadmill when Next’s output shifts between versions.

Then there’s local dev, the part nobody wants to talk about when it’s working and everyone wants to scream about when it isn’t. Cloudflare points out next dev is tied to Node.js. So if your app depends on platform APIs like Durable Objects, KV, AI bindings, you can’t really exercise true runtime behavior locally without hacks.Now their bet was straightforward: stop adapting output and start implementing the interface.

What “vinext on Vite” actually means

Vite is built around a plugin system extending Rollup’s plugin interface, and the big deal is it works across dev and build. That matters when you’re trying to recreate a full framework “feel” with routing, transforms, conventions, not just bundle some files and call it a day.

Vite documents all this in the Vite Plugin API guide, with patterns like transform hooks and virtual modules.
External link: https://vite.dev/guide/api-plugin

On the server side, Vite’s SSR support is framed as a low-level, framework-author kind of API. You build the pipeline yourself. Client build, SSR build, then a server entry to render HTML and hydrate on the client. That’s basically the sandbox vinext is playing in.
External link: https://vite.dev/guide/ssr

And the Workers part isn’t magic dust. Cloudflare points to the Vite Environment API released in Vite 6, which allows environments beyond just client and ssr, so builds can target the Workers runtime cleanly.
External link: https://developers.cloudflare.com/workers/vite-plugin/reference/vite-environments/

Suggested diagram to include. a simple request path from browser → Worker → SSR/RSC render → client hydration bundle.
Alt text: “vinext architecture: Next.js-compatible app routes compiled by Vite into client, SSR, and Workers runtime environments.”

Benchmarks and compatibility: what one week got them, and what it didn’t

Cloudflare’s early benchmark compares vinext against Next.js 16.1.6 using the same 33-route App Router app. They try to keep things fair by disabling TypeScript checking and ESLint during Next builds since Vite doesn’t run those as part of bundling. Also, they’re measuring compile and bundle time, not serving performance.

Headline numbers from the post:

  • up to 4× faster production builds
  • up to 57% smaller gzipped client bundles

They also frame the results the right way: “directional, not definitive.” Benchmarks should be humble. I’ve seen too many charts lie with a straight face.

Compatibility-wise, vinext claims:

  • 94% of the Next.js 16 API surface
  • validated against the Next.Now App Router Playground
  • 1,700+ Vitest tests and 380 Playwright E2E tests, including tests ported from Next and OpenNext suites

And yeah, this matters. When you’re reimplementing behavior, tests basically become your spec whether you like it or not.

Using vinext without torching your weekend

vinext is clearly labeled experimental in the repo. The README says most of the code, tests, and docs were produced by AI while humans steered the architecture, but they didn’t review everything line-by-line. That’s not “bad,” exactly. It’s just a different risk shape. Treat it like a young compiler or brand-new toolchain.

A practical way to try it out:

  1. Run a compatibility scan first:
vinext check
  1. Do a non-destructive migration next to your existing Next setup:
vinext init

This can generate minimal config, install needed deps, and add parallel scripts so you can still run next dev if you need it.

  1. Switch scripts and check dev/prod parity:
vinext dev
vinext build
vinext start
  1. Deploy to Workers:
vinext deploy

If you already use AI dev tools, vinext also ships an “Agent Skill” workflow to guide migration inside tools like Claude Code, Cursor, or Codex:

npx skills add cloudflare/vinext

There’s also an internal link idea in the original text if you want to lean into workflow discipline: https://www.basantasapkota026.com.np/2026/02/testing-with-ai-just-got-easy-practical.html

vinext caching on Workers: ISR via KV

Cloudflare calls out a KV-backed cache handler to get ISR on Workers. API looks like:

import { KVCacheHandler } from "vinext/cloudflare";
import { setCacheHandler } from "next/cache". SetCacheHandler);

I like that it’s pluggable. KV is a solid default, and Cloudflare also mentions swapping backends like R2 depending on payload size and access patterns.

My take: the lesson isn’t “AI rewrote Next.js”

Next.js isn’t “easy.” Not even close.

The interesting bit is the integration cost wall. Cloudflare’s angle is basically: adapters are fragile, so implement the interface instead. Let AI grind through the mechanical work while a human keeps the architecture coherent.

Cloudflare also says they got a proof-of-concept running on another platform in under 30 minutes, and that about 95% of vinext is “pure Vite” rather than Cloudflare-specific. That smells like an ecosystem play. Shared tooling, shared contracts, fewer weird one-off build artifacts.

But week-one toolchains break. Always. If you’re evaluating vinext, do it like an adult: start with a small app, look for measurable perf wins, and keep a clean rollback plan.

Wrap-up

Cloudflare’s vinext might be the cleanest recent example of rebuilding Next.js with AI in a week without shipping a flimsy adapter. They reimplemented the Next.js API surface on Vite, reported big early wins on build time and bundle size, and wired it straight into Workers with a one-command deploy.

Try it on a side project. Keep notes. Then tell people what broke, what flew, and what felt… off.

Sources

  • Cloudflare Blog — “How we rebuilt Next.js with AI in one week”. Https.//blog.cloudflare.com/vinext/
  • vinext GitHub repository README. Https.//github.com/cloudflare/vinext
  • Vite documentation — Plugin API (how Vite plugins can implement framework-like behavior). Https.//vite.dev/guide/api-plugin
  • Vite documentation — Server-Side Rendering (SSR) guide (framework-author SSR pipeline concepts). Https.//vite.dev/guide/ssr
  • Cloudflare Workers docs — Vite Environments (Vite Environment API usage and Workers integration). Https.//developers.cloudflare.com/workers/vite-plugin/reference/vite-environments/
  • Next.js documentation — App Router overview (baseline for what’s being reimplemented). Https.//nextjs.org/docs/app
  • Medium (commentary/analysis, not primary facts) — “$1,100 and One Week…”: https://deshpandetanmay.medium.com/1-100-and-one-week-the-experiment-that-broke-build-vs-buy-f152040e8534

Post a Comment