The verdict: Cloudflare just dropped a certified W on the entire Next.js ecosystem. vinext is not a wrapper, not an adapter, not another OpenNext — it’s a clean reimplementation of the Next.js API surface on Vite, built in one week by one engineer and an AI, and the benchmarks are not a drill.
4.4× faster builds. 57% smaller bundles. npm install vinext. That’s the pitch.
The Problem That Made This Necessary
If you’ve ever tried deploying Next.js to anything that isn’t Vercel, you know the pain. Next.js’s toolchain is entirely bespoke — built around Turbopack, optimised for Vercel, and difficult to reshape for other platforms.
OpenNext exists precisely because of this. It’s a community project that reverse-engineers Next.js’s build output to make it run on Cloudflare, Netlify, and AWS Lambda. It works. Until it doesn’t. Every Next.js version bump risks breaking the reverse-engineering assumptions, and maintaining compatibility is a constant game of whack-a-mole.
Cloudflare has been collaborating with Vercel on a first-class adapters API. That’s still early. And even adapters only cover build and deploy — they don’t fix the dev experience problem: next dev runs in Node.js only, with no way to test Durable Objects, KV, or AI bindings without workarounds.
The premise of vinext: what if you skip the adapter entirely and just reimplement the API surface on Vite?
What vinext Actually Is
vinext is not a fork. It’s not a wrapper around Next.js. It’s an alternative implementation of the routing, server rendering, RSC, server actions, caching, and middleware APIs — all built on top of Vite as a plugin.
Migration is a single command:
npm install vinext
# Replace 'next' with 'vinext' in package.json scripts. Done.
vinext dev # dev server with HMR
vinext build # production build
vinext deploy # build + deploy to Cloudflare WorkersYour existing app/, pages/, and next.config.js work as-is. All 33 next/* imports are shimmed automatically — no rewrites needed. 94% of the Next.js 16 API surface is covered out of the box.
The Numbers That Actually Matter
Early benchmarks against a shared 33-route App Router application:
| Framework | Build time | vs Next.js |
|---|---|---|
| Next.js 16.1.6 (Turbopack) | 7.38s | baseline |
| vinext (Vite 7 / Rollup) | 4.64s | 1.6× faster |
| vinext (Vite 8 / Rolldown) | 1.67s | 4.4× faster |
| Framework | Bundle size (gzipped) | vs Next.js |
|---|---|---|
| Next.js 16.1.6 | 168.9 KB | baseline |
| vinext (Rollup) | 74.0 KB | 56% smaller |
| vinext (Rolldown) | 72.9 KB | 57% smaller |
The key is Rolldown — the Rust-based bundler coming in Vite 8. Vite’s architecture has structural advantages for build performance that show up clearly here. These benchmarks are directional, not definitive — one 33-route app isn’t a representative sample — but the direction is hard to ignore. Benchmarks run on GitHub CI on every merge. Methodology and live results are public.
Built by One Engineer. With AI. In Seven Days. For $1,100.
Here’s the part that should make every engineering team sit with their thoughts for a minute. This wasn’t a six-month project with a dedicated team. One Cloudflare engineer and an AI rebuilt the most popular React framework’s API surface — 94% coverage, 2,080+ tests — in one week, for approximately $1,100 in tokens.
“We honestly didn’t think it would work,” the Cloudflare team wrote in the announcement post. “But it’s 2026, and the cost of building software has completely changed.”
That’s the real story here. vinext’s existence is the headline — but the method of its creation is the data point that should inform every senior engineer’s roadmap for the next 18 months.
Cloudflare Workers Native
vinext is built with Cloudflare Workers as the primary deployment target. vinext deploy auto-generates your worker config, builds, and ships in one command. Both App Router and Pages Router work on Workers with full client hydration, navigation, and React state.
ISR via Cloudflare KV is built in. Durable Objects, AI bindings, KV, R2 — no workarounds, no adapter shimming, just direct access.
The experimental Traffic-aware Pre-Rendering (TPR) is the sleeper feature. Instead of pre-rendering your whole site at build time, vinext queries Cloudflare zone analytics and pre-renders only the pages that actually get traffic — then caches them to KV. For a store with 100,000 product pages, you pre-render the 184 that drive 90% of traffic. That’s not a small optimisation.
The Actual Verdict
vinext is 0.1.0. It’s experimental. Cloudflare are honest that 6% of the Next.js API surface isn’t covered yet. Don’t migrate your critical production app today.
But the direction is clear. A clean Vite-based implementation with Workers-native deployment, built with AI assistance in a week, producing measurably better build performance? The OpenNext whack-a-mole era is on notice.
npm install vinext. Try it on a side project. The dev experience alone — being able to test Durable Objects and KV bindings in dev without workarounds — is worth it for anyone already on the Cloudflare stack. W.
