Edge infrastructure: Why Cloudflare beats Vercel

The coupling challenge

Next.js is a surely a solid framework and on Vercel, it genuinely does just work. The challenge emerges when requirements evolve beyond what that particular pairing was designed for.

The framework and the platform were built together for websites predominantly. That tight coupling shows in features like image optimisation, middleware execution, and incremental static regeneration. These were designed with Vercel's infrastructure in mind.

However, when you deploy Next.js elsewhere, you're getting an approximation, not the same product. 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 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.

Rather than adapting a framework built for another platform, we prefer frameworks designed to run anywhere and are compatible with multiple runtimes with Vite plugin as the enabler here.

Vite has become the dominant build tool for modern web development, powering 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 Vite plugin isn't an adapter like 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. 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 code that works locally but fails in production, this parity eliminates an entire category of deployment problems. (Three cheers are very much deserved here)

Why we prefer React Router

Beyond the runtime story, React Router itself offers advantages over Next.js for the projects we build.

Complete control over caching: React Router gives you full control over your application's behaviour. Want to set custom cache-control headers on any response? You can. Next.js sets immutable cache headers on certain assets that cannot be overridden. Its image optimisation pipeline enforces its own caching rules regardless of your requirements.

These constraints make sense on Vercel's infrastructure. They become friction when you need fine-grained control over how your application interacts with CDNs and caches. In our experience with enterprise clients (particularly in retail and manufacturing), custom caching strategies are the rule, not the exception.

Native Cloudflare integration: 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 followed with the same level of native support.

These frameworks treat Cloudflare Workers as a first-class deployment target. 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.

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 flexibility over time

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

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, 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 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. This flexibility is architectural insurance for the long term.

Cost predictability at scale

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.

Why the governance model matters

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.

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 thus isn't tied to driving deployments to a specific provider.

In a glance

Why we like Cloudflare combined with React-Router a lot.

What this means in practice

Through projects for many clients we've developed a clear understanding of when this framework and infrastructure pairing provides measurable advantages:

• When you need custom caching strategies: Enterprise platforms rarely fit standard caching patterns. Full control over cache headers and invalidation strategies is essential.

• When development-production parity prevents problems: The closer your development environment matches production, the fewer surprises during deployment. This compounds over time.

• When framework flexibility reduces risk: Frontend frameworks evolve rapidly. Infrastructure that supports multiple frameworks through the same primitives reduces migration risk.

• When platform independence matters: Organisations operating critical platforms benefit from framework choices that don't lock them into single-vendor ecosystems.

• When you acknowledge that digital infrastructure far exceeds web-only: Modern digital platforms serve far more than only web browsers. LLM-powered agents query your APIs. Mobile applications need the same data. Voice assistants, IoT devices, and automated systems all interact with your infrastructure. Your digital platform isn't a website. It's a multi-channel system.

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.

Combined with the business and infrastructure advantages of edge-native architecture (global distribution, cost predictability, AI at the edge), this framework approach delivers consistent outcomes for the enterprise platforms we build.

If your platform requirements align with what we've described here, we should talk about whether this approach might serve you better.