Meet Vinext, the Next.js Alternative Built on Vite

Vinext is an open-source Vite plugin from Cloudflare that reimplements the Next.js API, so an existing App Router or Pages Router codebase can be built and served by Vite instead of the Next.js toolchain. Cloudflare announced version 1.0 on 28 September 2026.

Many teams like Next.js but not the hosting it pulls them toward, and porting a large app to a different framework just to change hosts is hard to justify. Vinext offers another route. This article covers what Vinext supports, where it deploys, the exact commands to test it on your own app, and the gaps Cloudflare documents itself.

What Is Vinext and How Does It Differ from Other Next.js Alternatives?

Vinext is Next.js reimplemented on top of Vite by Cloudflare. Vinext started in February 2026 as a week-long, AI-driven experiment and reached 1.0 seven months later. The README is explicit that it is not a fork: the core was written from scratch to match the public Next.js API.

Vinext is therefore a different kind of option from the usual Next.js alternatives. Moving to React Router, Astro or SvelteKit means rewriting routes, data loading and components. Vinext leaves that code alone and changes only what builds and serves it. Your project still looks like a Next.js project. Vite does the work underneath.

What Does Vinext Support?

Vinext covers both routers and the main server features of modern Next.js. The 1.0 announcement and the README list support for:

• App Router, Pages Router, and hybrid apps that use both
• React Server Components and Server Actions
• Middleware, API routes and route handlers
• ISR revalidation
• Build-time prerendering through generateStaticParams() and getStaticPaths()
• Static export with output: "export"

The README targets Next.js 16.x and lists vite ^8.0.0 as a peer dependency.

Cloudflare reports Vinext’s Next.js compatibility in two different ways, and the two numbers do not measure the same thing. The 1.0 post reports more than 99% test compatibility, but only for the features customers asked for most, and with Cache Components left out. The README states that “~94% of the Next.js 16 API surface has full or partial support.” Both figures come from Cloudflare. Neither replaces running your own app.

Where Can Vinext Deploy?

Vinext deploys natively to Cloudflare Workers, and the 1.0 post says it runs on the Workers free plan. The same post names Netlify and AWS Lambda as deploy targets. The README explains the mechanism: Workers is handled directly by @vinext/cloudflare, while Vercel, Netlify, AWS and Deno Deploy are reached by adding the Nitro Vite plugin. No native Netlify or Lambda adapter is involved.

A minimal config adds a single plugin:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";

export default defineConfig({
  plugins: [vinext()],
});

To target a non-Cloudflare host, install nitro and add its plugin:

// vite.config.ts
import { defineConfig } from "vite";
import vinext from "vinext";
import { nitro } from "nitro/vite";

export default defineConfig({
  plugins: [vinext(), nitro()],
});

npm install nitro
NITRO_PRESET=netlify npx vite build

How to Try Vinext on an Existing Next.js App

Testing Vinext on an existing app takes two commands, and neither one stops your current Next.js workflow from working. Run them on a branch:

npx vinext check
npx vinext init

vinext check scans the project and reports known incompatibilities before you change anything. vinext init is non-destructive, so next dev keeps working next to the new setup. It asks for a deployment target and defaults to Cloudflare. Since the 1.0 release, Cloudflare setups use the cf CLI with a typed cloudflare.config.ts by default. To keep the older Wrangler setup instead, pass --legacy-wrangler-cloudflare-init.

Starting a New Vinext App

For a greenfield project, scaffold the app, run it, build it, then deploy:

npm create vinext-app@latest my-app
npx vite dev
npx vite build
npx @vinext/cloudflare deploy

The 1.0 release adds a --warm-cache flag to the deploy command. It uploads the new version with 0% of traffic, requests the cacheable pages through it to fill the caches, and only then promotes it.

What Are Vinext’s Limitations and Known Gaps?

The README’s Known gaps section lists four areas where Vinext does not yet match Next.js: Cache Components, build-time image and font optimization, native modules in App Router development, and some platform-specific route config. Cloudflare says it is still working on all four, so none of them is a permanent limit.

