// the find
cloudflare/vinext
Vite plugin that reimplements the Next.js API surface — deploy anywhere
vinext is a Cloudflare-built Vite plugin that reimplements the Next.js API surface (App Router, Pages Router, RSC, Server Actions, middleware) from scratch on top of Vite, rather than wrapping `next build` output. It targets teams who want Next.js's programming model but Vite's build tooling and a deploy target other than Vercel, with Cloudflare Workers as the first-class destination.
Reimplementing from scratch (vs. OpenNext's approach of adapting next build output) gets native `cloudflare:workers` binding access with no `getPlatformProxy()` workaround, plus faster builds and smaller bundles. The compatibility matrix is unusually honest for a project this young — a real ✅/🟡/⬜ table per API instead of a vague marketing claim, with a 'known gaps' section that names specific broken things (Cache Components, build-time image/font pipeline, native modules in RSC dev). Test coverage is substantial: 1,700+ Vitest and 380+ Playwright tests, including tests ported directly from Next.js's own suite and OpenNext's Cloudflare conformance suite, plus running Vercel's actual App Router Playground as an integration test. `vinext init` does AST-aware config merging instead of clobbering your Vite config, and explicitly doesn't touch `next.config`, `tsconfig.json`, or source files.
Cache Components / Partial Prerendering — a core piece of Next.js 16 — is only partially implemented, and the README admits cache profiles, tags, and resume behavior 'do not yet match Next.js in every case'; that's exactly the kind of gap that surfaces only in production. Native modules (sharp, resvg, satori, lightningcss, canvas) can fail in App Router dev mode specifically, so your dev and prod environments diverge for anything doing image/font generation. Reimplementing the Next.js API surface from scratch means an ongoing chase against every new Next.js release; the README says commit-level tracking of upstream Next.js is only 'planned,' not built yet. It's also very new — the project's own FAQ says it 'has not yet been battle-tested across the full range of production Next.js workloads' and explicitly points people who want a proven path to OpenNext instead, so anyone adopting today is taking on real early-adopter risk.