Cloudflare Just Replaced Next.js in a Week. Kind Of.

One engineer at Cloudflare rebuilt 94% of the Next.js API surface in a week. The tool is called Vinext, it runs on Vite, and it cost about $1,100 in AI tokens. Early benchmarks show 4x faster builds and 57% smaller bundles.

If your first reaction was "that's terrifying," you're paying attention.

What Vinext actually is

Vinext is not a fork of Next.js. It's not a wrapper. It's a ground-up reimplementation of the Next.js API surface as a Vite plugin. Your existing app/ directory, pages/ router, next.config.js, server actions, React Server Components: all of it works. You swap next for vinext in your scripts and keep building.

npx vinext init    # Migrate existing project
npx vinext dev     # Dev server with HMR
npx vinext deploy  # Build and deploy to Cloudflare Workers

The critical difference from OpenNext is architectural. OpenNext reverse-engineers the Turbopack build output and reshapes it for non-Vercel platforms. Every Next.js release can break that pipeline. Vinext skips the middleman entirely. It compiles your code with Vite from scratch.

The numbers from their public benchmarks (33-route App Router app, TypeScript checking disabled to isolate bundler speed):

That 57% bundle size reduction is the number I keep staring at. Build speed is nice. Shipping half the JavaScript to users is a different conversation entirely.

The real story isn't the AI part

Every headline focused on the "$1,100 in tokens" angle. That's the least interesting part of this.

The real story is that Next.js has accumulated so much accidental complexity that one engineer could reimplement the useful parts faster than maintaining compatibility with the existing internals. The Turbopack build pipeline, the deployment assumptions baked into the output format, the tight coupling to Vercel's infrastructure: Vinext treats all of that as unnecessary weight.

This is a pattern I've seen repeatedly in large systems. When the adapter layer between your tool and everything else becomes more complex than reimplementing the tool, someone will reimplement it. OpenNext was the adapter. Vinext is the reimplementation.

Cloudflare explicitly called this out: "Building on top of Next.js output as a foundation has proven to be a difficult and fragile approach." That's a polite way of saying the abstraction leaked so badly they gave up patching it.

Why the benchmarks matter (and where they don't)

The 4x build speed improvement comes mostly from Rolldown, the Rust-based bundler shipping in Vite 8. That's not a Vinext win. Any Vite-based framework will get similar gains. Credit goes to the Rolldown team.

The bundle size reduction is more interesting. Next.js ships framework code that Vinext doesn't need because Vite handles module loading differently. Less runtime overhead, fewer polyfills, smaller output. This directly affects your Core Web Vitals: Largest Contentful Paint and Total Blocking Time.

Where the benchmarks fall short: 33 routes is not a production app. I've worked on Next.js projects with 500+ routes, complex middleware chains, and heavy ISR configurations. Vinext doesn't support static pre-rendering at build time yet. For content-heavy sites that rely on generateStaticParams() to build thousands of pages, that's a dealbreaker today.

The 6% that's missing

Cloudflare claims 94% API coverage. That remaining 6% matters more than it sounds.

No build-time static pre-rendering means any site relying on SSG workflows needs to rethink its caching strategy. The ISR support works (cached after first request, revalidated in the background), but your cold-start experience changes. For marketing sites with hundreds of mostly-static pages, that first visitor to each page pays a rendering cost that Next.js would have handled at build time.

The known limitations list also includes gaps in middleware behavior, partial next/image support, and some edge cases in the Pages Router. Production apps with years of accumulated Next.js-specific patterns will hit these.

94% compatibility sounds like an A grade. In production, it feels more like a minefield where you don't know which 6% will bite you until it does.

What this actually changes

Three things are real here:

Framework lock-in is weaker than we thought. If one person can reimplement your framework's API surface in a week, the moat was never the API. It was the ecosystem, the docs, the community, and the deployment pipeline. Vercel's real competitive advantage is the deployment experience, not the framework.

Vite won the build tool war. Astro, SvelteKit, Nuxt, Remix, and now (sort of) Next.js all run on Vite. The Vite Environment API that makes Vinext possible is the same API that lets any framework target any runtime. Turbopack is technically impressive, but it's an island.

AI changes the economics of "should we reimplement this?" The calculation used to be: reimplementation takes 6 months and 5 engineers, so we maintain the adapter. Now the calculation is: reimplementation takes a week and $1,100. That changes which projects get attempted. It doesn't change which ones succeed long-term, because maintenance is the hard part.

The maintenance question nobody's asking

Here's what keeps me skeptical. Next.js releases a major version roughly every year. Minor releases ship constantly. Each one can change internal behavior that Vinext needs to match. Cloudflare is staffing this project today, but will they still be staffing it in two years when the initial excitement fades and the maintenance grind sets in?

OpenNext has the same problem. It's a constant chase. Vinext avoids the "reverse-engineering build output" trap, but it creates a new one: tracking API surface changes across an actively developed framework. When Next.js 17 ships with new APIs, Vinext needs to implement them from scratch. That's not a $1,100 problem. That's an ongoing engineering commitment.

The Cloudflare blog post addresses this obliquely: "We believe it's important we work with partners across the ecosystem to ensure ongoing investment." Translation: we know we can't maintain this alone.

What I'd actually do

If I were starting a new project today and deploying to Cloudflare Workers, I'd look at Vinext seriously. The developer experience of using familiar Next.js patterns with native Workers support (Durable Objects, KV, AI bindings in dev mode) is genuinely better than the OpenNext workaround path.

If I had an existing Next.js app in production, I would not migrate yet. The 94% coverage number needs to be 99%+ before I'd trust it with revenue-generating traffic. Wait for the 1.0 release, wait for the static pre-rendering support, and watch the GitHub issue tracker for a few months.

If I were choosing a framework with no Next.js baggage, I'd still consider Astro or SvelteKit. The entire premise of Vinext is "what if Next.js but on Vite?" If you're already free of Next.js, you don't need a reimplementation of it. You need the right tool for your problem.

The most honest takeaway: Cloudflare built an incredible proof of concept that highlights real problems in the Next.js ecosystem. Whether it becomes a real alternative depends entirely on whether they commit to the boring work of maintaining it after the blog post hype fades.

That boring work doesn't cost $1,100. It costs years.