Edge infrastructure: Why Cloudflare beats Vercel

When "it just works" stops working

Next.js is an excellent framework. On Vercel, it genuinely does just work. The challenge emerges when your requirements evolve beyond what that particular pairing was designed for.

The framework and the platform were built together, and that tight coupling shows. Features like image optimisation, middleware execution at the edge, and incremental static regeneration are designed with Vercel's infrastructure in mind. When you deploy elsewhere, you're not getting the same product. You're getting an approximation.

This isn't a secret. Cloudflare, AWS, Netlify, and others have invested significant engineering effort into making Next.js run on their platforms. The OpenNext project, which Cloudflare actively contributes to, exists specifically to bridge this gap. It transforms Next.js build output into something that can run on alternative infrastructure. The adapter currently doesn't support the Edge runtime, requires specific compatibility flags and dates to function correctly, and some features arrive months after Next.js releases them.

None of this is a criticism of the engineers working on OpenNext. They're solving a genuinely hard problem: making a framework designed for one platform run well on another. But the existence of that problem is itself informative.

A different approach entirely

So what's the alternative? Rather than adapting a framework built for another platform, we use frameworks that were designed with Cloudflare Workers as a first-class target from the start.

Cloudflare's Vite plugin is the enabler here. Vite has become the dominant build tool for modern web development, powering frameworks like React Router, Astro, SvelteKit, and many others. Cloudflare's plugin integrates directly with Vite's architecture, meaning any Vite-based framework can run natively on Workers without transformation layers.

Here's a distinction that matters: the Cloudflare Vite plugin isn't an adapter in the same sense as OpenNext. It doesn't transform build output from one format to another. Instead, it runs your code directly in workerd, the same open-source runtime that powers Cloudflare Workers in production.

During local development, your server code executes in the actual Workers runtime, not in Node.js pretending to be something else. This isn't a simulation or an approximation. When you run vite dev, you're running the same environment you'll deploy to. The bindings work identically. The APIs behave the same way. The constraints you'll face in production surface immediately during development.

For teams who've experienced the particular frustration of code that works locally but fails in production, this parity is transformative. It compresses the feedback loop and eliminates an entire category of "works on my machine" problems.

The case for React Router

Beyond the infrastructure story, there's a compelling argument for React Router itself over Next.js.

React Router gives you complete control over your application's behaviour. Want to set custom cache-control h

eaders on any response? You can. Next.js, by contrast, sets immutable cache headers on certain assets that cannot be overridden, and its image optimisation pipeline enforces its own caching rules regardless of your requirements. These constraints make sense on Vercel's infrastructure, but they become friction when you need fine-grained control over how your application interacts with CDNs and caches.

React Router v7 (the successor to Remix) was the first full-stack framework to provide complete support for the Cloudflare Vite plugin. Not through an adapter, not through a compatibility layer, but through direct integration built in partnership with Cloudflare's engineering team. Astro has followed with the same level of native support. These frameworks treat Cloudflare Workers as a first-class deployment target, not an afterthought.

The practical difference is significant. When Cloudflare releases new platform capabilities, framework support typically follows quickly. When issues arise, they're addressed in the framework itself, not in a separate adapter with its own release cycle and maintenance burden.

Bindings: the speed of light, not the speed of HTTP

Cloudflare Workers isn't just a place to run JavaScript. It's an integrated platform with KV storage, D1 databases, R2 object storage, Durable Objects for stateful applications, Queues for background processing, and Workers AI for inference at the edge.

When you build on Vite-based frameworks with the Cloudflare plugin, these services are accessible through bindings that work identically in development and production. But here's the part that doesn't get enough attention: bindings aren't HTTP calls. They're direct connections within Cloudflare's infrastructure.

When your Worker reads from KV or queries D1, that communication doesn't traverse the public internet. It happens within Cloudflare's network, limited only by the speed of fibre optics between machines, not by the overhead of HTTP round-trips, TLS handshakes, and DNS resolution. For latency-sensitive applications, this architectural advantage compounds across every database query and storage operation.

