Cloudflare Releases Vinext 1.0 to Run Next.js Applications on Vite

Cloudflare Releases Vinext 1.0 to Run Next.js Applications on Vite Cloudflare has announced Vinext 1.0, an open-source Vite-backed framework that allows Next.js applications to be deployed across platforms such as Cloudflare Workers, AWS Lambda, and Netlify. Vinext 1.0 supports both App Router and Pages Router with reported compatibility exceeding 99% for key customer-requested features. The release supports build-time prerendering and Incremental Static Regeneration (ISR), while adding network-level cache warming to reduce build times on Cloudflare Workers. Upstream Next.js changes are tracked through automated agents that inspect daily commits, run nightly test suites, and propose bug fixes. Expanded Router Support and Migration Vinext has broadened support from App Router to include Pages Router applications, addressing legacy codebases that are difficult to migrate. The framework features migration commands (`npx vinext check` and `npx vinext init`) and supports common patterns such as metadata, environment variables, MDX, and image optimization. While core features and test parity remain the focus, Vinext currently provides only limited support for Next.js 16's 'use cache' directive. Build Lifecycle and Network Cache Warming Vinext 1.0 adds support for rendering routes during the build via generateStaticParams() and getStaticPaths(), handling path- or tag-based ISR and static exports. To avoid prolonged build times on sites with large URL counts, Cloudflare introduced cache warming. This shifts prerendering from the build machine to Cloudflare's network by deploying the Worker to 0% of production traffic, populating caches with critical and high-traffic pages before promoting the deployment. Automated Upstream Tracking and Testing To prevent regressions against upstream Next.js canary commits, automated agents review daily diffs, create tracking issues, and regenerate compatibility matrices against the Next.js end-to-end test suite nightly. When gaps emerge, agents assist in reproducing the issue, porting tests, and proposing fixes, allowing maintainers to focus on framework-level Vite mapping.

Cloudflare 发布 Vinext 1.0：基于 Vite 运行 Next.js 并支持跨平台部署 Cloudflare 宣布推出开源项目 Vinext 1.0。该框架允许开发者使用 Vite 驱动 Next.js 应用，提供双路由兼容性与增强的缓存行为，使应用能够无缝迁移并部署至 Cloudflare Workers、Netlify 或 AWS Lambda 等任意平台。 Vinext 1.0 实现了对 Next.js Pages Router 与 App Router 的全面支持，客户关键特性兼容性超 99%。 支持构建期预渲染与增量静态再生（ISR），同时引入缓存预热机制以避免耗时漫长的传统构建渲染。 针对 Next.js 16 倡导的 Cache Components 及“use cache”指令，Vinext 目前仅提供有限支持并聚焦基础高频需求。 采用基于 AI Agent 与自动化测试的流水线，每日跟踪 Next.js 上游变更并自动化生成修复方案。 路由兼容性与核心功能支持 Vinext 最初源自单人 AI 实验，现已进化为面向高流量生产环境的框架。1.0 版本重点扩展了对大型老旧项目常见的 Pages Router 的支持，使其与 App Router 的关键客户功能测试兼容率超过 99%。框架对认证、MDX、图像优化、字体、元数据及环境变量等常用功能进行了适配，并允许开发者通过两行命令完成环境检查与迁移。针对 Next.js 16 推出的 Cache Components，因多数团队暂无硬性迁移需求，Vinext 目前仅保持有限支持。 构建优化与边缘缓存预热 此前 Vinext 仅在首个请求后支持 ISR，新版本则完整支持构建期预渲染、路径与标签失效机制，以及静态导出模式。为解决海量 URL 导致构建机器耗时过长的问题，Cloudflare 引入了网络级缓存预热：应用通过将新版本 Worker 部署至 0% 流量并在后台发起请求，在不阻塞构建且未接入真实流量前于边缘网络完成页面预渲染与缓存填充，之后再安全切换流量。 测试网络与 AI 驱动的自动化演进 为了保障框架行为与 Next.js 完全一致并防止代码回归，Vinext 维护了覆盖开发、生产及不同部署目标的数千项测试，每晚运行 Next.js 端到端测试套件。同时，项目部署了 AI Agent 流水线，每日追踪 Next.js canary 分支的提交并建立问题单，在发现断言失败时自动重现缺陷、移植测试并提交修复方案，协助维护者聚焦 Vite 映射的核心架构设计。

