What actually happens between the moment a developer pushes code and the moment a user in another country sees a page? That question shapes every Vercel, Netlify, and Cloudflare Pages decision. All three platforms promise the same headline: connect a repository, get a global site with previews and serverless logic. Behind that promise, though, they make very different bets about where code runs, what runtime it runs on, and how tightly the hosting layer binds to storage and data.
Those bets shape what a team can build two years from now. This article walks through the architecture decisions that matter, in plain language, with the trade-offs spelled out.
Why the runtime choice is the first real fork in the road
The single most consequential decision is not pricing or build minutes. It is the execution model for dynamic code. Each platform offers two lanes: a Node.js-style function that runs in a region and behaves like a small server, and an edge function that runs in lightweight isolates close to the user.
Vercel splits these explicitly. Its standard Functions run on AWS Lambda under the hood with full Node.js APIs, while Edge Functions run on a V8-isolate runtime with a narrower API surface. Netlify follows a similar split but picks a different engine for the edge lane: Netlify Functions are Lambda-based, while Netlify Edge Functions run on Deno. Cloudflare Pages collapses the two lanes. Pages Functions are compiled into Cloudflare Workers and execute on the same V8-isolate runtime that powers the rest of Cloudflare’s network. (Cloudflare clef omni 30b multimodal decision model 2026) (Content delivery network)
Why does the engine matter? Because it decides which libraries work. A V8 isolate is not a Node.js process. It starts in milliseconds and scales without you thinking about regions, but it cannot open a raw TCP socket the way Node can, and many npm packages assume Node APIs that simply are not there. Deno brings web-standard APIs and partial npm compatibility, but it is still its own world. Full Node functions are the opposite: maximum compatibility, regional execution, and cold starts to manage.
A practical rule that holds up in real projects: put authentication callbacks, PDF generation, image processing, and anything touching a legacy SDK on the Node lane. Put redirects, A/B bucketing, header rewriting, geo-personalization, and token checks on the edge lane. Teams that mix this up usually discover it the hard way, when a library fails at deploy time or a cold start ruins a checkout flow.
How each platform wires compute to storage
The second decision is where your data lives relative to your code. Latency is rarely about raw compute speed. It is about round trips.
Cloudflare’s structural advantage is that Pages sits on the same network as Workers, KV, R2, D1, and Durable Objects. A Pages Function can bind directly to those primitives without a second vendor, which keeps the request path short. That tight coupling is the reason so many teams treat the platform as a full stack rather than a static host. If you want to see how these pieces fit together at a deeper level, the breakdown of how cloud storage architecture actually works with objects and erasure coding explains the durability model underneath object stores like R2. (Cloudflare Workers documentation)
Vercel and Netlify take an integration-first approach. Their storage products and partnerships connect to external providers, which is convenient but adds a network hop and, often, a second bill. Neither path is wrong. It is a question of whether you want one vendor’s primitives or best-of-breed services stitched together.
| Decision | Vercel | Netlify | Cloudflare Pages |
|---|---|---|---|
| Node-style functions | AWS Lambda | AWS Lambda | Workers with Node compatibility flags |
| Edge runtime | V8 isolates | Deno | V8 isolates (Workers) |
| First-party storage | Integrated products | Blobs and integrations | KV, R2, D1, Durable Objects |
| Next.js support | First-party | Adapter-based | Adapter-based |
| Strongest fit | Next.js apps | Framework-agnostic sites | Data-heavy, globally distributed apps |
The framework question: Next.js is not neutral ground
Vercel maintains Next.js, and that relationship shows. Features like incremental static regeneration, image optimization, and middleware tend to land on Vercel first and work most predictably there. Netlify and Cloudflare support Next.js through adapters, and the adapters are good, but “supported” and “native” are different words for a reason.
This matters most for teams on the App Router with heavy use of server components and caching. Before committing, list the Next.js features you actually use, then test each one on the target host in a staging deploy. Adapter coverage moves fast, so a feature that failed last year may work now, and the reverse is also true after a major Next.js release.
For teams not on Next.js, the calculus flips. Astro, SvelteKit, Remix, and plain static sites deploy cleanly on all three, and the decision comes down to runtime and storage rather than framework politics.
Build pipelines look alike until they don’t
Every platform builds from Git, creates immutable deployments, and issues a preview URL per branch or pull request. The differences hide in build environment limits, cache behavior, and monorepo handling.
Three habits separate smooth deployments from painful ones:
- Pin your build tool versions in the repository rather than relying on platform defaults, which change without notice.
- Keep build output deterministic so caching actually helps; timestamps and random IDs in generated files quietly break it.
- Test both the preview deploy and the production deploy, because environment variables and bindings are configured separately.
Build minutes and concurrency limits are the most volatile facts on any comparison chart. They change quarterly. Check the current documentation for your account tier instead of trusting a blog post, including this one.
Edge compute limits nobody mentions until launch
Edge functions are excellent until they are not. Three constraints bite teams repeatedly.
First, CPU time limits. Edge runtimes cap how long a request can compute, and the cap is short. Anything resembling a batch job belongs on the Node lane or a queue.
Second, memory and payload size. Isolates are small by design. Parsing a 20 MB JSON file at the edge will fail or crawl.
Third, statefulness. Isolates are ephemeral and can be created anywhere. If you need coordination, counters, or websockets, you need a stateful primitive, not a variable in module scope. This is exactly the gap Durable Objects fill on Cloudflare, and the same architectural lesson applies to any platform: treat edge code as stateless and push state to a purpose-built service. The same principle shows up in cloud networking architecture, where virtual networks actually work by keeping routing logic separate from the workloads it serves.
Security and identity at the edge
Running auth checks at the edge is one of the best uses of the model. Verifying a session token before a request reaches origin cuts latency and load. But there is a trap: edge middleware that fetches user records from a regional database on every request can be slower than doing nothing, because the round trip crosses the planet.
The fix is to keep the edge check cryptographic and stateless, then hydrate full user data closer to the data store. Teams that get this right see middleware as a filter, not a data layer.
What the architecture means for disaster recovery
Multi-region failure is where architecture decisions get tested. A platform with regional Node functions and a global CDN fails differently from one where compute and storage share a network. Neither is automatically safer. What matters is whether you have a documented recovery path.
Practical steps that work regardless of vendor:
- Keep the site buildable from a clean clone with no platform-specific build steps.
- Store configuration as code so a rebuild elsewhere is a config change, not a rewrite.
- Test both a restore and a backup. An untested backup is a hope.
The design patterns in this guide to cloud disaster recovery architecture cover how failover, replication, and recovery objectives fit together, and they apply whether your functions run on Lambda or Workers.
Cost models reward different traffic shapes
Static hosting is cheap everywhere. The bill diverges on compute and bandwidth. Edge invocations are usually priced far below regional function invocations, which rewards architectures that push simple work to the edge and reserve Node functions for heavy lifting. Bandwidth pricing varies enough between platforms that a media-heavy site can see a five-figure annual difference.
The honest advice: model your actual traffic, including the boring parts like image requests and API polling, before you sign anything. Vendor calculators help, but they assume your architecture, not the one you have.
A decision framework that survives contact with reality
Strip away the marketing and three questions remain.
Does your code need Node APIs? If yes, weight the Node lane heavily and check cold-start behavior under real load.
Is your data already on a platform’s primitives? Co-location beats theoretical performance every time.
How deep is your framework’s integration? First-party support reduces surprise, and surprise is expensive.
If the answers point in different directions, split the stack. A static front end on one platform and APIs elsewhere is a legitimate, common architecture. The mistake is choosing a host for its dashboard and discovering the runtime mismatch three months in. The same trap appears in cloud API management architecture, where modern gateways actually work only when the gateway layer matches the traffic patterns it fronts.
Conclusion
Vercel, Netlify, and Cloudflare Pages are not three versions of the same product. They are three different answers to the question of where code should run and what it should be allowed to touch. Vercel optimizes for Next.js and a clean developer experience. Netlify optimizes for framework flexibility with a Deno-based edge. Cloudflare optimizes for tight coupling between compute, storage, and a global network.
The right choice starts with the runtime your code needs, then the data it talks to, then the framework it is built on. Get those three in order and the platform decision mostly makes itself. Get them wrong and no amount of preview URLs will save the launch.
FAQ
What is the main difference between Vercel, Netlify, and Cloudflare Pages?
The core difference is the execution model. Vercel pairs AWS Lambda functions with V8-isolate edge functions. Netlify pairs Lambda functions with Deno-based edge functions. Cloudflare Pages compiles functions into Workers, so compute runs on the same V8-isolate network as its storage products.
Do edge functions support full Node.js?
No. Edge runtimes are not Node.js processes. They expose web-standard APIs and a limited subset of Node compatibility, which varies by platform. Libraries that depend on raw sockets, native modules, or filesystem access generally need a Node-style function instead.
Which platform is best for a Next.js app?
Vercel has the deepest Next.js integration because it maintains the framework. Netlify and Cloudflare support Next.js through adapters that cover most features. Teams using advanced caching or server components should test their specific feature set on the target host before committing.
Are build limits a good reason to pick a platform?
Rarely. Build minutes and concurrency limits change often and are easy to work around with caching and monorepo configuration. Runtime, storage locality, and framework support are far more durable reasons to choose a host.
Can I mix platforms in one architecture?
Yes, and many teams do. Hosting a static front end on one platform while running APIs elsewhere is common. The key is keeping configuration as code so each piece can move independently without a rewrite.
How should a team test a platform before migrating?
Deploy a real branch with real environment variables, then exercise the slow paths: authentication callbacks, large payloads, cold starts, and a database round trip from the edge. A staging deploy that mirrors production traffic patterns reveals more than any benchmark.
