Cloudflare's Vinext 1.0 reimplements Next.js on Vite, and its own README still calls OpenNext the safer choice. This covers what Vinext runs, what it leaves out, why npm audit stops describing your exposure after a move, and who should switch.
What Vinext Is
Cloudflare released Vinext 1.0 on September 28, 2026, during its Birthday Week. It began in February as a week-long experiment in rebuilding Next.js with AI, and it is now an MIT-licensed Vite plugin that reimplements the public Next.js API: routing, server rendering, the next/* imports and the CLI.
That design choice matters for everything below. Vinext is not a wrapper around Next.js and not a fork. It does not run next build or use its output. Your app/ and pages/ directories stay where they are, but the code that routes, renders and caches them is Vinext's own, written from scratch and running on Vite 8. It targets Next.js 16 only.
Cloudflare Workers is the main deployment target, with platform bindings and an optional cache-warming step that renders pages on a new version before that version takes any traffic. Vinext can also build a standalone Node.js server, and it reaches Vercel, Netlify, AWS and Deno Deploy through the Nitro Vite plugin.
How Complete It Is
Cloudflare reports that more than 99 percent of its compatibility tests pass for the features customers asked for most, not counting Cache Components, and that it runs the Next.js end-to-end test suite against Vinext every night. The README puts coverage at about 94 percent of the Next.js 16 API surface, with full or partial support.
The gaps it lists are specific:
- Cache Components and Partial Prerendering. The
"use cache"directive is partly implemented, and fullcacheComponentsbehavior is not there yet. - Build-time image and font optimization. Images can be optimized at request time on Cloudflare, Google Fonts load from the CDN, and local font CSS is injected at runtime instead of being extracted during the build.
- Native modules in App Router development. Packages such as
sharp,satori,resvgandlightningcsscan fail in Vite's development environment, although production builds handle more of them. - Where routes run.
preferredRegionis ignored, andruntimedoes not choose where a route runs.
Some things are left out on purpose. Turbopack and webpack configuration do not apply, so custom loaders have to become Vite plugins, next/jest gives way to Vitest, and behavior the Next.js documentation does not describe is not reproduced. Vite 8 also brings a newer default browser target and stricter handling of CommonJS default imports, which can surface in older dependencies.
What Vinext's Own Documentation Says
The launch post says customers already run Vinext in production for high-traffic, dynamic applications. The README on GitHub is more careful. It describes the project as under active development and not yet a drop-in replacement for every application, and its answer to whether you can use it in production is yes, with caution.
It is candid about the alternatives too. For running Next.js outside Vercel, it names OpenNext, which adapts the output of a normal next build, as the more mature and safer choice. And for anyone happy with the Next.js toolchain, it calls plain self-hosting on Node.js or Docker the simplest path. Coming from the people who build Vinext, that is the right frame for the decision.
The Security Question to Ask First
A Next.js security advisory describes code in the next package. A Vinext application renders through different code, so whether a Next.js advisory applies to it is a question only Vinext can answer. Vinext takes vulnerability reports through Cloudflare's disclosure program, and on September 29 its repository listed no published security advisories.
Dependency scanners make this easy to miss. vinext init does not remove Next.js from your dependencies, so npm audit keeps reporting advisories for a next package your Vinext build no longer uses to serve pages. Vinext does not need that package to run, apart from a few features such as styled-jsx that use Next.js internals, and once it is gone npm audit says nothing about Next.js at all. Either way the scanner has stopped describing your real exposure. We saw a quieter version of the same problem this month, when a critical next/og advisory was still invisible to npm audit two days after its release.
The calendar makes the point for us. Next.js has scheduled a security release for September 30 that fixes nine vulnerabilities, one of them critical, in 16.3.7 and 15.5.27. On Next.js the answer will be to upgrade. On Vinext it depends on whether Vinext reproduced the affected behavior, and you will need Vinext to tell you.
Who Should Move
It is a reasonable fit when the application will run on Cloudflare Workers, where Vinext's integration is deepest, when build and development-server times are a real cost, and when the app uses neither Cache Components nor custom webpack configuration.
It is a poor fit for now when the app relies on "use cache" or Partial Prerendering, when it has webpack loaders or plugins that would need rewriting, or when nobody on the team will track a second framework's releases and advisories.
If you self-host Next.js on Kubernetes or Docker, the case is weaker still. next start and the standalone output already run anywhere Node.js runs, so moving buys you Vite's toolchain rather than portability you lacked. If you do move, note that Vinext's standalone server reads its bind address from HOST, not from HOSTNAME as Next.js does. It defaults to 0.0.0.0 and port 3000, so a manifest that sets only HOSTNAME no longer controls where the server listens.
How to Try It Without Betting the App
Start with the scanner, on a branch:
npx vinext check
npx vinext init --platform=node
vinext init leaves your Next.js setup working. It adds dev:vinext, build:vinext and start:vinext scripts next to the existing ones and does not touch next.config, tsconfig.json or your source files. It does add "type": "module" to package.json and renames CommonJS config files such as postcss.config.js, so review that part of the diff before merging anything.
Then run your own end-to-end tests against both builds and compare what each one returns, including redirects, middleware, cache headers and how ISR pages revalidate. Caching deserves the most attention, since unsafe caching behavior is one of the things the Vinext team says its daily review of upstream changes keeps catching.
If you run Next.js on your own infrastructure, our production guide to Next.js 16 on Kubernetes covers the setup Vinext would replace, and Kubernetes for Next.js is how we run it for teams who would rather not weigh these trade-offs alone.
Sources
Or read how we handle it in Kubernetes for Next.js.
Related Articles
When Your Next.js MVP Stops Growing - Product, Marketing, or Infra?
Your Next.js MVP plateaued and nobody agrees why. Here is how to tell whether the bottleneck is product, marketing, or the infrastructure that is slowing you down.
Next.jsMeasuring Real-World Next.js Performance Beyond Lighthouse
Lighthouse scores and lab metrics tell you what is theoretically possible. Real-user monitoring tells you what is actually happening. This article covers the tools, metrics, and instrumentation setup that give you accurate Next.js performance data in production.
Next.jsThe Real Cost of a Next.js Outage - Beyond the Downtime Bill
A Next.js outage costs far more than lost sales for the hour it happens. Here is the full picture - trust, SEO, support load, churn - and how to stop paying it.