Next.js applications, powered by Vite: introducing Vinext 1.0

From one-week experiment to 1.0

Vinext began in February as a week-long AI-driven experiment: how far could one engineer and a large budget of tokens get toward replicating the Next.js framework on top of Vite? Seven months later it is a framework running production traffic, and it has now reached version 1.0. The goal is portability — take a Next.js app, Pages Router or App Router, and deploy it to any web platform, including the Cloudflare Workers free plan, Netlify, or AWS Lambda.

Getting there meant closing gaps on both routers rather than only the newest one. Customers with large Pages Router applications face complex migrations, and the project did not want to serve only teams on current App Router features. Compatibility for the most important customer-requested features now exceeds 99% in the test suite.

The community drove much of that progress by throwing Vinext at a wide range of applications as soon as it launched, surfacing problems that test coverage had missed. Matching Next.js is not a matter of exposing functions with the same names: a replacement for import { revalidatePath } is easy to write, but making it correctly affect the rendered page, the cache entry, and later requests is the hard part. Tracing requests end to end to replicate the behavior of the Next.js machine proved far more difficult than replicating its API.

Regression protection followed. Vinext now carries thousands of focused tests covering core framework behavior across both routers, the development and production servers, and the Node.js and Cloudflare Workers deployment targets. The Next.js end-to-end suite also runs against Vinext nightly, giving a moving view of compatibility so that upstream changes surface regressions immediately. The team additionally works directly with large production customers.

What Vinext 1.0 covers

Customer feedback showed that a subset of Next.js features carries most applications, so 1.0 concentrates support there:

• Routing and rendering models: App Router, Pages Router, and hybrid applications, with React Server Components, Server Actions, API routes, route handlers, middleware, and client-side navigation.
• Page lifecycle: server rendering, pre-rendering at build time, static asset export, and page-level Incremental Static Regeneration, with background and on-demand revalidation working against any output.
• Caching: a shared set of caching functions across both routers and the supported runtimes, plus support for Cloudflare's Workers Cache.
• Observability: Next.js-compatible tracing on both routers, so existing OpenTelemetry and Sentry setups keep working; on Cloudflare Workers, traces integrate with native Workers Observability.
• Ecosystem: the public next/* surface and common patterns for authentication, MDX, image optimization, fonts, metadata, and environment variables.
• Workers runtime: server code can run in the workerd runtime in development and production with direct access to bindings such as image optimization and Hyperdrive.

Migration ships with the framework: two commands verify that an existing Next.js install and any local modifications are compatible and write the Vite and deployment configuration, leaving the prior project structure intact.

One deliberate limit: Next.js 16 positions Cache Components as central to the framework's future, but most teams surveyed were not using them and did not treat support as a prerequisite for moving. Vinext therefore has limited support for the "use cache" directive that drives Cache Components; compatibility will improve, but core priorities come first.

Pre-rendering, warmed from the edge

The first Vinext release supported ISR only after an initial request, with no rendering during the build. Applications use generateStaticParams() and getStaticPaths() to name the pages that should render at build time, and they expect page-level ISR to connect those responses to background and on-demand revalidation. Version 1.0 supports that lifecycle on both routers: it prerenders App Router and Pages Router routes during the build, serves them through page-level ISR, and invalidates them by path or tag. It also supports output: "export" for fully static sites.

That raised a question: why render during the build at all? A site with tens or hundreds of thousands of candidate URLs can spend hours rendering pages that see little traffic, and the build cannot know which routes matter, so sequential builds grind through thousands of pages long after the important ones are done.

Cache warming moves that prerendering off the build machine and onto Cloudflare's network. Developers keep using Next.js primitives to identify pages, and Vinext can additionally flag high-traffic pages for the list. The work runs in the background before deployment goes live.

Mechanically, the deployment uploads a new Worker version, routes 0% of production traffic to it, and then requests pages from that version specifically, so the rendering pipeline runs before any real user touches the deployment. Once caches are populated, promotion is safe.

For the Pages Router specifically, Pages Router apps made up about 25% of sites at launch and now account for around 60% of those using Pages Router.

Alongside prerendering, Vinext 1.0 addresses a class of Pages Router migration issues: rewriting req.url no longer desynchronizes routing decisions, unsafe getStaticPaths fallback behavior is fixed, and import resolution has been reworked to respect package exports and condition map semantics — the standard Node.js resolution order and nesting rules, rather than a static directory convention.

npm create vinext-app@latest my-app

Or migrate an existing application:

npx vinext check && npx vinext init

Then deploy to Cloudflare Workers with cache warming:

npx @vinext/cloudflare deploy --warm-cache

Keeping pace upstream

An ongoing project needs an ongoing process. Next.js canary receives commits daily; each morning an agent inspects the changes, pulls diffs, and opens tracking issues for anything that could affect Vinext, while nightly runs regenerate the compatibility matrix against the Next.js test suite.

When a test or issue exposes a gap, agents can locate the change in both codebases, build a reproduction, port the relevant tests, and propose a fix. This has been turning up missing cases, unsafe caching behavior, and divergence between development and production servers, and narrowing the stream of upstream activity into a small set of changes that maintainers examine — chiefly those needing judgment about how a process maps from Next.js onto Vite.

Documentation, examples, and the current compatibility matrix are at vinext.dev; the source and issue tracker are at github.com/cloudflare/vinext. Application reproductions and pull requests are welcome. To check and convert an existing project, run npx vinext check and npx vinext init.