Vercel vs Webflow Cloud

Vercel and Webflow Cloud both deploy a full-stack JavaScript app from a Git repository, with a managed build, a global CDN, and a preview URL for every pull request. Both run your server code on compute that meters active CPU time, and both provision storage for you. What changes is the runtime your code executes in, how much of a framework's feature set you can run unchanged, where your code runs, and how the platform fits into the rest of your stack.

Vercel is the platform built by the team that creates and maintains Next.js. Your app runs on Vercel Functions with Fluid compute in a full Node.js runtime, and Vercel has first-class support for more than 35 frameworks, including Next.js, Astro, SvelteKit, and Nuxt. Functions run in a region you choose, so they sit close to your data, and the platform wraps managed caching, first-party storage, background jobs, observability, and a web application firewall around your deployment.

Webflow Cloud is Webflow's product for deploying a Next.js or Astro app as a Cloudflare Worker, mounted at a path inside a Webflow site or hosted on its own domain. Your code runs in the workerd runtime on V8 isolates, distributed across Cloudflare's global network, with support for Next.js 15+ and Astro 5+ through the Cloudflare adapter for each framework. A site-attached app integrates with the surrounding Webflow site, its CMS, and DevLink.

The right choice usually comes down to how much of a framework you need to run unchanged, whether your workload is data-heavy or compute-light, where your code should execute, and whether the app lives alongside an existing Webflow site. This guide compares the two across runtime, framework support, deployment, storage, background work, pricing, and developer experience, then closes with a scenario-by-scenario guide to help you match each to what you're building.

Both platforms turn a Git push into a deployed app and handle the build, CDN, and preview URLs for you. The differences start at runtime and extend to feature support, configuration, scaling, and pricing.

The most consequential difference is the server runtime. Vercel runs your app 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.

On Vercel, Fluid compute is the default. Single-function instances handle multiple concurrent requests, scale down to zero when traffic stops, and use predictive scaling and bytecode caching to reduce cold starts. Because the runtime offers full Node.js coverage, npm packages that depend on Node.js built-in modules run without extra configuration. Functions execute in a region you choose, with a default near your deployment, and Pro and Enterprise plans can run them across multiple regions.

On Webflow Cloud, your app runs as a Cloudflare Worker in workerd. The deployment sets 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. Workers run across Cloudflare's global network, close to the user making the request, with a fixed 128 MB of memory per isolate and a cold-start budget of up to 400 ms.

The practical trade-off 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 several round-trip requests per request.

Both platforms run Next.js and Astro, but they differ in breadth and depth.

Vercel has first-class support for more than 35 frameworks, including Next.js, Astro, SvelteKit, and Nuxt. As the maintainer of Next.js, it can run the full framework with no adapter gaps and new capabilities land on Vercel first. Webflow Cloud supports Next.js 15+ and Astro 5+ only, running each through a Cloudflare adapter: the OpenNext Cloudflare adapter for Next.js and the @astrojs/cloudflare adapter for Astro. Because each adapter must translate framework features into the Workers runtime, some features are partially supported or unavailable.

These gaps are most visible in Next.js, where the OpenNext Cloudflare adapter translates server-side features into the Workers runtime. The table below compares Next.js feature support on each platform:

For Astro, both platforms use an adapter.

• On Vercel, you add the first-party @astrojs/vercel adapter (static sites deploy with zero config; server-side rendering requires the adapter), which supports the full Vercel feature set, including ISR, on-demand revalidation, and Image Optimization.
• On Webflow Cloud, the @astrojs/cloudflare adapter targets the Workers runtime, handling server-side rendering, API routes, and server islands, though some Node.js APIs and integrations need adjustment, and Astro API routes must opt into the edge runtime with an export const config = { runtime: 'edge' } directive.

The caching difference matters most for content-heavy 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.

On Vercel, deployment is zero-configuration. Vercel detects your framework on import, sets the build command and output directory, and a basic deployment needs no platform-specific config 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 brought-your-own app requires several configuration files and runs at a base path within its environment. For a Next.js app, you install the OpenNext Cloudflare adapter and Wrangler, then add the files Webflow Cloud reads at build time. Because the app serves from a mount path such as /app, you set basePath and assetPrefix to that path:

import type { NextConfig } from "next";

