Vinext 1.0: running Next.js on Vite, deploy anywhere

Cloudflare's Vinext 1.0 runs Next.js on Vite and deploys the build to Cloudflare Workers, a standalone Node server, or through Nitro to Vercel, Netlify, AWS, Deno Deploy and Azure. Cloudflare puts compatibility above 99%. Vinext's own dashboard puts it at 96.0%. Both figures are honest, and the gap between them is the entire decision.

What follows is which of those numbers applies to your application, what Vinext still leaves out, and why we are telling most clients already on Vercel to stay where they are for now.

What running Next.js on Vite actually changes

Vinext replaces the toolchain, not the framework. Your app/ or pages/ routes, your components, your public assets and most next/* imports stay exactly where they are, while Vite 8 takes over development and production builds in place of the Next.js compiler.

App Router, Pages Router, React Server Components, Server Actions, middleware, route handlers, static generation and ISR are all implemented. Cloudflare describes 1.0 as production-ready and says customers already run it for high-traffic, dynamic applications.

Adoption is deliberately reversible, which is the most underrated thing about the release. vinext init is non-destructive: it leaves your existing Next.js scripts in place and adds parallel *:vinext scripts, so next dev and the Vite server run side by side while you compare routes. A vinext check scanner reports unsupported configuration, imports and project patterns before you commit to anything.

The 99% claim, and the two numbers underneath it

Cloudflare's post says test compatibility now surpasses 99%, excluding cache components. The live compatibility dashboard is more precise. Its run of 29 September 2026, against Next.js v16.2.6 across 799 test files, reports three separate figures.

Figure	Value	What it measures
Supported pass rate	99.7%	Tests passing within the surface Vinext claims to support
Supported surface coverage	93.9%	How much of the Next.js test surface that claim covers
Overall pass rate	96.0%	What you get when nothing is excluded

By router, the same dashboard reports App Router at 99.8% supported and 94.7% overall, Pages Router at 99.7% and 97.9%, and mixed applications at 100% and 96.8%. Pages Router, the older model, is the better supported one.

None of this is a criticism of Cloudflare's figure. It is the supported-surface number and they label it as such. It is a criticism of how that figure will be repeated in your planning meeting, stripped of the qualifier, as though 99% of your application is covered.

Which Next.js versions Vinext supports

The launch post does not say. The documentation does: Vinext targets the stable Next.js 16 API surface, explicitly not undocumented Vercel behaviour or every experimental feature. The compatibility suite runs against Next.js v16.2.6, and installation requires Node.js 22 or newer.

If you are on Next.js 14 or 15, Vinext is not a migration you can evaluate this quarter. It is a framework upgrade first and a toolchain change second, and those are two separate risk budgets that should not be spent in the same sprint. Staying current on the framework matters more anyway: Next.js 16.3.6 fixed a critical next/og RCE, and being a version behind on Next.js is a worse position than being on its default build tooling.

What is still missing: Cache Components, PPR and use cache

Cache Components and Partial Prerendering remain incomplete, per the differences page, and build-time image and font optimisation do not yet reproduce the full Next.js pipeline. Cloudflare frames the limited use cache support as a prioritisation call: most teams it surveyed were not asking for the directive.

That framing is reasonable today and uncomfortable over two years. Cache Components is where the App Router caching model is heading. Adopting a toolchain that is openly behind on the part of the framework most likely to change is a bet that you will not need it — a fine bet, provided you can name the date you would revisit it.

Two smaller gaps matter in practice. Webpack plugins do not carry over, so any build step that reaches into the Next.js compiler needs a Vite equivalent. And route config values such as runtime and preferredRegion no longer choose where code runs, because placement now belongs to the deployment adapter you picked.

The caching divergence your code review will not catch

This is the part worth reading twice. Vinext decides at request time whether a render is dynamic, rather than classifying the route at build time. A client-side navigation requests only the RSC payload, and that render does not run client components — so it cannot see a "use client" page reading searchParams, or a useSearchParams() call with no <Suspense> boundary above it.

On an otherwise static route, Vinext can then store that RSC payload, where Next.js would treat the route as dynamic or fail the build outright. The payload does not carry the query string, but server-rendered data on the route can stay stale through client navigations until something revalidates it.

The remedies are documented: export dynamic = "force-dynamic" from the route's layout.tsx, or read searchParams in a server component and pass the values down, and wrap useSearchParams() in a <Suspense> boundary as Next.js already requires. The difficulty is that nothing fails. A green test suite and a page quietly serving a stale view look identical from the outside, which is why a migration audit has to target caching behaviour specifically rather than trusting the build.

Who should move, and who should stay put

Your situation	Verdict	Why
On Vercel, Next.js 16, no portability requirement	Stay	You pay a real migration and caching-audit cost for an option you are not exercising
Already on Cloudflare Workers, or heading there	Move	Workers is the primary native target, with direct bindings, caching and one-command deploys
Portability is contractual — residency, a client's cloud, an exit clause	Evaluate now	The check scanner and parallel scripts let you price the move without committing to it
On Next.js 14 or 15	Not yet	Vinext targets the stable Next.js 16 API surface
Dependent on Cache Components or PPR	Not yet	Both are explicitly incomplete

One caveat on the second row: moving onto Workers brings its own set of production issues worth learning early, and they are not the failures a Node host teaches you. Budget for that learning rather than assuming the adapter hides it.

For most of the web application work we do, the honest position at the end of September 2026 is that portability is an option with a price, not a free upgrade. The teams who should move already know why — an existing Workers footprint, a residency rule, a customer contract that names the host. If your reason is that you might want to leave Vercel one day, buy the cheaper version of that option instead: keep host-specific code behind a thin boundary, know what your deployment retention actually is before you need a rollback, and run the compatibility scanner once a quarter so the cost of leaving is a number you already have.