Cloudflare is announcing Vinext 1.0, marking the maturation of a framework that began as a week-long AI-assisted experiment in February to see whether a single engineer could replicate Next.js functionality using Vite. Over seven months, the project has evolved from a proof of concept into a production-grade tool trusted by customers running high-traffic applications.
Vinext enables developers to take existing Next.js applications—built with either the Pages or App Router—and deploy them to any web platform, including Cloudflare Workers' free tier, Netlify, or AWS Lambda. The 1.0 release introduces substantial improvements to compatibility, stability, and caching, alongside a streamlined migration path: running npx vinext check and npx vinext init converts a Next.js project.
Graduation to 1.0
When Vinext launched, it was functional but incomplete. Development effort has focused on expanding compatibility across both routing systems. Pages Router support proved essential; Cloudflare discovered that many customers maintain large, complex applications built on Pages Router and cannot easily migrate. The framework now supports both routers equally, with test compatibility for most customer-requested features exceeding 99%.
Community feedback from the GitHub project accelerated improvements by exposing gaps that standard test coverage missed. The core challenge was not merely implementing functions with matching names—such as revalidatePath—but ensuring behavior matched Next.js exactly. Tracing requests through applications to verify that Vinext produces the expected rendered output, cache entries, and future request handling proved far more demanding than API replication.
To prevent regressions, Cloudflare built an extensive test suite with thousands of focused tests covering core framework behavior across both routers, development and production servers, and deployment targets including Node.js and Cloudflare Workers. The team runs the Next.js end-to-end test suite against Vinext nightly, providing continuous visibility into compatibility and immediate awareness of changes that could cause regressions. Direct collaboration with large production customers supplements automated testing.
What's in 1.0
Customer feedback revealed that Vinext did not need to implement every feature Next.js has shipped recently to deliver significant value. Development prioritized support where it matters most:
- App Router, Pages Router, and Hybrid applications: Both routing systems are supported, including React Server Components, Server Actions, API routes, route handlers, middleware, and client-side navigation.
- The complete page lifecycle: Pages can be rendered on the server, pre-rendered at build time, exported as static assets, or cached with page-level Incremental Static Regeneration (ISR). Background and on-demand revalidation work with any output mode.
- Caching: A shared set of caching functions spans both routers and supported runtimes, with additional support for Cloudflare's Workers Cache.
- Observability: Next.js-compatible tracing works across both routers, allowing existing OpenTelemetry and Sentry setups to continue functioning. On Cloudflare Workers, traces integrate with native Workers Observability.
- Next.js ecosystem compatibility: The public next/* surface is implemented, with support for common patterns including authentication, MDX, image optimization, fonts, metadata, and environment variables.
- First-class runtime support for Workers: Server code runs in the Cloudflare workerd runtime during development and production, with direct access to bindings such as image optimization and hyperdrive.
Migration is built into the framework itself. Two commands verify that a Next.js installation and any customizations are compatible, then configure Vite and deployment settings while preserving the existing project structure.
When discussing feature priorities with teams, Cloudflare found that Next.js 16's emphasis on Cache Components and the "use cache" directive did not align with customer needs. Most teams surveyed were not using Cache Components and did not consider support essential for migration. Vinext 1.0 therefore offers limited support for the "use cache" directive, with continued improvements planned but lower priority than core features.
Pre-rendering and cache warming
The original Vinext supported Incremental Static Regeneration after the first request but did not render pages during the build. Applications use generateStaticParams() and getStaticPaths() to identify pages for build-time rendering, expecting page-level ISR to connect those initial responses to background and on-demand revalidation.
Vinext 1.0 supports this lifecycle for both routers, prerendering App Router and Pages Router routes during the build, serving those responses through page-level ISR, and invalidating them by path or tag. It also supports output: "export" for fully static sites.
However, this raised a fundamental question: why prerender during the build at all? Sites with tens or hundreds of thousands of possible URLs can spend substantial time rendering pages that receive minimal traffic. The build process cannot predict the long tail of traffic patterns and therefore cannot prioritize compute on the most critical pages. Instead, sequential builds waste hours working through thousands of pages long after important routes are complete.
Cache warming addresses this by moving page prerendering from the build machine to Cloudflare's network. Developers continue using Next.js primitives to identify pages for prerendering, and Vinext can additionally identify high-traffic pages to include. This happens in the background before production deployment, ensuring rapid cached responses are ready when the site goes live.
The deployment process uploads a new Worker version and deploys it to 0% of production traffic, then requests pages specifically from that version. This allows the rendering pipeline to execute before real users encounter the new deployment. Once caches are populated, the deployment can be promoted safely.
What we're doing next
While the original experiment created a one-off implementation, the more significant achievement has been establishing a process for continuous self-improvement. The project now focuses on staying synchronized with upstream development. Next.js canary receives new commits daily. Each morning, an agent reviews changes, fetches diffs, and opens tracking issues for anything that could affect Vinext. Each night, the compatibility matrix regenerates as the Next.js test suite runs against Vinext.
When tests or issues reveal gaps, agents can identify changes across both codebases, build reproductions, port relevant tests, and propose fixes. This review has caught missing cases, unsafe caching behaviors, and differences between development and production servers.
Automation narrows the stream of activity into a focused set of changes deserving attention, allowing project maintainers to concentrate on issues requiring context about how processes should map from Next.js implementation onto Vite. Cloudflare describes this as building a software factory for open source, with activity visible on GitHub.
Try it out
Vinext is available for new applications and existing Next.js projects. Create a new application with:
npm create vinext-app@latest my-app
Convert an existing Next.js project with:
npx vinext check && npx vinext init
Deploy to Cloudflare Workers with cache warming enabled:
npx @vinext/cloudflare deploy --warm-cache
Documentation, examples, and the current compatibility matrix are available at vinext.dev. Vinext is open source at github.com/cloudflare/vinext. Issues, pull requests, application reproductions, and feedback are welcome.