When an Astro and Webflow hybrid build earns its complexity

The deploy button on Webflow’s product page for Webflow Cloud ships a starter repo from Webflow’s own GitHub organization, and the repo is named hello-world-astro.

So the vendor’s default example for its own app-hosting platform is an Astro app, not a community hack or a paid sync tool in the middle. Webflow chose Astro to demonstrate its own product.

That settles whether Astro and Webflow work together. For contrast, running Shopify inside Webflow takes one of three integration patterns, and none of the three is Webflow’s own. The open question, and the one this post answers, is whether your build needs a custom app alongside the Webflow site. For many teams it does not.

What Webflow ships for Astro

Webflow Cloud is Webflow’s serverless platform for full-stack apps. You connect a GitHub repo, deploy, and run the app standalone or attached to an existing Webflow site.

The product page’s own FAQ names Astro twice in a single answer, and the answer opens with a plain yes.

Yes, you can deploy Next.js and Astro full-stack applications directly on Webflow Cloud.

Its developer docs go further, with a dedicated framework compatibility page stating that “Astro 6 and Astro 7 are supported.”

Version pinning is handled for you. Webflow Cloud reads your Astro version from package.json and installs the matching adapter, @astrojs/cloudflare 14.x for Astro 7 and 13.x for Astro 6, with Node.js 22.12 as the minimum for both.

Those versions were checked in September 2026, and Webflow Cloud is a fast-moving subject, so confirm the current tables in Webflow’s docs and on Webflow’s pricing page before you pin versions or budget usage.

Five official example repos back the docs, from a bare Astro 7 starter to apps with SQLite, KV, and object storage wired up, to a site-attached app with DevLink components exported.

Underneath, this is Cloudflare. Webflow’s own FAQ says the platform is “powered by Cloudflare Workers,” and its help center names the storage layer outright as D1 for relational data, R2 for assets, and KV for fast lookups. That explains the framework list. Next.js, Astro, and Vite match Cloudflare’s adapter ecosystem because Cloudflare’s runtime is what your app actually runs on.

Astro’s docs do not cover Webflow

Now run the same check from Astro’s side. A search for “webflow” in Astro’s integrations directory returns zero results, and the headless CMS guide lists dozens of platforms without it.

Read that as an absence of documentation rather than a statement of incompatibility. Astro’s CMS guide is community-written and says so itself: “many of these pages are stubs.” Nobody has contributed the Webflow page yet.

In practice, the reference material for this hybrid lives on Webflow’s side of the seam. When something breaks, Webflow’s developer docs are the manual, and Astro’s docs will not mention the other half of your stack.

Two ways to read the Webflow CMS

A hybrid’s one recurring job is getting Webflow CMS content into the Astro app. Webflow exposes two read paths, and choosing between them is your caching design.

The first is the Data API at api.webflow.com. It always returns current data and is rate-limited by plan, at 60 requests per minute on Starter and Basic and 120 on CMS, eCommerce, and Business.

curl --request GET \
     --url https://api.webflow.com/v2/collections/:collection_id/items \
     --header 'accept: application/json' \
     --header 'authorization: Bearer YOUR_TOKEN'

The second is the Content Delivery API. It mirrors the Data API’s live collection-item reads on a second host, api-cdn.webflow.com, with responses cached for 300 seconds on most plans and 120 on Enterprise. Cached calls carry a different budget entirely, and Webflow’s docs put it in one line.

there are effectively no rate limits for cached calls to the Content Delivery API.

So the routing rule follows from that. Static builds and background syncs read the CDN host, and the rare must-be-current read goes to origin. A read-heavy content site can sidestep rate limits almost completely that way.

Staleness is the price, because a CMS edit can take up to five minutes to reach the cached path. Webhooks close that gap. Events fire for Collection Item Created, Updated, Deleted, Published, and Unpublished, POSTed to a URL you host with a timestamp and signature header. Trigger a rebuild or invalidate your cache on receipt, and content stays current without polling.

That receiver is what keeps a hybrid from going stale, and it is also new infrastructure, since you now run a service with its own failure modes.

Webflow’s docs even show the wiring from inside an Astro app, with the Data API token as a runtime secret.

// src/pages/api/posts.ts, adapted from Webflow's framework docs
import type { APIRoute } from 'astro'

export const GET: APIRoute = async ({ locals }) => {
  const siteId = locals.runtime.env.WEBFLOW_SITE_ID
  const token = locals.runtime.env.WEBFLOW_API_TOKEN
  // fetch collection items with the token, then render or return them
}

DevLink is paid and labeled early-access

DevLink is the piece that syncs design. It exports Webflow-built components as React components, so the app can reuse the marketing site’s design system, and in an Astro app each exported component mounts as a React island.

Two facts belong next to that. First, DevLink requires a paid plan, meaning a paid Workspace plan or a CMS, Business, or Ecommerce Site plan. Webflow Cloud itself, by contrast, is included on every Site plan, free Starter included.

Second, Webflow’s own site navigation labels DevLink “LABS.” That is the vendor flagging its own feature as early-access. A build that treats design-system sync as a hard dependency is betting on a product Webflow itself has not called stable.

What the hybrid costs to run

Everything above describes what the hybrid buys. Running one also has a price, and most of it is paid in maintenance rather than dollars.

You now maintain an API contract between the Webflow CMS and the Astro app. A renamed field in a Webflow Collection is a breaking change in an Astro template, and no type checker spans the seam.

You maintain a version stack made of an Astro major, the adapter Webflow Cloud pairs with it, and a Node floor. All three move, and the pairing table is Webflow’s to change.

You run a build step and a second deploy target. The marketing site publishes from the Webflow Designer while the app deploys from GitHub, so a launch has two pipelines and two places it can fail.

You host a webhook receiver if you want same-minute content updates, or you accept up to five minutes of staleness if you do not.

The runtime also has hard ceilings. Webflow Cloud replaces every response’s Cache-Control header with private, no-cache, and its own docs state that it “overrides custom cache headers from your application.” If the reason you wanted Astro was CDN-cached static pages, that single header takes the strategy off the table. The Cloudflare Workers runtime underneath has fixed limits of its own, at 30 seconds of CPU per request, 128 MB of memory, and a 10 MB bundle.

Budget behavior is fixed too. If app usage exceeds your site plan’s limits for two consecutive months, Webflow upgrades the plan automatically to match. That is predictable under stable traffic and a surprise under a spike.

When Webflow on its own is the better build

Set the architecture aside and ask what the site does and who edits it. Those two answers make most of this decision, and for most marketing sites they point to Webflow on its own.

A Webflow-only build gives the client a site they run themselves. Every page, image, and blog post is edited in the Webflow Designer or the Webflow CMS, with no developer in the loop and no Git workflow to learn. Hosting, caching, image optimization, a CDN, and the sitemap are part of the platform, so there is nothing to patch, nothing to deploy, and one bill.

A Webflow-only site also skips the maintenance that comes with adding an app. Every item in the running-costs list above, the deploy pipeline, the version pinning, the API contract between the CMS and the app, and the webhook receiver, exists because there is custom application code to keep in step with the site. With no app, none of that exists. The site is edited, published, and hosted in Webflow, and that is the whole job.

The hybrid earns its place when there is an app in the build. An authenticated dashboard, a booking engine, a pricing calculator, or a service with its own API cannot be built with Webflow’s visual editor alone. That kind of feature needs application code running on a server, which is what Webflow Cloud provides.

In that setup, each part of the site runs on the tool built for it. The marketing pages stay in Webflow, where the client can edit them without a developer. The app is built in Astro and hosted on Webflow Cloud, which Webflow officially supports, and it reads content from the same Webflow CMS the marketing site uses, so nothing is entered twice.

If there is no app on the roadmap today, a Webflow-only site is the complete answer, not a compromise. The hybrid can be added later without rebuilding anything, because the marketing site stays exactly where it is.

One domain for the site and the app

For the businesses that do have an app in the build, there is one benefit of the hybrid that is easy to miss, and it has nothing to do with frameworks. Webflow Cloud attaches the app to the existing site at a path you choose, so the booking engine lives at yourbusiness.com/book rather than on a separate subdomain like app.yourbusiness.com.

That difference matters more than it looks. A subdomain reads as a separate property, to visitors and to search engines. Customers see a second address that may not look like the brand they came from, and Google and Bing treat the subdomain as its own site, so the links it earns, the traffic it draws, and the pages it adds build up a separate record instead of strengthening the main one.

Running the app under the main domain keeps everything in one place. The customer stays on one site with one brand from the first page to the last, and every page the app generates counts as part of that site.

The traffic, the links, and the regular updates the app produces all accrue to the domain your marketing site already ranks on, which is one of the signals search engines use to judge whether a site is active and worth sending visitors to.

Choosing to run the app under the same domain as the marketing site is what makes that possible. The two halves work together instead of competing for attention, and everything the app earns adds to the site the business already has.

Building both halves

We build both halves of this architecture. Our Webflow sites are built so the clients who own them can edit every page themselves, and our Astro builds handle the custom features and the performance-critical work that a visual editor cannot. The site you are reading this post on is one of those Astro builds.

When a project needs both, our web design service settles that boundary before anything gets built. We decide which pages the client will edit in the Webflow Designer, which features the app owns, and how the app pulls content from the Webflow CMS, whether through the cached Content Delivery API or the always-current Data API.

Get in touch if you are weighing the hybrid for a Houston site. What the site needs to do beyond rendering pages usually decides whether you need it at all, before any framework talk starts.

Frequently asked questions

Does Webflow officially support Astro?

Yes. Webflow Cloud supports Astro 6 and Astro 7, reads the version from package.json, and installs the matching @astrojs/cloudflare adapter itself. Webflow names Astro in its own FAQ, maintains a framework compatibility page, and publishes official Astro example repos.

Does Astro document Webflow as a CMS?

No. Astro’s integrations directory returns zero results for Webflow, and its community-written headless CMS guide does not include it. That is missing documentation, not incompatibility. The hybrid’s official support and reference material come from Webflow’s side.

How does an Astro site read Webflow CMS content?

Through two paths. The Data API always returns current data and is rate-limited by plan. The Content Delivery API at api-cdn.webflow.com serves cached reads with effectively no rate limits, at the cost of up to five minutes of staleness. Webhooks signal CMS changes either way.

When is the Astro and Webflow hybrid not worth it?

When the site is a marketing site the client edits themselves. That build belongs in Webflow alone. The hybrid adds a build step, a second deploy target, version pinning, and an API contract between the CMS and the app. It pays off only when the build includes real app functionality.