When we [launched Vinext](https://blog.cloudflare.com/vinext/) in February, it was the result of an audacious week-long AI-driven experiment to see how far one engineer, and a stack of tokens, could get to replicating the NextJS framework backed by Vite. In the seven months since that experiment, Vinext has grown into a framework that our customers trust and run in production for high-traffic, dynamic applications. Today we are announcing the release of Vinext 1.0, the latest step on our journey to make it possible to deploy Next.js apps anywhere. Vinext lets you take any Next.js application, whether it was built for the Pages or App Router, and make it portable to be deployed to any web platform, including the Cloudflare Workers free plan, Netlify, or AWS Lambda. Vinext 1.0 brings with it sweeping improvements to compatibility, stability, and caching behaviors, and sets the project up for the long term. There’s never been a better time to take your Next.js project and convert it to Vinext; just run `npx vinext check` and `npx vinext init`. On release Vinext was promising, but it was incomplete. Since then, we’ve spent a lot of time both improving App Router compatibility and expanding that to Pages Router apps — which we’ve learned many customers are longtime fans of, with large applications that are complex to migrate. We didn’t want Vinext to be a tool that only worked for people using the latest App Router features. Our focus has been on adopting both these routers, and watching our test compatibility closely, which for most important customer-requested features now surpasses 99%. This improvement has been fueled through the community around our [GitHub project](https://github.com/cloudflare/vinext). As soon as Vinext launched, that community threw it at a wide variety of applications to find the gaps. With their scrutiny, we found challenges not immediately obvious in the test coverage. Vinext needs to act exactly as Next.js behaves. It is not good enough to imitate functions with the same name. Building an alternative `import { revalidatePath }` is simple enough; the difficulty is in making sure it correctly affects the rendered pages, cache entry, and future requests. Tracing requests through the application to make sure Vinext responds in the way expected — and replicating not just the API, but the behavior of this machine — was by far the more challenging aspect. Once we’ve patched problems and brought new features forward, it’s important that we don’t regress, especially if Next.js makes a change. That’s why we’ve also built out our test suite: thousands of focused tests covering core framework behavior across both routers, the development and production server, and the deployment targets of Nodejs and Cloudflare Workers. We also run the Next.js end-to-end test suite against Vinext nightly, giving us a continually moving window on our compatibility, and making sure we immediately become aware of regressions coming from merged changes. Alongside the automated testing, we’ve been working directly with large customers that have Vinext in production to make sure they are not facing issues. The clearest messages we got from customers using Vinext is that certain Next.js features carry the framework and Vinext didn’t actually need to do *everything* that Next.js has launched in recent versions to be incredibly useful to them. So we focused on better support where you need it: `next/*` surface and supports common Next patterns for use of authentication, MDX, image optimization, fonts, metadata, environment variables, and more. We’ve also made migration part of the framework: it takes two commands to verify that your Next.js install and any modification you have made is compatible, and set up the Vite and deployment configuration while keeping all your previous Next.js project structure. When we talked to teams about what features were important for them, something stood out. Next.js 16 took a stance that Cache Components were an important part of the future of the framework, and yet most teams that we talked to were not using them and did not consider support a prerequisite to move. Therefore, Vinext today has limited support for the “use cache” directive that drives Cache Components, and though we will continue to improve compatibility there, we’re much more focused on the core priorities above. When we first announced Vinext, it supported Incremental Static Regeneration (ISR) after the first request, but it did not yet render pages during the build. Applications use generateStaticParams() and getStaticPaths() to identify pages that should be rendered when building, and they expect page-level ISR to connect those initial responses to background and on-demand revalidation. Vinext 1.0 supports that lifecycle for both routers. It can prerender App Router and Pages Router routes during the build, serve those responses through page-level ISR, and invalidate them by path or tag. It also supports output: "export" when the result you want is a fully static site. But this led us to question something: **Why should this rendering happen during the build at all?** A site with tens or hundreds of thousands of possible URLs can spend a seriously long time rendering pages that receive little traffic. The build process cannot evaluate the long tail of traffic that most sites experience and therefore cannot focus compute time on the smaller number of more critical pages. Instead you waste hours of time waiting for sequential builds working their way through thousands of pages, long after the most important routes are done. Cache warming is our solution to this, moving page prerendering from the build machine to Cloudflare’s network. Developers can continue to use Next.js primitives to identify the pages for prerendering, and Vinext can additionally identify high-traffic pages to add to this list. This happens in the background before your site is deployed to production, so that the moment it is, it is ready to serve rapid responses from the Cloudflare cache. Inside the deployment process, this works by uploading a new Worker version and deploying it to 0% of production traffic, before then requesting pages specifically from that version. This allows the rendering pipeline to work before any real users hit the new deployment. Once the caches have been populated, the deployment can be promoted safely. If the original experiment invented the one-off slopfork, the more consequential part has been how we can keep that process of self-improvement running indefinitely. The project is now focused on keeping the framework up to date with everything happening upstream. Next.js canary receives new commits every day. Each morning, an agent reviews the changes, fetches diffs, and opens tracking issues for anything that could affect Vinext. Every night, the compatibility matrix is regenerated as we run the Next.js test suite against Vinext. When one of these tests or issues reveals a gap, agents are now in the position where they can identify the change across both codebases, build a reproduction, port any relevant tests, and propose a fix. This review has been catching missing cases, unsafe caching behaviors, and differences in the development vs. production servers. Automation has helped us narrow the stream of activity into a focused set of changes that deserve attention, allowing the maintainers of the project to focus on only the issues that need context of how a process should map onto Vite from the Next.js implementation. We’re building a software factory for open source at Cloudflare, and you can see what we’re up to on [GitHub](http://github.com/cloudflare/vinext). Vinext is available for new applications, and existing Next.js projects. Start a new application today: Or migrate an existing application: And then deploy it to Cloudflare Workers, with our cache warming: Visit [vinext.dev](http://vinext.dev) for documentation, examples, and the current compatibility matrix. Vinext is open source at [github.com/cloudflare/vinext](http://github.com/cloudflare/vinext). Issues, pull requests, application reproductions, and feedback are welcome.