# Astro on Vercel vs Webflow Cloud **Author:** Ben Sabic --- [Astro](https://astro.build/) 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](https://vercel.com/docs/functions) with [Fluid compute](https://vercel.com/fluid) 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 ## How Astro runs on each platform 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. | Area | Vercel | Webflow Cloud | | ---------------------- | ---------------------------------------------------------------------------------- | ------------------------------------------------------------------------------- | | Framework support | First-class, via the official `@astrojs/vercel` adapter | Via the `@astrojs/cloudflare` adapter | | Build setup | Zero-config detection; add the `@astrojs/vercel` adapter for on-demand rendering | `astro.config.mjs` (adapter and base path), `wrangler.json`, and `webflow.json` | | Server runtime | Vercel Functions on Fluid compute, full Node.js | Cloudflare Workers in `workerd` | | Compute model | Fluid compute, enabled by default | Workers, V8 isolates | | Execution location | Regional; runs in the region you choose, with multi-region support on higher plans | Global, across Cloudflare's network | | Memory | Up to 4 GB per function | 128 MB per isolate | | Reading config in code | `process.env` | `locals.runtime.env` and `Astro.locals.runtime.env`, injected at runtime only | | Package manager | npm, pnpm, Yarn, or Bun | npm only | | Deploy | Git push or the `vercel` CLI | Git push (GitHub) or the `webflow cloud deploy` CLI | ## How the runtimes differ 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. ## Which Astro features are supported 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. | Astro feature | Vercel | Webflow Cloud | | ------------------------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | On-demand rendering (SSR) | Supported on Vercel Functions | Supported on the Workers runtime | | Static rendering and prerendering | Supported | Supported | | Server islands | Supported | Supported | | Sessions | Supported | Supported, with a Key Value Store binding | | Astro middleware | Supported on Vercel Functions, or at the edge with `middlewareMode: 'edge'` | Runs on the Workers runtime | | Image optimization (`astro:assets`) | On-demand optimization with minimal configuration | Astro's default Sharp service isn't supported; configure Cloudflare's image service, and external images aren't resized | | Incremental Static Regeneration (ISR) | Supported with `adapter: vercel({ isr: true })` | Not available | | Streaming | Supported | Supported | | Node.js APIs in server code | Full Node.js runtime | `nodejs_compat` flag, with limited isolate API support | 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. ## Where your code runs 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. ## Configuring and deploying Astro 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. `// astro.config.mjs on Vercel import { defineConfig } from "astro/config"; import vercel from "@astrojs/vercel"; import react from "@astrojs/react"; export default defineConfig({ output: "server", adapter: vercel(), integrations: [react()], });` 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. `// astro.config.mjs on Webflow Cloud import { defineConfig } from "astro/config"; import cloudflare from "@astrojs/cloudflare"; import react from "@astrojs/react"; export default defineConfig({ base: "/YOUR_BASE_PATH", // your environment's mount path build: { assetsPrefix: "/YOUR_BASE_PATH", // must match the mount path }, output: "server", adapter: cloudflare({ platformProxy: { enabled: true }, }), integrations: [react()], vite: { resolve: { // Map react-dom/server to the edge build for React 19 on the Workers runtime alias: import.meta.env.PROD ? { "react-dom/server": "react-dom/server.edge" } : undefined, }, }, });` 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. ## Mapping storage and data services The clearest code-level difference is how each platform exposes storage. On Webflow Cloud, you declare storage [bindings](https://developers.webflow.com/webflow-cloud/storing-data/overview) 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](https://vercel.com/docs/marketplace-storage), 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: | Need | Webflow Cloud | Vercel | | --------------------- | --------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Object storage | Object Storage | [Vercel Blob](https://vercel.com/storage/blob) | | Key-value and caching | Key Value Store | [Redis from the Marketplace](https://vercel.com/marketplace?search=Redis), or [Edge Config](https://vercel.com/storage/edge-config) for read-heavy config | | SQL database | SQLite | [Postgres from the Marketplace](https://vercel.com/marketplace?search=postgres) | | AI inference | No first-party option | [AI Gateway](https://vercel.com/ai-gateway) with [AI SDK](https://ai-sdk.dev/) | 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. ## Mapping scheduled tasks, queues, and workflows 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. | Need | Webflow Cloud | Vercel | | ----------------------------- | --------------------- | ----------------------------------------------------- | | Scheduled jobs | No first-party option | [Vercel Cron Jobs](https://vercel.com/docs/cron-jobs) | | Message queues | No first-party option | [Vercel Queues](https://vercel.com/docs/queues) | | Durable, multi-step processes | No first-party option | [Vercel Workflows](https://vercel.com/workflows) | 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. ## How each platform prices computing 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](https://vercel.com/docs/functions/usage-and-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](https://webflow.com/blog/simplified-plans-and-updated-pricing-2026), so check the [Webflow pricing page](https://webflow.com/pricing) 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. | Limit | Vercel | Webflow Cloud | | ------------------------ | -------------------------------------------------------------------- | -------------------------------------------------------------------- | | Compute time per request | Wall-clock duration up to 300s (Hobby) and 800s (Pro and Enterprise) | CPU time up to 30s, with a 20s request timeout | | Memory | Up to 4 GB | 128 MB per isolate | | Bundle size | 250 MB | 10 MB per worker | | Beyond the limit | Vercel Workflows for minutes-to-months processes | No durable workflow primitive; move long work to an external service | 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. ## Comparing developer experience 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](https://vercel.com/products/observability) for tracing requests and monitoring function usage, the [Vercel Firewall](https://vercel.com/security/web-application-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](https://vercel.com/docs/analytics), and [Speed Insights](https://vercel.com/docs/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](https://webflow.com/feature/devlink), to sync Webflow components and styles into your app. ## When to choose Vercel or Webflow Cloud 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. | If your project... | Consider | Why | | --------------------------------------------------------------------------------- | ------------- | --------------------------------------------------------------------------------------------------- | | Depends on npm packages that need full Node.js APIs | Vercel | Runs in a full Node.js runtime with no compatibility flags or runtime workarounds | | Uses Astro's image optimization through `astro:assets` | Vercel | On-demand optimization works with minimal setup, and external images can be optimized | | Needs Incremental Static Regeneration or on-demand revalidation | Vercel | The `@astrojs/vercel` adapter supports ISR with `adapter: vercel({ isr: true })` | | Is I/O-bound or AI-heavy, with LLM calls, agents, or MCP servers | Vercel | Fluid compute and Active CPU pricing avoid billing CPU during waits, and Workflows handle long jobs | | Needs more than 128 MB of memory or longer than 30s of compute per request | Vercel | Function memory is configurable up to 4 GB, with durations up to 800s on Pro and Enterprise | | Needs scheduled jobs, queues, or durable workflows | Vercel | Cron Jobs, Queues, and Workflows are first-party features | | Wants fewer platform-specific files and less runtime configuration | Vercel | One adapter line replaces `wrangler.json`, `webflow.json`, base-path config, and edge workarounds | | Serves short, compute-light responses with the lowest latency to users everywhere | Webflow Cloud | Workers execute at the edge across Cloudflare's global network | | Embeds an app inside an existing Webflow site at a path like `/app` | Webflow Cloud | Apps mount into a Webflow site and integrate with Webflow content and DevLink | | Should be billed and managed alongside an existing Webflow plan | Webflow Cloud | App compute is bundled into Webflow site plans rather than billed separately | 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. ## Next steps - [Astro on Vercel](https://vercel.com/docs/frameworks/frontend/astro) - [Vercel Functions](https://vercel.com/docs/functions) and [Fluid compute](https://vercel.com/docs/fluid-compute) - [The](https://docs.astro.build/en/guides/integrations-guide/vercel/) [`@astrojs/vercel`](https://docs.astro.build/en/guides/integrations-guide/vercel/) [adapter](https://docs.astro.build/en/guides/integrations-guide/vercel/) - [Incremental Static Regeneration on Vercel](https://vercel.com/docs/incremental-static-regeneration) - [Storage on the Vercel Marketplace](https://vercel.com/docs/marketplace-storage) and [Vercel Blob](https://vercel.com/docs/vercel-blob) --- [View full KB sitemap](/kb/sitemap.md)