In late February 2026, Cloudflare published a blog post that quietly set off a debate across the JavaScript community. The post described how a single engineer, directing an AI model, had rebuilt Next.js from scratch in under one week. The resulting framework is called vinext, it covers 94% of the Next.js 16 API surface, builds 4.4x faster than the original, and ships bundles that are 57% smaller. It also deploys to Cloudflare Workers with a single command. vinext Depending on who you ask, this is either a fascinating engineering story, a bold infrastructure play by Cloudflare, or a signal that the economics of building developer frameworks has changed forever. Probably all three. Let me walk you through exactly what vinext is, how it was built, what it actually does well, and why this whole thing matters well beyond a performance benchmark. What Is Vinext? Vinext is a Vite plugin that reimplements the public API surface of Next.js. It is not a fork of Next.js. It is not a wrapper around it. It is a clean-room reimplementation that supports the same routing conventions, the same rendering strategies, and the same module imports (things like next/navigation, next/image, next/headers) but runs on Vite instead of Turbopack. next/navigation next/image next/headers That difference matters. Vite is a build tool that the JavaScript community largely loves. It is fast, well-maintained, and has an excellent plugin ecosystem. Turbopack is Vercel’s bet on Rust-based bundling that, while improving, is tightly bound to the Next.js release cycle and to Vercel’s infrastructure. Vinext sits on top of Vite and benefits immediately from that ecosystem. The project is open source under the MIT license and available at github.com/cloudflare/vinext. You can install it today, run your existing Next.js app on it without changing your source code, and deploy it to Cloudflare Workers with a single vinext deploy command. github.com/cloudflare/vinext vinext deploy It also runs on Vercel. A proof-of-concept deployment to Vercel took less than 30 minutes in the team’s own testing. Platform-agnosticism is a stated design goal. The Build That Took One Week and $1,100 Here is where the story gets interesting. Cloudflare did not assemble a team and spend months on this. One engineer directed an AI model, specifically Claude Opus 4.6, through more than 800 development sessions using a tool called OpenCode. The work began on February 13. By February 15, there was a full deployment pipeline running with client hydration. By the end of the week, 94% of the Next.js API surface was covered and over 2,000 tests were passing. The total cost in API tokens: approximately $1,100. This is a number worth sitting with. Not because it is shockingly cheap (though it is), but because of what it reveals about how certain types of software are now built. The engineer was not writing the implementation code. They were designing the architecture, decomposing problems into tractable tasks, setting acceptance criteria, and reviewing what the AI produced. The AI wrote the code. The tests caught the regressions. The methodology is worth understanding in detail, because it is replicable. The Test-Suite-as-Specification Approach Next.js ships with thousands of end-to-end tests and unit tests. These tests describe exactly what the framework should do in response to specific inputs. They cover routing behavior, server component rendering, streaming, error boundaries, middleware execution, cache headers, and dozens of other concerns. These tests are public. They live in the Next.js repository on GitHub, available for anyone to read. What the vinext team did was treat those tests as machine-readable specifications. Instead of trying to understand the intent behind a feature and then implementing it, the approach was: port the test, run it, fail, iterate until it passes, move to the next one. As one analysis of the project put it: “The AI did not need to understand human intent. It needed to make assertions pass.” This is a genuine methodological shift. When the acceptance criteria are already written as executable code, a capable AI model can grind through implementation work with very little human intervention beyond architecture decisions. The human becomes the system designer and the quality gate. The model becomes the implementer. The development timeline shows how effective this was. Day 1 covered Pages Router, App Router SSR, middleware, server actions, and streaming. Day 2 had the App Router playground rendering 10 of 11 routes. Day 3 had a working deployment pipeline with client hydration. Days 4 through 7 expanded the test suite, fixed edge cases, and pushed API coverage to 94%. The final test count sits at 1,700 Vitest unit tests and 380 Playwright end-to-end tests. What Vinext Actually Supports Let’s be specific about features, because “94% of the Next.js API surface” is a marketing-friendly number that deserves unpacking. Vinext supports the App Router in full: nested layouts, loading states, error boundaries, parallel routes, and intercepting routes. It supports the Pages Router as well, including getStaticProps, getServerSideProps, and getStaticPaths. React Server Components work, streaming SSR with Suspense boundaries works, server actions with FormData support work, and middleware is functional. App Router Pages Router getStaticProps getServerSideProps getStaticPaths On the module side, vinext ships 33 shims that automatically cover all next/* import paths. You do not need to change a single import in your codebase. next/navigation, next/image, next/link, next/headers, next/cookies and the rest all resolve to vinext’s own implementations. next/* next/navigation next/image next/link next/headers next/cookies Incremental Static Regeneration works, backed by Cloudflare KV. The “use cache” directive, cacheLife(), and cacheTag() are supported. Static exports work for pre-rendering to HTML and JSON. cacheLife() cacheTag() What does not work yet? Full static pre-rendering via generateStaticParams() is on the roadmap but not shipped. The team is transparent about this. The project page says it clearly: this is experimental software, use it at your own risk. generateStaticParams() One real organization is not waiting: the National Design Studio’s CIO.gov (the official U.S. government Chief Information Officer website) is already running vinext in production beta. That is not nothing. The Performance Numbers Performance claims in the JavaScript ecosystem need to be approached carefully because benchmarks are easy to game and context is everything. With that caveat stated, here is what Cloudflare measured using a 33-route test application. Build time comparison: Framework

Build Time



Next.js 16.1.6

7.38 seconds



Vinext (Vite 7 / Rollup)

4.64 seconds (1.6x faster)



Vinext (Vite 8 / Rolldown)

1.67 seconds (4.4x faster) Framework

Build Time



Next.js 16.1.6

7.38 seconds



Vinext (Vite 7 / Rollup)

4.64 seconds (1.6x faster)



Vinext (Vite 8 / Rolldown)

1.67 seconds (4.4x faster) Framework

Build Time Framework Framework Build Time Build Time Next.js 16.1.6

7.38 seconds Next.js 16.1.6 Next.js 16.1.6 7.38 seconds 7.38 seconds Vinext (Vite 7 / Rollup)

4.64 seconds (1.6x faster) Vinext (Vite 7 / Rollup) Vinext (Vite 7 / Rollup) 4.64 seconds (1.6x faster) 4.64 seconds (1.6x faster) Vinext (Vite 8 / Rolldown)

1.67 seconds (4.4x faster) Vinext (Vite 8 / Rolldown) Vinext (Vite 8 / Rolldown) 1.67 seconds (4.4x faster) 1.67 seconds (4.4x faster) Gzipped client bundle size: Framework

Bundle Size



Next.js 16.1.6

168.9 KB



Vinext

72.9 KB (57% smaller) Framework

Bundle Size



Next.js 16.1.6

168.9 KB



Vinext

72.9 KB (57% smaller) Framework

Bundle Size Framework Framework Bundle Size Bundle Size Next.js 16.1.6

168.9 KB Next.js 16.1.6 Next.js 16.1.6 168.9 KB 168.9 KB Vinext

72.9 KB (57% smaller) Vinext Vinext 72.9 KB (57% smaller) 72.9 KB (57% smaller) The 4.4x build time improvement comes specifically from Vite 8 with Rolldown, which is the Rust-based rewrite of Rollup that the Vite team has been building. If Rolldown lives up to its benchmarks in general use (and early signs suggest it does), vinext gets faster automatically as the Vite ecosystem matures. That is a nice structural advantage. The bundle size difference is more immediately meaningful for users. Smaller bundles mean faster page loads, especially on mobile connections. A 57% reduction in the baseline JavaScript that every visitor downloads is a meaningful improvement in real-world performance. The team is careful to note that these are compile and bundle benchmarks, not production serving benchmarks. They do not measure time-to-first-byte or rendering performance, which are governed by different variables. The data is real but should not be extrapolated beyond what it measures. Traffic-Aware Pre-Rendering: A New Idea Among all the features, the one that stands out as genuinely novel is Traffic-aware Pre-Rendering, or TPR. Traffic-aware Pre-Rendering Traditional static site generation has a scaling problem. If your e-commerce site has 100,000 product pages, you have to either pre-render all 100,000 pages at build time (which takes forever and often is not worth it for pages that get no traffic) or serve everything dynamically (which gives up the performance benefits of static). This tradeoff has frustrated teams running large content sites for years. Vinext’s TPR takes a different approach. Instead of asking you to enumerate which pages to pre-render, it queries Cloudflare’s own zone analytics to figure out which pages are actually receiving traffic. It then pre-renders only the pages driving 90% of real traffic, caches those to KV, and falls back to on-demand SSR for everything else. In the example Cloudflare used: a site with 100,000 product pages might only need 50 to 200 of them pre-rendered based on actual traffic patterns. The other 99,800 pages get served dynamically. Build times collapse. Cache hit rates stay high. The pages that matter to actual visitors are always fast. This is a genuinely clever use of Cloudflare’s infrastructure advantage. They have the analytics data, they have KV for edge caching, and they have Workers for on-demand rendering. The TPR feature threads all three together into something that the Next.js team, running on Vercel’s infrastructure, cannot easily replicate. How Vinext Compares to OpenNext Anyone paying attention to the Next.js ecosystem knows about OpenNext, the open-source project that adapts Next.js output for deployment on non-Vercel platforms. OpenNext sits between Next.js and the target platform: it takes what Next.js builds and transforms it into something that can run on AWS Lambda, Cloudflare Workers, or other runtimes. Cloudflare has contributed to OpenNext. It is not an adversarial relationship. But the Cloudflare team is honest about OpenNext’s structural limitation: it builds on top of Next.js internals, which means every time Vercel changes how Next.js produces output, OpenNext has to catch up. Version fragility is a constant maintenance burden. Features that Vercel builds with Vercel’s infrastructure in mind are sometimes difficult or impossible to adapt cleanly. Vinext sidesteps this entirely by reimplementing the API surface rather than adapting the output. It does not care what Next.js produces internally because it does not touch Next.js at all. The public API is the contract: file-system routing conventions, the module imports, the configuration schema. Those change rarely and when they do, it is a documented, versioned change. Vinext tracks that contract, not the internals. This makes the long-term maintenance story different. Not necessarily easier, because you are now owning a framework implementation rather than an adapter. But more stable, because you are not chasing a moving internal target. Cloudflare’s Motivation Here Is Not Subtle It is worth being direct about what Cloudflare is doing with vinext from a business perspective, because understanding the incentive helps you evaluate the project honestly. Cloudflare makes money when developers deploy workloads to Cloudflare Workers. Next.js is the dominant React framework. Most Next.js applications are deployed on Vercel, where Cloudflare cannot monetize them. If Cloudflare can offer a Next.js-compatible framework that is faster, cheaper to run, and deploys to Workers with one command, they have a compelling pitch to pull workloads off Vercel and onto their platform. This is not cynical. It is a normal competitive dynamic in cloud infrastructure, and it benefits developers. Competition between Cloudflare and Vercel pushes both platforms to improve their offerings, reduce prices, and invest in developer experience. OpenNext already created pressure on Vercel to take edge deployment seriously. Vinext escalates that pressure. The more interesting implication is that Cloudflare built a credible competitor to a major Vercel product for $1,100 in API costs. That is a signal to Vercel, and to every other infrastructure company, that the moat around “we built the framework first” is weaker than it used to be. What the Community Is Saying The reaction from the broader JavaScript community has been a mix of genuine excitement and measured skepticism, which is probably the right response. On the excitement side: build times and bundle sizes are real pain points for teams running large Next.js applications. The possibility of a drop-in replacement that fixes both, while also making Workers deployment straightforward, is genuinely appealing. The traffic-aware pre-rendering idea has gotten particularly positive attention from teams running content-heavy sites. On the skepticism side: GitHub issue #21 on the vinext repo asks directly how serious Cloudflare is about maintaining this long-term. Will they fund three or more months of development? Will they staff a team to handle the inevitable edge cases that real production traffic surfaces? These are fair questions. The project is explicitly labeled experimental. CIO.gov is brave for running it in production, but one government website is not evidence of production readiness at scale. There is also the broader question about AI-generated codebases. Some research suggests AI-written code introduces more bugs than human-written equivalents. Vinext has a solid test suite that catches a lot, but passing tests does not guarantee correct behavior in every edge case that production traffic will find. The “it works well enough for demos and exploration” framing in the official blog post is honest, but it should set expectations for teams considering adoption. What This Actually Changes Here is the part that matters more than vinext itself. One engineer, in one week, rebuilt a major framework. The cost was $1,100. This is not a one-time stunt. The same methodology works for any well-tested, publicly documented software with a stable API contract. As the Cloudflare post itself observed: “most abstractions in software exist because humans need help” managing complexity. AI systems do not have the same limitations. They can hold entire codebases in context. They can grind through thousands of test cases without losing focus. The intermediate layers that frameworks used to provide partly as organizational tools for human teams become less necessary. If reimplementing a framework costs $1,100 and takes a week, the competitive landscape for developer tools looks very different than it did five years ago. The moat used to be the implementation complexity itself: building a framework well took months of skilled engineering, and that investment created barriers to entry. Now the moat has to come from somewhere else: community, ecosystem, trust, maintenance quality, integrations, support. Vercel’s moat is not “we built Next.js.” Their moat is the ecosystem around Next.js: the integrations, the documentation, the community expertise, the years of production battle-testing, the enterprise relationships, and the tight integration between framework and platform. Those things are hard to replicate in a week regardless of how much you spend on API tokens. But vinext proves that the framework itself is no longer the hard part. And that changes what it means to compete in this space. Getting Started with Vinext If you want to try vinext today, there are three migration paths depending on your preference. The recommended path is using the agent skill approach: npx skills add cloudflare/vinext. This uses an AI-assisted migration agent to walk through your codebase and handle compatibility. npx skills add cloudflare/vinext The CLI approach is npx vinext init, which automates the migration for most standard Next.js setups. npx vinext init If you prefer to do it manually: npm install vinext, then update your package.json scripts to replace next dev with vinext dev, next build with vinext build, and so on. Migrations are non-destructive, meaning your existing Next.js setup continues to work alongside vinext. You can experiment without committing. npm install vinext next dev vinext dev next build vinext build Deployment to Workers is vinext deploy. The command builds the app, generates the Worker configuration automatically, and publishes. That includes App Router and Pages Router support, client hydration, and ISR via KV. vinext deploy Final Thoughts Vinext is worth paying attention to for two distinct reasons. The first is practical. If you are running a Next.js application and want faster builds, smaller bundles, and an easier path to deploying on Cloudflare Workers, vinext is already a reasonable thing to experiment with. It is not production-ready for high-stakes applications yet, but for side projects, internal tools, or low-stakes services, it is compelling right now. The second reason is conceptual. Cloudflare has demonstrated that a well-tested, publicly documented framework can be reimplemented in a week by a single person with an AI model and a small budget. That changes the economics of framework development. It changes what it means to have a technical moat. And it raises real questions about how the open-source ecosystem evolves when “building the alternative” gets this cheap. The JavaScript ecosystem has always moved fast. Vinext is a signal that it is about to move even faster.

This story contains new, firsthand information uncovered by the writer.

Render

I Read X's Open-Source Algorithm: Here's What Actually Matters in 2026

Cloudflare Vinext: The AI-Built Next.js Replacement That Changes Everything

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Building the "Spotify Wrapped" of Product Hunt: A 48-Hour Technical Sprint to Map the Maker Economy

I Built 10 Pokemon Agents That Learn From Each Other Using Kafka and Flink

I Turned My Claude Chat History Into a Pixel Art City (and Built the Whole Thing With Claude Code)

Why Right Now Is the Perfect Time to Build Things (And How AI Changed Everything)

Building the "Spotify Wrapped" of Product Hunt: A 48-Hour Technical Sprint to Map the Maker Economy

I Built 10 Pokemon Agents That Learn From Each Other Using Kafka and Flink

I Turned My Claude Chat History Into a Pixel Art City (and Built the Whole Thing With Claude Code)

Why Right Now Is the Perfect Time to Build Things (And How AI Changed Everything)

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps