Summary: Cloudflare’s Vinext 1.0, announced September 28, 2026, lets existing Next.js apps using either router run on Cloudflare Workers, Netlify or AWS Lambda. Cloudflare reports more than 99% test compatibility for most important customer-requested features and nightly Next.js end-to-end checks, while cache warming moves prerendering from the build machine into its network. Heavy use of the “use cache” directive remains the key migration caveat.
The real decision Vinext 1.0 forces is not “is the compatibility good enough?” It’s “where do I want my Next.js app to run?” Until now, the practical answer was: wherever Vercel’s tooling points you. Cloudflare announced Vinext 1.0 on September 28, 2026, and the pitch is simple — take an existing Next.js application, whether it uses the Pages Router or App Router, and deploy it to Cloudflare Workers, Netlify, or AWS Lambda.
The compatibility numbers behind the 1.0 label
Vinext started in February 2026 as a week-long experiment: could one engineer plus a large token budget reproduce the Next.js framework on top of Vite? Seven months later, Cloudflare says customers run it in production for high-traffic dynamic applications.
The hard part wasn’t cloning function names. As the Cloudflare post puts it, building an alternative revalidatePath import is easy; making it actually affect rendered pages, cache entries, and future requests is the work. Their test compatibility for most important customer-requested features now surpasses 99%, backed by thousands of focused tests and a nightly run of the Next.js end-to-end suite against Vinext. That nightly run matters: when Next.js merges changes, the team knows about regressions within a day, not after a customer reports one.
What 1.0 actually covers
The feature list reflects what large customers said they needed, not a mirror of every Next.js release:
- Both routers, including hybrid apps, with React Server Components, Server Actions, middleware, and route handlers.
- The full page lifecycle: server rendering, build-time prerendering, static export, and page-level ISR with background and on-demand revalidation.
- A shared caching layer across routers and runtimes, plus Workers Cache integration.
- OpenTelemetry and Sentry compatibility, and native Workers Observability on Cloudflare.
One omission is deliberate and telling. Next.js 16 made Cache Components a pillar of the framework’s future, but Cloudflare reports most teams they talked to weren’t using them and didn’t consider them a migration blocker. Vinext has limited support for the "use cache" directive. If your app leans heavily on that directive, this is the caveat to check before migrating.
Cache warming is the interesting bet
Migration is two commands — npx vinext check and npx vinext init — but the more original idea is cache warming. Sites with hundreds of thousands of possible URLs waste hours in sequential builds rendering pages nobody visits, while the build machine can’t prioritize the handful of routes that matter.
Vinext moves prerendering from the build machine to Cloudflare’s network. The deployment uploads a new Worker version at 0% of production traffic, requests pages from that version to populate caches, then promotes the deployment once warmed. Vinext can also identify high-traffic pages itself and add them to the prerender list. For anyone who has watched a CI pipeline crawl through a long tail of low-traffic routes, this reframes where pre-render compute belongs — similar in spirit to how Cloudflare’s Worker previews give every agent branch its own runtime, treating deployment-time infrastructure as a first-class product surface rather than glue scripts.
Maintained by agents, gated by humans
The ongoing maintenance model is worth watching independently of the framework itself. Every morning an agent reviews Next.js canary commits, fetches diffs, and opens tracking issues. Every night the compatibility matrix regenerates. When a gap surfaces, agents can locate the change across both codebases, build a reproduction, port tests, and propose a fix — while maintainers focus on the cases that need judgment about how Next.js behavior should map onto Vite.
Practical takeaway
If you’re on Next.js and locked in mainly by inertia rather than Vercel-specific features, npx vinext check is a cheap way to find out how portable your app really is. If you depend on Cache Components or other very recent App Router features, wait or verify carefully. And if you’re deciding where a new app should live, Vinext is now a credible argument that the framework choice and the hosting choice can be separate decisions.