Cloudflare vinext: Rebuilding Next.js on Vite in One Week with AI

Cloudflare has introduced vinext (pronounced “vee-next”), an experimental alternative implementation of the Next.js API surface built entirely on Vite and designed to deploy natively to Cloudflare Workers with a single command.

What makes vinext remarkable isn’t just the technology—it’s the process. According to Cloudflare, the project was built in under one week by a single engineer, working alongside an AI model, with a total token cost of roughly $1,100.

This positions vinext as both a technical experiment and a case study in AI-assisted framework development.

Why vinext exists: solving the Next.js deployment problem#

Next.js is dominant, but its build and development workflows are deeply tied to a bespoke Node.js toolchain. That tight coupling works well on the default deployment path—but becomes painful when targeting edge runtimes or non-Node platforms.

Cloudflare highlights several long-standing issues:

• Adapting Next.js output to other platforms (for example via OpenNext) requires reverse-engineering build artifacts
• These adapters are fragile across Next.js releases
• Even with work on an adapters API, next dev remains Node-only
• There is no official way to swap runtimes during development

In short: the API is portable, but the tooling is not.

vinext exists to flip that equation.

What vinext is—and what it is not#

Cloudflare is explicit about vinext’s scope:

• ✅ A clean re-implementation of the Next.js API surface
• ❌ Not a wrapper around Next.js
• ❌ Not an adapter transforming Turbopack output

Instead, vinext is implemented as a Vite plugin that reproduces Next.js behavior from the ground up.

Drop-in compatibility goals#

Cloudflare aims for near drop-in compatibility:

• Keep your existing app/, pages/, and next.config.js
• Replace next with vinext in package.json scripts
• Continue using familiar Next.js patterns

Supported features#

vinext currently covers:

• File-system routing (App Router & Pages Router)
• Server-Side Rendering (SSR)
• React Server Components (RSC)
• Server Actions
• Middleware
• Caching APIs

All output is designed to run via the Vite Environment API, making vinext theoretically portable beyond Cloudflare Workers.

Benchmarks: build speed, bundle size, and test coverage#

Cloudflare published early, directional benchmarks comparing vinext with Next.js 16.1.6 (Turbopack) using a shared 33-route App Router fixture.

Build performance#

• Next.js (Turbopack): 7.38s mean production build
• vinext (Vite 8 / Rolldown): 1.67s mean production build
• 👉 ~4.4× faster

Notes: TypeScript checking and ESLint were disabled for Next.js, and force-dynamic was used to avoid pre-rendering skew.

Client bundle size (gzipped)#

• Next.js: 168.9 KB
• vinext (Rolldown): 72.9 KB
• 👉 57% smaller

Cloudflare stresses these results focus on compilation and bundling, not runtime performance, and are based on a single test fixture, not real-world production apps.

Correctness and coverage#

• 1,700+ Vitest unit tests
• 380 Playwright E2E tests
• ~94% API coverage of the Next.js 16 surface

For an experimental project, this level of test investment is notable.

Developer experience: edge-native by default#

vinext is built Cloudflare-first, with Workers as the primary deployment target.

One-command deployment#

vinext deploy

This single command:

1. Builds the app
2. Generates Cloudflare Worker configuration
3. Deploys directly to Workers

Both App Router and Pages Router work on Workers with:

• Client-side hydration
• Navigation
• Preserved React state

Caching and ISR#

vinext supports Incremental Static Regeneration (ISR) using:

• A default Cloudflare KV cache handler
• The standard Next.js setCacheHandler API
• A pluggable cache layer (KV by default, others possible)

Quick start: migrating to vinext#

Manual migration#

npm install vinext
# Replace `next` with `vinext` in package.json scripts

vinext dev
vinext build
vinext deploy

This mirrors the standard Next.js workflow: dev → build → deploy.

AI-assisted migration#

Cloudflare also provides an AI Agent Skill that automates migration:

• Compatibility checks
• Dependency installation
• Config generation
• Dev server startup

Supported tools include Claude Code, Cursor, OpenCode, and Codex.

npx skills add cloudflare/vinext
# Then prompt your AI tool:
# "migrate this project to vinext"

Limitations and experimental status#

Cloudflare is clear: vinext is experimental and not production-proven at scale.

Known limitations include:

• ❌ No static HTML pre-rendering at build time (yet)
• ✅ ISR supported
• 🚧 Static prebuild is on the roadmap

Traffic-aware Pre-Rendering (TPR)#

To address large-site build times, Cloudflare proposes an experimental idea: Traffic-aware Pre-Rendering (TPR).

Instead of pre-rendering every path from generateStaticParams():

• vinext analyzes Cloudflare zone traffic analytics
• Pre-renders only the high-traffic subset
• Stores those pages in KV
• Falls back to on-demand SSR + ISR for the long tail

Example shared by Cloudflare:

• 12,847 total paths
• 184 pages cover 90% of traffic
• Only those 184 pages are pre-rendered

This approach reframes static generation as a data-driven optimization, not a blanket rule.

Why vinext matters (beyond Cloudflare)#

vinext is interesting not because teams should migrate today—but because it demonstrates something bigger:

• A well-specified, well-tested API surface can be reimplemented quickly
• AI-assisted development dramatically lowers the cost of framework replication
• Tooling lock-in becomes weaker when compatibility is reproducible
• Deployment targets and distribution start to matter more than proprietary build systems

In that sense, vinext isn’t just about Next.js—it’s a glimpse at how framework moats may shrink in an AI-accelerated future.

References#

• GitHub: https://github.com/cloudflare/vinext
• Cloudflare Blog: https://blog.cloudflare.com/vinext/