Your Next.js corporate site or web app, built by a web agency, runs on Vercel. Your other sites and DNS are consolidated on Cloudflare, so could hosting move there too? If you are thinking along those lines, there is now another candidate: "vinext", developed by Cloudflare. According to npm records, 1.0.0 was published on September 28, 2026, and 1.0.1 on October 1.
On the other hand, vinext's README states at the very top that it is "not yet a replacement for every application or production workload" and names OpenNext as a more mature option. Rather than deciding to switch based on the 1.0 version number alone, we organize the material for the decision from the README, the changelog, and the results of running it on a Next.js 16 test app.
vinext is "the Next.js API rebuilt on Vite"
According to the README, vinext does not use the output of next build; instead, it reimplements the Next.js APIs (routing, server rendering, next/* modules and so on) on top of the Vite build tool. It says it supports the App Router and Pages Router, React Server Components, Server Actions, middleware, route handlers, ISR and static export. It targets Next.js 16.x and does not handle APIs that were deprecated in older versions.
The main deployment target is Cloudflare Workers. For other targets (Vercel, Netlify, AWS Amplify, Deno Deploy, Node.js servers and so on), you deploy by adding a Vite plugin called Nitro. It is not a fork of Next.js.
According to npm's publication records, it reached 1.0.0 after 14 beta releases, starting with beta.0 on July 4, 2026. The 1.0.0 changelog lists changes such as caching only the pages that Next.js treats as static, having vinext check report which next.config entries are ignored or applied, and switching the initial Cloudflare setup to the new "cf" CLI.
What the README lists as "not there yet"
The README's "Known gaps" section lists the following items as work in progress.
- Cache Components and Partial Prerendering:
"use cache"is only partially implemented, and the behavior ofcacheComponentsmay not match Next.js - Build-time image and font optimization: On Cloudflare, images can be optimized at request time, but Next.js's build-time image processing is not reproduced
- Native modules during App Router development:
sharp,resvg,satoriand others may fail on the development server - Settings tied to the deployment target:
preferredRegionis ignored, andruntimedoes not choose where code runs
Separately, the README explicitly states that Vercel-specific features (@vercel/og for the edge runtime, Vercel Analytics, Vercel KV/Blob/Postgres) will not be supported going forward. On production use, its "Can I use this in production?" entry answers "You can, with caution."
Four ways to move off Vercel
The descriptions of the options are based on vinext's README. We did not open the official OpenNext or Next.js documentation for this article, so please check the details of each in their official materials.
| Option | How it works | Positioning in vinext's README |
|---|---|---|
| Stay on Vercel | As is | Not mentioned (used in this article as the baseline for comparison) |
| Self-hosting Next.js | Node.js server, Docker, static export | "The easiest option if you want to keep Next.js and run it somewhere else" |
| OpenNext | Converts next build output for each platform | "More mature and covers more of the API", "a safe, proven choice" |
| vinext | Reimplements the Next.js API on Vite | Faster builds and smaller output, but does not cover the edges of Next.js's features |
In the editorial team's view, choosing vinext makes sense when you have a reason to change the toolchain itself, such as wanting to move to the Vite tool ecosystem or to use Cloudflare Workers bindings directly. We also covered developments in Vite-based development environments in our Vite+ article.
Running it on a Next.js 16 test app
On October 2, 2026, in the editorial team's test environment (Linux, Node v22.22.0, npm 10.9.4), we took the App Router template generated by create-next-app (Next.js 16.3.8, using next/image and next/font/google), added one route handler that returns JSON, and tested it. vinext was version 1.0.1.
check rewrites nothing
npx vinext@1.0.1 check finished in about 13 seconds without changing any files (no git diff). The result was "100% compatible (6 supported, 0 partial, 0 issues)".
We then added two of the items the README lists as gaps and ran it again: cacheComponents: true in next.config.ts, and preferredRegion = "hnd1" and "use cache" on a new page. The result dropped to "94% compatible" and cacheComponents — experimental support; behavior is incomplete was displayed. However, nothing was displayed for preferredRegion. Passing check is no substitute for reading the README's Known gaps.
init stopped on the React version
The next step, vinext init --platform=node, stopped while adding dependencies. The npm error was ERESOLVE could not resolve: the react-server-dom-webpack@19.3.0 it tried to add requires React 19.3.0 or later, while the template's React was 19.2.8. By the time it stopped, it had already added scripts and "type": "module" to package.json, created vite.config.ts, and appended to .gitignore. Changes remain even if it stops partway, so try it on a git branch.
After upgrading React and React DOM to 19.3.0 and trying again, init completed.
As the README describes, next.config.ts, tsconfig.json and the contents of app/ were unchanged, and existing Next.js scripts such as npm run dev also remained as they were. The three scripts added were dev:vinext, build:vinext and start:vinext. It also detected CSS Modules and added vite-css-modules.
Building and starting
npm run build:vinext (Vite 8.3.2) completed, and the server started with npm run start:vinext returned HTTP 200 for both the page and the route handler. However, the route list at the end of the build showed / as "? Unknown", with a note that "use of dynamic APIs such as headers() or cookies() cannot be detected at build time". When the same app is built with next build, / is "○ (Static)". The benchmarks section of the README also explains that Next.js generates pages statically at build time, whereas vinext renders on the server for each request by default.
For Cloudflare, decide on the caching approach first
init with --platform=cloudflare stopped and asked us to choose caching and image optimization options. It told us to specify the CDN cache (response-store, workers-cache, static-assets, data-cache), the data cache (kv or none) and image optimization (cloudflare-images or none), and then run it again. When we reran it with static-assets, no data cache and no image optimization, cloudflare.config.ts was created, and / was prerendered at build time and shown as "○ Static". In the local preview, the page and route handler also returned 200.
The added dependencies included 2.0.0 beta versions of cf@1.0.0-beta.10 and @cloudflare/vite-plugin. Even though vinext itself is at 1.0, the tools used to deploy to Cloudflare are still in beta. We cover cf in our article on Cloudflare's cf beta and Wrangler. We did not try an actual deployment to Cloudflare.
What to check before deciding to switch (editorial proposal)
- Next.js version: vinext targets 16.x. For sites on 15 or earlier, first check whether you need to update Next.js itself
- Checking the features you use against the Known gaps: Check whether you use
"use cache", build-time optimization ofnext/image, OG image generation withsharporsatori, or Vercel-specific services. OG image generation is also an area we touched on in our article on the September Next.js vulnerabilities - Run
vinext checkandvinext initon a branch: Review the diff in git and share what was added with your web agency - Whether pages are static or dynamic: In the build's route list, check whether the pages you want to serve statically are marked "Static". For Cloudflare, your choice of caching approach affects this
- Who will maintain it: vinext is a separate implementation from Next.js. Confirm whether your web agency can take on investigation and workarounds when bugs occur
Which to choose
This is the editorial team's summary based on the materials and testing covered so far.
| Status | Editorial proposal |
|---|---|
| No major complaints about Vercel's cost or operations | Stay. Don't make leaving Vercel a goal in itself |
| Want to keep Next.js and run it on self-managed servers | Consider self-hosting Next.js first |
| Want to move to Cloudflare without losing features | Consider OpenNext first |
| Want to make active use of Cloudflare Workers features or Vite; on Next.js 16 and not affected by the Known gaps | Try vinext on a branch, and decide after checking how static pages are handled and the dependency versions |
Pitfall
- Treating check's "100%" as a certificate of compatibility. Even settings the README says are ignored, such as
preferredRegion, were not flagged - Pages that were static become server-rendered on every request after deployment. This affects page speed and the number of executions
- Reading 1.0 as "the same behavior as Next.js". The README says it does not reproduce behavior that is not documented by Next.js
On October 2, 2026, we directly opened and checked the README of cloudflare/vinext, the CHANGELOG of packages/vinext (main branch), and vinext's publication records in the npm registry. check, init, build and startup were each run once in the editorial team's test environment (Linux, Node v22.22.0, npm 10.9.4) against a test app made by adding one route handler to the create-next-app template (Next.js 16.3.8). We have not verified migrating a real business site, deploying to Cloudflare, how OpenNext or self-hosted Next.js behave, or comparisons of page speed or cost.
If you are reviewing the hosting of a Next.js site or planning its architecture as part of a redesign, talk to GleamHub.
