← Back to blog

Cloudflare’s Next.js strategy: OpenNext, Vinext, and the Void Zero bet

A quick story about a familiar problem

If you’ve built with Next.js long enough, you’ve probably felt this tension:

  • Next.js is incredibly productive.
  • Vercel is tightly integrated with Next.js and tends to offer a smoother developer experience.
  • But at some point you ask: Can I run this somewhere else without giving up everything that makes Next.js… Next.js?

That question sits at the center of a lot of platform strategy-especially for Cloudflare.

Over the past couple of months, Cloudflare hasn’t made just one move toward “Next.js outside Vercel.” They’ve been building a sequence of bets: some pragmatic, some ambitious, and some clearly about the long game.

This is that sequence.

Act 1: The practical bridge (OpenNext)

The first thing you notice when you try to run Next.js outside Vercel is that the ecosystem isn’t designed for it. You can deploy Node. You can deploy serverless. You can deploy edge functions. But Next.js output-the real thing-has a lot of assumptions baked in.

This is where OpenNext enters the story.

OpenNext is the “make it work” layer. It’s not trying to reinvent Next.js. It’s trying to translate it:

  • take what Next.js produces
  • adapt it so it can run on different runtimes
  • reduce the need for app teams to rewrite their code

Cloudflare has clearly recognized this as the most immediate route to credibility: enable portability today, not someday. It also meant Cloudflare started supporting the OpenNext open-source folks financially and through code contributions.

What it feels like: “Let’s bridge the gap first. We can talk about reinvention later.”

Act 2: The ambitious rewrite (Vinext)

Then a more daring idea appears.

What if the problem isn’t “how do we adapt Next.js output,” but rather:

That’s the direction behind Vinext.

Cloudflare introduced it here:

  • https://blog.cloudflare.com/vinext/
  • https://vinext.dev/

Vinext’s vibe is different from OpenNext. It’s closer to: “We can keep the developer-facing API familiar, but rebuild the engine underneath.” The bet is that a Vite-based approach can give you a build artifact that’s better positioned to run anywhere.

Vinext’s intent (as it reads today):

  • rebuild Next.js internals on top of Vite
  • keep the Next.js API surface recognizable (minimal app code changes)
  • avoid having to reverse-engineer Next.js bundles for every runtime

And then reality shows up.

Cloudflare itself says it’s not production ready and still has feature gaps. Looking at activity:

  • https://github.com/cloudflare/vinext/pulse

…it doesn’t look like a project with a huge dedicated team behind it (at least publicly). That doesn’t mean it’s dead-but it does mean the timeline is unclear.

What it feels like: “This could be the future… but it’s not the present yet.”

Act 3: The tooling pivot (Void Zero)

At this point, the story gets bigger than Next.js.

Cloudflare’s problem isn’t only runtime. Cloudflare already has a strong platform. The bigger challenge is how developers experience that platform.

That’s why the move toward Void Zero matters:

  • https://vite.dev/
  • https://voidzero.dev/

Because if Cloudflare wants to compete for modern web workloads, the competition isn’t only “who has the fastest edge.” It’s also:

  • who has the smoothest local development flow
  • who has the least painful build/deploy loop
  • who helps teams debug the weird stuff
  • who makes the platform feel obvious

Bringing in deep Vite/tooling expertise is a signal that Cloudflare sees DX as strategic. Not a nice-to-have.

What it feels like: “The platform is strong, but the interface to the platform needs to be world-class.”

Act 4: Beyond Next.js (Void / void.cloud)

Then Void Zero announces something that reframes the whole picture: Void / void.cloud.

  • https://void.cloud/

Now we’re not talking about “Next.js outside Vercel.” We’re talking about “a modern app workflow where build and deploy are one continuous experience,” built around the Vite ecosystem.

The pitch is roughly:

  • built on the Vite toolchain
  • closes the gap between development and deployment
  • supports multiple meta-framework ecosystems (TanStack Start, React Router, SvelteKit, Nuxt, Astro)
  • can act as both:

This is where Cloudflare’s broader direction becomes clearer. If you connect the dots:

  • OpenNext is the bridge
  • Vinext is the experimental rewrite
  • Void Zero is the tooling investment
  • Void is the bigger “own the workflow” play

And it also lines up with Cloudflare’s visible push into AI: a unified toolchain + platform can make AI-assisted development more effective (fewer bespoke configs, more predictable primitives).

What it feels like: “Don’t just run frameworks-shape how people build with them.”

Ending (for now): what this story is really about

Cloudflare’s moves suggest a clear arc:

  1. Make Next.js deployable outside Vercel (OpenNext).
  2. Explore a re-architecture that could change the rules (Vinext).
  3. Invest in the tooling layer to improve developer experience (Void Zero).
  4. Broaden beyond Next.js to stay relevant across ecosystems (Void).

The cliffhangers to watch

  • Does Vinext get real traction and staffing, or remain a prototype?
  • Do Cloudflare + Void Zero ship a coherent “build → deploy” workflow that feels magical?
  • Will this become a production-grade, low-lock-in path for teams that want Next.js and independence?

For now, it reads like Cloudflare is assembling pieces of a bigger platform story. The open question is whether the pieces will land as one coherent product experience-or stay as interesting experiments orbiting the same problem.

← Back to blog