Astro on Vercel vs Webflow Cloud

Astro is a web framework for content-driven sites, with static site generation, on-demand server rendering, and an island architecture that ships zero JavaScript by default. Astro runs on any platform that hosts a JavaScript server through a platform adapter, including both Vercel and Webflow Cloud. Your application code stays largely the same on both platforms. What changes is the runtime your server code executes in, which Astro features are fully supported, how you configure and deploy the project, and which storage and background-processing services you connect to.

On Vercel, Astro runs on Vercel Functions with Fluid compute through the official @astrojs/vercel adapter, in a full Node.js runtime. On Webflow Cloud, it runs as a Cloudflare Worker in the V8-isolate-based workerd runtime through the @astrojs/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 Astro deploys and runs on Vercel and Webflow Cloud
• Which Astro 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 compute
• When to choose Vercel or Webflow Cloud for your project

Both platforms build the same Astro application and deploy from Git, with a preview URL per pull request. Astro needs an adapter to server-render on either platform, so the differences start with the adapter and the runtime it targets, then flow through to feature support, configuration, scaling, and pricing.

The most consequential difference is the server runtime.

Vercel runs Astro 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, so some native or filesystem-dependent modules aren't supported. The Astro Cloudflare adapter also needs a Vite alias that maps react-dom/server to react-dom/server.edge for React 19, and you may need to disable Astro's built-in CSRF protection to handle form POST requests. Astro's default image optimization runs on Sharp, which doesn't work in the isolate, so you configure Cloudflare's image service instead.

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.

On Vercel, the official @astrojs/vercel adapter runs Astro in full Node.js, so Astro's server features and Vercel's framework-aware features work together with minimal configuration.

On Webflow Cloud, support depends on what the @astrojs/cloudflare adapter can translate into the Workers runtime, and a few Astro capabilities need extra configuration or aren't available.

Two differences matter most for content-heavy Astro sites:

• Image optimization: On Vercel, astro:assets optimizes images on demand with minimal setup. On Webflow Cloud, Astro's default Sharp-based service doesn't run in the isolate, so you switch to Cloudflare's image service, and external images aren't resized.
• Incremental Static Regeneration: On Vercel, you enable ISR with adapter: vercel({ isr: true }) to cache rendered pages and revalidate them on demand. On Webflow Cloud, the Cloudflare adapter doesn't offer ISR, so you work within the platform's own caching behavior.

Vercel Functions run in the region you choose, with a default near 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 close to zero-configuration. Vercel detects Astro on import and sets the build command and output directory for you. To render routes on demand, you add the official @astrojs/vercel adapter to astro.config.mjs, and that adapter line is the only platform-specific change a basic deployment needs. You read 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.

1
// astro.config.mjs on Vercel
2
import { defineConfig } from "astro/config";
3
import vercel from "@astrojs/vercel";
4
import react from "@astrojs/react";
5

6
export default defineConfig({
7
  output: "server",
8
  adapter: vercel(),
9
  integrations: [react()],
10
});

On Webflow Cloud, an Astro app requires several configuration files and runs at a base path within the environment. You install the @astrojs/cloudflare adapter and Wrangler, then add the files that Webflow Cloud reads at build time.

1
// astro.config.mjs on Webflow Cloud
2
import { defineConfig } from "astro/config";
3
import cloudflare from "@astrojs/cloudflare";
4
import react from "@astrojs/react";
5

6
export default defineConfig({
7
  base: "/YOUR_BASE_PATH",            // your environment's mount path
8
  build: {
9
    assetsPrefix: "/YOUR_BASE_PATH",  // must match the mount path
10
  },
11
  output: "server",
12
  adapter: cloudflare({
13
    platformProxy: { enabled: true },
14
  }),
15
  integrations: [react()],
16
  vite: {
17
    resolve: {
18
      // Map react-dom/server to the edge build for React 19 on the Workers runtime
19
      alias: import.meta.env.PROD
20
        ? { "react-dom/server": "react-dom/server.edge" }
21
        : undefined,
22
    },
23
  },
24
});

Alongside astro.config.mjs, you add a wrangler.json that sets the nodejs_compat flag, asset handling, and any storage bindings, and a webflow.json that tells Webflow Cloud the framework is astro. Because your app is served from a mount path such as /app, you set base and build.assetsPrefix to that path and use import.meta.env.BASE_URL and import.meta.env.ASSETS_PREFIX in client-side fetch calls and asset references. Astro API routes need export const config = { runtime: "edge" } to run on the Workers runtime, and environment variables are injected at runtime only, so they aren't available during the build. 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 astro 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. In an Astro Server Endpoint you read them from locals.runtime.env, and in a component you read them from Astro.locals.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. If you used Drizzle ORM with SQLite on Webflow Cloud, Drizzle supports Postgres too, so you keep your schema-first workflow when you move to a Marketplace database.

Background work is where the platforms diverge most.

Vercel offers first-party features for scheduled jobs, message queues, and durable, long-running processes. 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. Through the @astrojs/vercel adapter, framework-aware features such as ISR, Image Optimization, Web Analytics, and Speed Insights work with minimal configuration.

Webflow Cloud runs your app in the same workerd runtime locally as in production through Wrangler, so npm run preview builds your Astro 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 Astro on either platform.

Choose Vercel when you want full Node.js compatibility, on-demand image optimization and ISR with minimal configuration, 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.

If you're moving an existing Astro project, a dedicated migration guide walks through swapping the @astrojs/cloudflare adapter for @astrojs/vercel, removing the Webflow Cloud configuration files, and remapping storage to the Vercel Marketplace.

• Astro on Vercel
• Vercel Functions and Fluid compute
• The @astrojs/vercel adapter
• Incremental Static Regeneration on Vercel
• Storage on the Vercel Marketplace and Vercel Blob