Cloudflare just slop forked Next.js…

Cloudflare’s V-Next is a Next.js re-implementation built on V (and leveraging V’s Rust-based bundler, rolldown), aiming to let Next.js apps run on Cloudflare Workers without the fragile “repackage Next output” approach used by Open Next. The project’s pitch is straightforward: instead of reverse-engineering the results of next build, rebuild the Next framework itself so routing, middleware, ISR, image optimization, SSR, server actions, and streaming behave natively on non–Vercel platforms.

The effort is framed as unusually fast and unusually complete. Cloudflare reportedly got basic SSR, middleware, server actions, and streaming working in a single day. By day three, it reached deployment on Cloudflare Workers with full client hydration. Over the rest of the week, it focused on edge cases, expanded the test suite, and pushed API coverage to 94% of the Next API—done with roughly $1,100 in AI tokens. The technical rationale is that V’s architecture (including rolldown) can improve build performance and reduce bundle size, which matters because portability often comes with performance tradeoffs.

That portability claim is also where the rivalry with Vercel comes in. Vercel’s CTO publicly criticized the work as a “slop fork,” while Cloudflare’s Germo and Matthew exchanged pointed messaging, including a migration guide and critical vulnerabilities found in the project. The transcript suggests those vulnerabilities make V-Next feel like a true Next clone, but the practical takeaway is that the ecosystem conflict is happening alongside real engineering progress.

To test whether it works outside theory, the walkthrough targets a newsletter app (“byes.dev”) that uses typical Next.js patterns: signup, an archive read from disk, and an endpoint that returns HTML for email templates. For simple apps, the migration might be as easy as swapping the next command for V-Next in package.json. For this app, the author reports needing refactoring, then uses an agent skill (via Cursor) to migrate the codebase.

The migration highlights concrete compatibility issues with V. The agent adds type module to package.json so JavaScript files are treated as ES modules, and it refactors JSX-bearing files to use the JSX extension required by V. Even then, the process initially leaves “half the app” broken, requiring additional follow-up until the app runs on V.

On whether it’s worth switching, the verdict is cautious: bleeding-edge software still shifts under developers’ feet, and the migration cost may not pay off yet. Still, performance numbers are a strong signal. Cloudflare’s Trust Me Bro benchmarks claim V-Ex production build times are up to 4.4× faster than Next and client bundle size is 57% smaller, attributed largely to vit and rolldown. The author’s own local test reportedly hits 5× faster builds on the newsletter site, though they caution not to treat personal results as authoritative.

Overall, V-Next’s significance isn’t just platform portability—it’s the combination of speed-to-coverage, a more native approach than output repackaging, and performance improvements that could make “deploy anywhere” a realistic expectation for Next-style apps if the remaining edge cases keep shrinking.