When the Vinext project was introduced, it was the result of an ambitious experiment aimed at verifying how far one could go in replicating the Next.js framework using Vite. In the seven months since that experiment, Vinext has evolved into a framework that is now reliably deployed in production environments for demanding, high-traffic dynamic applications.
Today, we announce the release of Vinext 1.0, another milestone on the path to enabling Next.js applications to be deployed anywhere. Vinext allows you to take any Next.js application, whether built with the Pages or App Router, and make it portable for deployment on any web platform, including platforms like Cloudflare Workers, Netlify, or AWS Lambda. Version 1.0 brings extensive improvements in compatibility, stability, and cache behavior, and prepares the project for long-term sustainability. There has never been a better time to migrate your Next.js project to Vinext; simply run the commands `npx vinext check` and `npx vinext init`.
At its initial release, Vinext was promising but incomplete. Since then, we have worked intensively to improve compatibility with the App Router and extend support to Pages Router applications, which we found have many long-standing users with large and complex projects that are difficult to migrate. Our goal was not to create a tool that only worked for users of the latest App Router features.
We focused on supporting both router types and meticulously tracked testing compatibility, which exceeds 99% for most important user-requested features. This improvement was driven by the active community around the project on GitHub. Immediately after Vinext's launch, the community tested a wide range of applications and identified gaps. Thanks to their diligence, we discovered challenges that were not immediately apparent in our test coverage. Vinext must behave exactly as Next.js does. It's not enough to imitate functions with the same name; for example, creating an alternative for `import { revalidatePath }` is simple, but the difficulty lies in ensuring it correctly affects rendered pages, cache entries, and future requests. Tracking application requests to ensure Vinext responds as expected – replicating not just the API but the behavior of the entire mechanism – was by far the biggest challenge.
Once we fix issues and add new features, it's crucial that we don't introduce regressions, especially if Next.js makes a change. That's why we've also built an extensive test suite: thousands of targeted tests covering the framework's core behavior across both routers, development and production servers, and target deployment environments like Node.js and Cloudflare Workers. Every night, we also run the Next.js end-to-end test suite against Vinext, which provides us with a continuously up-to-date view of our compatibility and ensures we immediately notice regressions resulting from merged changes. In addition to automated testing, we work directly with large customers who use Vinext in production to ensure they don't encounter issues.
The clearest messages we received from Vinext users indicated that certain Next.js features are crucial for the framework and that Vinext doesn't actually need to implement everything Next.js has released in recent versions to be extremely useful to them. We have therefore focused on providing better support where you truly need it:
App Router, Pages Router, and Hybrid Applications: User feedback confirmed that the Pages Router is still important and migrations are not a simple step. Therefore, Vinext supports both routing paths, including React Server Components, Server Actions, API routes, route handlers, middleware, and client-side navigation.
Complete Page Lifecycle: Pages can be rendered in many different ways: on the server, prerendered during build time, exported as static files, or cached with Incremental Static Regeneration (ISR) at the page level. We have ensured that background and on-demand revalidation works with any output.
Cache: Vinext has a set of shared cache functionalities across the App and Pages Routers and supported runtimes. We provide additional support for utilizing platform-specific cache mechanisms.
Planning a new website or app?
Tell me what you have in mind — I will take a look and advise on the best way forward.
Observability: Vinext provides Next.js-compatible tracing across both routers, so existing OpenTelemetry and Sentry setups continue to work. On some platforms, tracing also integrates with native observability tools.
Next.js Ecosystem Compatibility: Vinext implements the public `next/*` interface and supports common Next.js patterns for using authentication, MDX, image optimization, fonts, metadata, environment variables, and much more.
Full Runtime Support for Workers: Although Vinext can run anywhere, server-side code can run in a Workers runtime environment during both development and production, with direct access to bindings like image optimization.
We have also made migration a part of the framework: just two commands are needed to verify the compatibility of your Next.js installation and its modifications, and to set up the configuration for Vite and deployment, all while preserving the entire original Next.js project structure.
When we spoke with teams about what features were important to them, something became clear. Next.js 16 has taken the stance that Cache Components are an important part of the framework's future; however, most teams we spoke with were not using them and did not consider their support a prerequisite for migration. Therefore, today Vinext has limited support for the "use cache" directive that powers Cache Components, and while we will improve compatibility in this area as well, we are much more focused on the key priorities listed above.
When first announced, Vinext supported Incremental Static Regeneration (ISR) after the initial request but did not yet render pages during the build. Applications use `generateStaticParams()` and `getStaticPaths()` to identify pages that should be rendered at build time and expect page-level ISR to link these initial responses with background and on-demand revalidation. Vinext 1.0 supports this lifecycle for both router types. It can prerender App Router and Pages Router paths during build time, serve these responses via page-level ISR, and invalidate them by path or tag. It also supports `output: