Next.js on Vercel vs Webflow Cloud

Next.js is a full-stack React framework with server-side rendering, streaming, server actions, and file-based routing. Vercel creates and maintains Next.js, and the framework runs on any platform that hosts a JavaScript server, including both Vercel and Webflow Cloud. Your application code remains largely the same on both platforms. What changes is the runtime your server code executes in, which Next.js features are fully supported, how you configure and deploy the project, and which storage and background-processing services you connect to.

On Vercel, Next.js runs on Vercel Functions with Fluid compute, the native platform built by the team that maintains the framework. On Webflow Cloud, it runs as a Cloudflare Worker in the V8-isolate-based workerd runtime through the OpenNext Cloudflare adapter, mounted at a path inside a Webflow Cloud environment. Those runtimes lead to different tradeoffs in feature support, package compatibility, where your code executes, how it scales, and how you pay for compute. This guide breaks down how the two platforms differ so you can decide which one fits your project.

In this comparison guide, you'll learn:

• How Next.js deploys and runs on Vercel and Webflow Cloud
• Which Next.js features each platform supports, and where support is partial
• How the Vercel Functions and Cloudflare Workers runtimes differ in compatibility and execution
• How storage and background processing map across the two platforms
• How each platform prices computing
• When to choose Vercel or Webflow Cloud for your project

Both platforms build the same Next.js application and deploy from Git, with a preview URL per pull request. The differences start at the server runtime and flow through to feature support, configuration, scaling, and pricing.

The most consequential difference is the server runtime. Vercel runs Next.js in a full Node.js runtime on Vercel Functions, while Webflow Cloud runs it in workerd, the same V8-isolate runtime that powers Cloudflare Workers.

This determines which packages run without extra work. On Vercel, npm packages that depend on Node.js built-in modules work without configuration, because the runtime offers full Node.js coverage. On Webflow Cloud, the deployment enables the nodejs_compat flag to provide Node.js APIs, but the isolate model still has limited API support. Webflow's documentation recommends using fetch for outbound calls and avoiding clients like axios that may not run in the runtime, and some native or filesystem-dependent modules aren't supported.

Memory and request limits also differ. Vercel Functions let you configure up to 4 GB of memory per function on Pro and Enterprise plans, which helps with heavier in-memory work. Webflow Cloud apps run with a fixed 128 MB limit per isolate and cap CPU time at 30 seconds per request, with a 20-second request timeout. A single isolate can handle multiple requests, so you design around a smaller, shared memory budget.

Because Vercel maintains Next.js, the framework runs on Vercel with full feature support, and new framework capabilities land on Vercel first. On Webflow Cloud, support depends on what the OpenNext Cloudflare adapter can translate into the Workers runtime, and several Next.js features are partially supported or unavailable.

The caching difference matters most for content-heavy Next.js sites:

• On Vercel, the CDN applies caching based on your framework code and manages Cache-Control headers for you, and ISR supports request collapsing, durable storage, and tag-based invalidation.
• On Webflow Cloud, the platform replaces application Cache-Control headers with private, no-cache and strips cache-tag headers, so standard HTTP cache invalidation doesn't apply, and you work within the platform's own caching behavior.

Vercel Functions run in a region you choose, with a default close to your deployment. You can place them near your database to reduce data-access latency, and Pro and Enterprise plans can run functions across multiple regions. Webflow Cloud runs your app across Cloudflare's global network, close to the user making the request.

The tradeoff is between proximity to the user and proximity to your data. Global edge execution lowers network latency for short, compute-light responses served near users. Regional execution keeps your function close to its database or APIs, which often matters more for data-heavy server functions that make multiple round-trip requests per request.

On Vercel, deployment is zero-configuration. Vercel detects Next.js on import and sets the build command and output directory for you, so a basic deployment needs no platform-specific files. You read the configuration from process.env, add an optional vercel.json for project settings, and deploy by pushing to Git or running the vercel CLI. Vercel connects to GitHub, GitLab, and Bitbucket, with automatic deploys on push and a preview URL for every pull request.

On Webflow Cloud, a Next.js app requires several configuration files and runs at a base path within the environment. You install the OpenNext Cloudflare adapter and Wrangler, then add the files that Webflow Cloud reads at build time.

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  basePath: "/YOUR_BASE_PATH",    // your environment's mount path
  assetPrefix: "/YOUR_BASE_PATH", // must match the mount path
};

export default nextConfig;

You also add open-next.config.ts to configure the adapter, a wrangler.json that sets the nodejs_compat flag and asset handling, and a webflow.json that tells Webflow Cloud the framework is nextjs. Because your app is served from a mount path such as /app, you set basePath and assetPrefix to that path and include it in client-side fetch calls and asset references. Environment variables are injected at runtime only and aren't available during the build, so avoid build-time validation that reads them.

Webflow Cloud deploys when you push to the connected GitHub branch or when you run webflow cloud deploy from the CLI. You can deploy an app to its own domain or attach it to an existing Webflow site, and app deployments run independently of Webflow site publishing. Publishing the site doesn't trigger an app deploy, and deploying the app doesn’t require republishing the site. Webflow Cloud connects to GitHub for continuous deployment, and only next build is used, so custom build commands aren't supported.

The clearest code-level difference is how each platform exposes storage.

On Webflow Cloud, you declare storage bindings in wrangler.json, and Webflow Cloud creates the corresponding resources in your environment and exposes them on the runtime env.

On Vercel, you read connection details from process.env and talk to each store through its SDK or client. When you provision storage from the Vercel Marketplace, Vercel adds the connection string and credentials as environment variables for you.

The table below maps Webflow Cloud's storage options to their Vercel counterparts:

Webflow Cloud's storage tier is built on Cloudflare primitives (D1 for SQLite, Workers KV for the key-value store, and R2 for object storage), with storage limits that vary by Webflow plan. Vercel sources databases and key-value stores through Marketplace integrations, which wire credentials into your environment variables and bill through your Vercel account.

Background work is where the platforms diverge most.

Vercel offers first-party features for scheduled jobs, message queues, and durable, long-running processes. Meanwhile, Webflow Cloud focuses on request handling and storage, and doesn't expose scheduled jobs, queues, or a durable workflow primitive.

On Vercel, Vercel Workflows run durable steps that can pause, resume, and retain state for minutes to months, which supports long-running processes beyond a single function's duration limit.

On Webflow Cloud, apps are bound by a 30-second CPU limit and a 20-second request timeout, so work that would otherwise run on a schedule or as a durable job moves to an external service.

Both platforms meter compute based on active CPU time rather than wall-clock time, so neither charges full compute rates while your code waits on I/O such as database queries or model responses. The mechanics and packaging differ.

Vercel Functions on Fluid compute use Active CPU pricing. You pay for Active CPU at $0.128 per hour, Provisioned Memory at $0.0106 per GB-hour, and per invocation. CPU is billed only while your code runs, memory is billed while a request is in flight, and nothing is billed between requests. In-function concurrency allows a single instance to handle multiple requests, and predictive scaling keeps instances warm to reduce cold starts. The Hobby plan includes certain functions for free, while Pro and Enterprise plans add usage-based billing with a monthly resource allotment.

Webflow Cloud compute is bundled into Webflow's site plans rather than billed as a standalone compute product. Each plan includes a monthly allotment of app requests and CPU time, and app bandwidth counts toward your overall Webflow site bandwidth. Webflow Cloud meters requests and active CPU time, excluding time spent waiting on external resources, and storage limits scale with your plan. If usage exceeds your plan's limits for two consecutive months, the site plan upgrades automatically. Webflow adjusted these allotments in its 2026 plan changes, so check the Webflow pricing page for the current figures.

The two platforms package compute differently. Vercel bills for granular active CPU usage plus provisioned memory on dedicated plans, while Webflow Cloud includes request and CPU time allotments within a website plan. As a result, your actual cost depends on your traffic volume, the CPU usage of each request, and the memory your app needs.

The execution limits also measure different things, which matters when you compare them.

Vercel's per-request limit is based on wall-clock duration, the total time a function can take to respond, including time spent waiting on I/O. Webflow Cloud's CPU limit excludes time spent waiting on network requests, but its 20-second request timeout still bounds the total time a request can take. A request that mostly waits on a database stays within the CPU limit yet must still return within that 20-second window.

Both platforms offer Git-based deployments, automatic preview URLs per pull request, and framework detection, so the day-to-day deploy workflow is similar. The differences are in what each platform bundles around that flow.

Vercel includes built-in observability for tracing requests and monitoring function usage, the Vercel Firewall for traffic protection, and instant rollbacks, alongside its preview-deployment workflow. As the native Next.js platform, Vercel also surfaces framework-aware features such as ISR, Image Optimization, and Draft Mode without extra configuration.

Webflow Cloud runs your app in the same workerd runtime locally as in production through Wrangler, so npm run preview builds your Next.js app and serves it from the correct mount path to closely match production. Webflow Cloud enables observability and logging by default, with log and deployment retention ranging from 1 hour to 3 days, depending on the plan, and a usage dashboard for requests and CPU time. For teams already building in Webflow, Webflow Cloud also integrates with the surrounding Webflow site, including DevLink, to sync Webflow components and styles into your app.

The framework is the same on both platforms, so the decision comes down to feature support, runtime compatibility, where your code needs to run, and how the app fits into your wider stack.

Many teams successfully run Next.js on either platform.

Choose Vercel when you want the full Next.js feature set with no adapter gaps, full Node.js compatibility, efficient pricing for I/O-bound and AI workloads, and first-party scheduling and workflow features. Choose Webflow Cloud when you're extending an existing Webflow site with an app at a mount path, want low-latency edge execution by default, or prefer to manage and bill app compute inside your Webflow plan.

• Next.js on Vercel
• Vercel Functions and Fluid compute
• Incremental Static Regeneration on Vercel
• Storage on the Vercel Marketplace and Vercel Blob
• Deploy a Next.js app to Vercel