Cloudflare used AI to reimplement Next.js on Vite in a week, and vinext is already in production

Last week, a Cloudflare engineer reimplemented Next.js from scratch on their own. It was done with AI pair programming, and the token cost was about $1,100. The result, vinext, is open source and is already running in production somewhere.

why reimplement Next.js

Next.js is the de facto standard React framework, but deployment to Cloudflare, Netlify, and AWS Lambda has been a long-running problem. Next.js depends heavily on its own Turbopack build chain, so its output has to be transformed for each platform.

OpenNext was created to solve that. But because it has to reverse-engineer Next.js build output, every Next.js release has meant another round of catch-up.

Next.js is working on an official adapter API, but it still remains tied to the Turbopack build chain. The development environment (next dev) only runs on Node.js, and testing Cloudflare-specific APIs such as Durable Objects, KV, and AI bindings required workarounds.

Cloudflare’s conclusion was simple: instead of adapting, reimplement.

what vinext is

vinext reimplements Next.js’s API surface as a Vite plugin. It is not a wrapper around Next.js; it is a separate implementation that speaks the same API. Vite is already the build tool used by most major frontend frameworks, and its output runs on any platform thanks to the Vite Environment API.

npm install vinext

For an existing project, you just replace next with vinext in package.json. app/, pages/, and next.config.js can stay as they are.

vinext dev          # dev server with HMR
vinext build        # production build
vinext deploy       # build and deploy to Cloudflare Workers

It implements routing, server-side rendering, React Server Components, server actions, caching, and middleware, and covers 94% of the Next.js 16 API.

the numbers

The benchmark used a 33-route App Router application. TypeScript type-checking and ESLint were disabled in the Next.js build so the comparison focuses on bundling and compilation speed.

production build time

framework	average time	compared to baseline
Next.js 16.1.6 (Turbopack)	7.38s	baseline
vinext (Vite 7 / Rollup)	4.64s	1.6x faster
vinext (Vite 8 / Rolldown)	1.67s	4.4x faster

client bundle size after gzip

framework	size	compared to baseline
Next.js 16.1.6	168.9 KB	baseline
vinext (Rollup)	74.0 KB	56% smaller
vinext (Rolldown)	72.9 KB	57% smaller

The big speedup comes mainly from Rolldown, Vite 8’s Rust-based bundler. The benchmarks run in GitHub CI on every merge, and the methodology is public.

Cloudflare Workers deployment

vinext deploy

That single command handles the build, automatic Worker config generation, and deployment. Because the whole app, including dev, runs on workerd, Cloudflare-specific APIs such as Durable Objects and AI bindings can be used without workarounds. That is fundamentally different from OpenNext.

ISR uses Cloudflare KV as the cache backend.

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

setCacheHandler(new KVCacheHandler(env.MY_KV_NAMESPACE));

The cache layer is pluggable and can also target R2 or other backends.

traffic-aware pre-rendering

vinext has an experimental feature called Traffic-aware Pre-Rendering, or TPR.

Next.js normally pre-renders every path listed by generateStaticParams(), which means a 100,000-page e-commerce site can end up with a 30-minute build. The build time scales directly with page count.

TPR looks at Cloudflare zone analytics and pre-renders only the pages that are actually receiving traffic.

vinext deploy --experimental-tpr

TPR: 12,847 unique paths — 184 pages cover 90% of traffic
TPR: Pre-rendered 184 pages in 8.3s -> KV cache

If traffic follows a power law, even a million-page site can have 90% of its traffic concentrated in 50 to 200 pages. TPR renders just those and leaves the rest to ISR.

why it could be built in a week

The first commit landed on February 13. That same night, SSR for both Pages Router and App Router was working, along with middleware, server actions, and streaming. The next afternoon, 10 of the 11 App Router Playground routes were rendering successfully. By day 3, vinext deploy could deploy to Workers.

The honest answer is that this was not one person typing everything by hand. It was one engineering manager steering AI, with the human making decisions and design calls while the model generated code. More than 1,700 Vitest tests and 380 Playwright E2E tests were written, including ports from the Next.js test suite and OpenNext’s Cloudflare compatibility suite.

In the first week after launch, National Design Studio’s CIO.gov was already running vinext in production and confirming the build-time and bundle-size gains.

next.js vulnerabilities and vinext’s position

Separate from vinext itself, Next.js has had several security issues over the last year and a half. Because vinext is a reimplementation, it is worth checking where it stands.

Next.js-specific implementation bugs

• CVE-2025-29927 (CVSS 9.1): an auth bypass where x-middleware-subrequest was trusted from external requests, allowing middleware to be skipped entirely
• CVE-2024-34351 (CVSS 7.5): SSRF through Host-header trust during relative redirects in Server Actions
• CVE-2024-46982 (CVSS 8.7): cache poisoning in non-dynamic SSR routes in the Pages Router
• CVE-2024-51479: auth bypass for restricted pages under the root directory
• CVE-2024-56332: DoS where special requests to Server Actions could hang the server

Because vinext does not use Next.js internals at all, those bugs are unlikely to exist there in the same form. Mistakes like trusting an internal header from the outside are the kind of thing that tends to disappear when you rewrite the implementation from scratch.

React-core vulnerabilities that can still affect vinext

• CVE-2025-55182 / CVE-2025-66478 (CVSS 10.0): React2Shell, an RSC deserialization issue in the Flight protocol that allowed unauthenticated RCE
• CVE-2026-23864 (CVSS 7.5): an RSC denial-of-service bug patched in 2026 after several incomplete fixes

These React Server Components issues come from React itself, so vinext can still be affected if it uses RSC. Cloudflare has not published an official statement yet.

This blog previously covered React2Shell notes, a migration from Next.js to Astro because of React2Shell, and the difference between Mintlify and React2Shell vulnerabilities.

Cloudflare’s seriousness

Steve Faulkner, Cloudflare Workers Director, said in GitHub issue #21 that this is still an experiment, but it is backed by a director who can allocate resources directly. Tanner Linsley, the TanStack founder, called it the first viable Next.js fork since OpenNext.

There is also criticism: some people call it vibe-coded copywork and argue the team should prioritize support for existing frameworks like TanStack Start. Vercel has not made an official statement, but a proof of concept running on Vercel exists.

current state and limits

vinext is still experimental. Static pre-rendering at build time (generateStaticParams()) is not implemented yet, so it does not help much for fully static sites right now. The README is honest about the non-goals and known limitations.

The current deployment target is Cloudflare Workers, but about 95% of the implementation is Cloudflare-agnostic pure Vite code. A Vercel proof of concept reportedly worked in less than 30 minutes, and the project is open to PRs for additional deployment targets.