const nextConfig: NextConfig = {
  basePath: "/app",    // your environment's mount path
  assetPrefix: "/app", // 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 names the framework:

{
  "cloud": {
    "framework": "nextjs"
  }
}

An Astro app follows the same pattern with astro.config.mjs (setting base, build.assetsPrefix, and the Cloudflare adapter), a wrangler.json, and a webflow.json with the framework set to astro. Environment variables are injected at runtime only and aren't available during the build, so you avoid build-time validation that reads them. You include the base path in client-side fetch calls and asset references, and API routes need export const runtime = 'edge' to run on the Workers runtime. Webflow Cloud deploys when you push to the connected GitHub branch or run webflow cloud deploy, and only next build or astro build is used, so custom build commands aren't supported.

Vercel's strengths come from being a full application platform: a complete framework feature set, a compute model tuned for I/O and AI workloads, managed caching, first-party storage and background jobs, and built-in observability and security.

Because Vercel runs a full Node.js runtime, npm packages that depend on Node.js built-in modules work without compatibility flags, and you can run heavier in-memory work with up to 4 GB of memory per function on Pro and Enterprise plans. Vercel also supports more than 35 frameworks with first-class integration, and as the maintainer of Next.js, it ships full support for ISR, use cache, Node.js runtime middleware, and Image Optimization without adapter gaps. Functions auto-scale to handle traffic, up to 30,000 concurrent executions on Hobby and Pro and 100,000 or more on Enterprise.

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. If a function spends 400 ms waiting on a database query and 100 ms processing the result, you're billed for the 100 ms of active CPU. This model suits I/O-bound and AI workloads such as LLM inference, agents, and MCP servers, where functions spend much of their time waiting on external responses. The Hobby plan includes functions for free within limits, while Pro and Enterprise add usage-based billing with a monthly resource allotment.

Vercel's CDN provides fully managed caching and routing. Frameworks like Next.js, Astro, SvelteKit, and Nuxt declare which routes are cacheable at build time, and Vercel handles CDN caching, durable ISR storage, request collapsing, and revalidation automatically. The ISR cache lives alongside your function region and persists content for 31 days or until you revalidate. On-demand and tag-based revalidation purge content globally in about 300 ms. Because Vercel knows a path is cacheable before the first request arrives, it can collapse requests, store results durably, and roll back instantly.

Vercel offers Vercel Blob for object storage, backed by Amazon S3, with public CDN-served URLs and files up to 5 TB. For databases and key-value stores, you provision a resource from the Vercel Marketplace, which wires the connection string and credentials into your environment variables and bills through your Vercel account. You read those values from process.env and talk to each store through its SDK or client.

Vercel provides first-party features for background work.

Cron Jobs run scheduled tasks, Queues provide durable, at-least-once message processing, and Workflows run durable steps that can pause, resume, and retain state for minutes to months. Workflows support long-running processes that exceed a single function's duration limit, which is useful for multi-step onboarding, payment processing, ETL pipelines, and long-running AI agents. Webflow Cloud focuses on request handling and storage and doesn't expose scheduled jobs, queues, or a durable workflow primitive, so work like this moves to an external service.

Vercel includes built-in observability for tracing requests and monitoring function usage, the Vercel Firewall for traffic protection, and instant rollbacks, alongside the 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's strengths come from running at the edge by default, provisioning storage with zero configuration, and slotting into the wider Webflow platform.

Webflow Cloud runs your app across Cloudflare's global network, so responses execute close to the user without a region to choose. For short, compute-light responses, this lowers network latency everywhere. The runtime starts code in lightweight V8 isolates with a cold-start budget of up to 400 ms and strong isolation between executions.

Webflow Cloud's storage is built on Cloudflare primitives:

• SQLite (D1) for relational data
• Key Value Store (Workers KV) for key-value data
• Object Storage (R2) for files

You declare a storage binding in wrangler.json, and Webflow Cloud creates the corresponding resource in your environment and exposes it on the runtime env. There's no separate storage product to enable, and you manage records from the Webflow Cloud dashboard. Storage limits scale with your Webflow plan, ranging from 100 MB to 1 GB for SQLite and 1 GB to 25 GB for Object Storage.

Site-attached Webflow Cloud apps mount into an existing Webflow site at a path, such as /app and deploys independently of site publishing, so publishing the site doesn't trigger an app deploy, and deploying the app doesn't require republishing the site. For teams already building in Webflow, the app integrates with the surrounding site and with DevLink, which syncs Webflow components, styles, and variables into your app so the app and the marketing site share one design system.

Webflow Cloud compute is bundled into Webflow's site plans rather than billed as a standalone product. Each plan includes a monthly allotment of app requests and CPU time, app bandwidth counts toward your overall Webflow site bandwidth, and storage limits scale with your plan. Webflow Cloud meters requests and active CPU time, excluding time spent waiting on external resources. Webflow adjusted these allotments in its 2026 plan changes, so check the Webflow pricing page for current figures. For a team that already manages and bills a Webflow site, keeping app compute on the same plan can mean one less platform to manage and one less bill to track.

The two platforms measure compute differently, which matters when you compare them. Vercel's per-request limit is wall-clock duration, the total time a function can take to respond, including time spent waiting on I/O. Webflow Cloud's limit is CPU time, which excludes time spent waiting on network requests, but its 20-second request timeout still bounds the total time a request can take. Requests that mostly wait on a database stay within the CPU limit yet must still return within that 20-second window.

Both platforms run Next.js and Astro, 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 run Next.js or Astro on either platform.

Choose Vercel when you want the full framework feature set with no adapter gaps, full Node.js compatibility, efficient pricing for I/O-bound and AI workloads, and first-party storage, 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 and Astro on Vercel
• Vercel Functions and Fluid compute
• Active CPU pricing for Vercel Functions
• Incremental Static Regeneration on Vercel
• Storage on the Vercel Marketplace and Vercel Blob
• Vercel Cron Jobs, Queues, and Workflows