Contrast this with the assembly required when hosting Next.js elsewhere: you'll need to integrate separate services, manage credentials across boundaries, and accept the latency penalties of cross-provider communication for every request.

Framework agility

Here's an under-appreciated advantage of the Vite-based approach: your infrastructure choice doesn't lock you into a specific framework.

React Router, Astro, and other Vite-based frameworks all deploy to Cloudflare Workers through the same plugin and the same platform primitives. If your requirements evolve, if a different framework becomes more suitable for a new project, or if you simply want to adopt emerging tools, your infrastructure investment remains intact.

This flexibility is architectural insurance. The frontend framework landscape continues to evolve rapidly, and betting everything on a single framework's trajectory is a concentrated risk. Building on a platform that supports multiple frameworks lets you adapt without migration projects.

Cost predictability at scale

Vercel's pricing model works well for many use cases, particularly during early growth. But as traffic scales, costs can become unpredictable. One of the more significant differences is how compute time is measured.

Vercel bills based on wall-clock time: the total duration your function runs, including time spent waiting for database queries, API responses, and other I/O operations. Cloudflare bills based on CPU time: only the moments when your code is actually executing on the processor. For typical web applications that spend far more time waiting on I/O than crunching numbers, this distinction can mean paying for a fraction of what you'd pay elsewhere.

Consider an API endpoint that takes 200ms to respond, but spends 180ms of that time waiting for a database query. On a wall-time billing model, you pay for 200ms. On Cloudflare, you pay for 20ms. As request volumes grow, this difference compounds significantly.

Beyond billing mechanics, Cloudflare owns and operates its own global network of data centres. Vercel, like most platforms, runs on AWS infrastructure. This means Cloudflare can optimise the full stack, from hardware to runtime, and deploy to locations that make geographic sense rather than being constrained by where their cloud provider has regions. Your compute runs close to your users globally by default, without configuring regions or paying premiums for distribution.

A note on governance

The relationship between a framework and its primary commercial sponsor deserves consideration. Vercel employs much of the Next.js core team, and the framework's development priorities naturally align with the platform's commercial interests. More notably, several React core team members have moved from Meta to Vercel over the past few years. While the React team's vision for Server Components originated independently, the practical reality is that Vercel has become the largest corporate backer of React development outside of Meta.

This isn't nefarious. It's the economic reality of open-source development. But it does create a dynamic where React's evolution and Next.js's roadmap are increasingly intertwined, and where features optimised for Vercel's infrastructure receive more attention than features that benefit self-hosters or alternative platforms.

For Shopify, the real challenge is not about how many different pieces of complex technology we can use but the opposite. Cloudflare helps us find a simple way to achieve something very complex that we can scale and maintain.

Duncan DavidsonVP of Developer Productivity | Shopify

React Router's governance model is different. While Shopify employs the core team, the framework doesn't have an affiliated hosting platform with competing economic incentives. The framework's success isn't tied to driving deployments to a specific provider.

In one glance

Why we prefer Cloudflare.

Betting on openness

Our choice of Cloudflare and Vite-based frameworks is ultimately a bet on openness. Open runtimes (workerd is open source). Open frameworks (React Router, Astro). Open standards (Vite's environment API was developed collaboratively with the broader ecosystem).

We believe the infrastructure choices made today will have compounding effects over the lifetime of the applications we build. Choosing platforms and frameworks designed for portability and interoperability reduces future optionality costs, even if the immediate developer experience is comparable.

The Vercel and Next.js combination remains a legitimate choice for many teams and many projects. But it's not the only legitimate choice, and for organisations that value infrastructure flexibility, cost predictability, and true dev/prod parity, the Cloudflare ecosystem offers compelling advantages that the mainstream narrative often overlooks.

At Two Point O, we've made up our mind and we believe it will shapeshift your digital platform.