• Cache Components and PPR: "use cache" works in part, but the full cacheComponents model is not finished. Cache profiles, tags, partial shells, resuming, prefetching and some dev and build caching can still behave differently from Next.js.
• Images and fonts: On Cloudflare, images can be optimized when they are requested. Vinext does not yet copy the full image pipeline that Next.js runs at build time, and fonts are loaded at runtime rather than processed during the build.
• Native modules: Packages such as sharp, resvg, satori, lightningcss and @napi-rs/canvas may break in Vite’s RSC dev environment. Production builds handle more of them than dev mode does.
• Route config: Vinext ignores the runtime and preferredRegion route settings.

The README also says Vinext is not yet a drop-in replacement for every application.

Who Should Adopt Vinext and Who Should Wait

Vinext suits teams that want to keep writing Next.js without being tied to one host. The sources do not fully agree on production readiness. Cloudflare’s announcement calls 1.0 production-ready, while the README answers “You can, with caution,” and points out that Vinext still has compatibility gaps and has not yet been proven on every kind of production Next.js app.

• Adopt if your app uses both routers, RSC, Server Actions and ISR, and you want to deploy to Workers or through Nitro.
• Wait if you rely heavily on Cache Components, PPR or "use cache" semantics such as tags and profiles.
• Consider OpenNext if you need proven production maturity. Vinext’s README explains that OpenNext works from the output of next build, so it covers more of the Next.js API, and it has a much longer track record.

Conclusion

With Vinext you can leave Vercel without rewriting your Next.js app. You do have to accept documented gaps, mainly around Cache Components. To see whether it fits, create a branch, run npx vinext check, review what it flags against the known gaps, then run npx vinext init and compare behaviour with next dev. If you also want to move the rest of your toolchain, read Getting Started with Vite+ (the README lists vp exec vinext-cloudflare deploy for Vite+ projects). For the cloudflare.config.ts workflow that init sets up, see A Practical Guide to Cloudflare’s New cf CLI.

FAQs

Can I keep my custom webpack config or next/jest setup when moving to Vinext?

No. Vinext runs on Vite, so Turbopack and webpack configuration do not apply, and custom webpack loaders or plugins must be replaced with Vite plugins. The Vinext README lists next/jest as unsupported and recommends Vitest instead. AMP is also unsupported, with useAmp() always returning false, and the legacy next export command is replaced by setting output: 'export' in the Next.js config.

What versions of React and Vite does Vinext require?

Vinext declares peer dependencies on react ^19.3.1, react-dom ^19.3.1, react-server-dom-webpack ^19.3.1 and vite ^8.0.0, and targets Next.js 16.x. App Router projects must also have @vitejs/plugin-rsc installed. Vinext registers that plugin automatically when it detects an app directory, so adding your own rsc() call fails the build with a duplicate plugin error unless you pass rsc: false to vinext().

What does vinext init change in an existing Next.js project?

vinext init adds 'type': 'module' to package.json and renames CommonJS config files, such as postcss.config.js to postcss.config.cjs, to avoid ESM conflicts. It also installs the Vite and Vinext packages and adds dev:vinext, build:vinext and start:vinext scripts alongside the existing Next.js scripts. Because the original scripts stay in place, next dev and the Vinext dev server can run from the same codebase for side-by-side comparison.

Does revalidateTag serve stale pages while they regenerate in Vinext on Cloudflare?

Yes, from the 1.1 releases in October 2026, when you pass a cache profile such as revalidateTag(tag, 'max'). Earlier releases purged matching pages from Workers Cache, so the next request waited for a full render. Now Workers Cache and the Response Store mark those entries stale and keep serving the cached version while it regenerates in the background, as Next.js does. Calling revalidateTag with only a tag, or with expire: 0, still expires entries right away. Stale 'use cache' entries are also served while they regenerate.