Webflow DevLink, code components, and Webflow Cloud: when adding React beats a rebuild.

How does Webflow DevLink work in 2026?

Webflow calls DevLink "the interface between external codebases and Webflow." Each part handles a different step between design and development, and each has its own status and plan rules.

Two caveats. Webflow has been merging its CMS and Business site plans into one Premium plan since May 2026, and its pricing page lists code components under Premium; our post on the Webflow price increase covers the dates. And Webflow's React page still says "The component export feature is currently in beta," despite the May 2026 announcement.

Older tutorials describe DevLink as export-only and tell you to run "webflow devlink sync". Since September 2025, code components bring React into Webflow too, and Webflow replaced the sync command with "webflow devlink export" in May 2026; CLI v2.9.0 removed the old command on September 24, 2026.

What can React code components do on a marketing website?

Code components let you use React components in Webflow. Developers create a component in React, run "webflow devlink import" from the Webflow CLI, and share the library. Once it's installed from the Libraries panel, designers and marketers place code components like any other component and edit their props and slots, including binding props to CMS fields. Good fits are interactive pieces, for example a pricing calculator, an ROI estimator, or a product tour.

Limitations designers and developers should both know:

• Rendering. "Webflow supports server-side rendering (SSR) for code components," and it's on by default. Developers turn it off for components that use browser-only APIs such as window or localStorage, which then render only in the browser. React Server Components aren't supported.
• Isolation. Each component is its own React app with its own Shadow DOM, so components "can't share React Context or state directly." Site classes and global CSS don't apply inside a component; developers connect site variables and other styles explicitly.
• Data. "All API requests are executed in the browser," against public APIs that allow CORS, and .env files aren't supported. Keep secret keys out of components.
• Releases. "the entire library is deployed as one unit," code components "don't support versioning," and the bundle limit is 50 MB. It's React only.
• Updates. Only a Workspace admin, owner, or Designer can review and accept library updates.

AI code components work differently. You describe the component, the AI Assistant builds it, and Site managers and Designers can refine it by prompt, in the Style panel, or in code; Marketers and Content editors can only view it. Webflow lists "No CMS data integration," and AI code components can't be exported to a codebase through DevLink.

When should you export Webflow components to a React project?

When a React application, such as your product or docs site, should reuse the marketing website's design system. DevLink Export turns "native Webflow components" into React components, with global styles, variables, fonts, and component classes. Webflow designers keep the design in Webflow, and development teams get React code, so the product stays on-brand without rebuilding components by hand.

From the root of your React project, a developer runs "webflow devlink export," and the CLI writes "every component into a ./webflow folder." After design changes, they "run the export again to refresh them in your React project," and the rest of the app's code is left untouched. "DevLink exports Components only, not every element on the canvas," so anything else has to become a component first.

Limitations to know:

• Components with bound CMS content "won't export fully," and Collection Lists export as "unsupported element placeholders."
• Component-scoped interactions export; page-level IX3 interactions don't.
• Webflow's Help Center says "Only Site Admins and Designers" can use it, while its developer docs ask for Site Admin or Owner permissions.

Webflow recommends deploying the exported project on Webflow Cloud. DevLink Export isn't Webflow's code export, which downloads a static copy of the site; our post on Webflow export code covers that one.

What is Webflow Cloud for?

For the parts of a site that need a server. Webflow says its hosting "excels at delivering static sites and CMS-driven content," and Cloud is for "experiences that require backend processing, API integrations, and dynamic content generation."

A Webflow Cloud app is a project built with a framework such as Next.js 15, Astro 5, or Vite, deployed from GitHub with one environment per branch. It runs on Cloudflare Workers and mounts at a path on your site, such as /app; if a Cloud route and a Webflow page collide, the Cloud app wins. Since June 2026, an app doesn't need a Webflow site attached. Cloud projects can use SQLite, key-value, and object storage, and they can read published CMS content through Webflow's Content Delivery APIs.

Bandwidth is pooled with the site's bandwidth, and usage above the allowance is billed. Watch the plan change: Webflow's own migration notes say former Business sites go from "10M to 2M/month" requests on Premium. Each request also has runtime limits, including 30 seconds of CPU time, 128 MB of memory, and a 20-second timeout, and Cloud only "partially supports Node.js APIs."

When should you use DevLink instead of a full rebuild?

When you need one feature, not a new stack. That's when a hybrid build beats a rebuild. Our headless CMS agency page says the same: "A Webflow Cloud app or a React code component adds it to the site you already have." We recommend a headless build when two or more of these are true: pages come from product data, many pages need web app features, engineers want ownership, you've hit platform limits, or you want to build with coding agents.

Our Webflow vs custom code guide covers the full-rebuild decision, and our custom websites and migrations page covers how a rebuild keeps rankings.

How do React components affect SEO and page speed?

It depends on where the HTML is made. Webflow says "SSR generates initial HTML for the component on the server, which can improve perceived performance and SEO," so keep SSR on for anything you want indexed. With SSR off, a component renders only in the browser. React added through custom code embeds is worse for search: Webflow says that content "is absent from the initial server-returned HTML," and its built-in SEO tools "have no visibility into React-rendered output."

Google's guidance points the same way. Server-side or pre-rendering "is still a great idea," and "not all bots can run JavaScript." So Webflow's HTML advantage, covered in is Webflow good for SEO, holds for code components with SSR on, not for browser-only ones.

For speed, Webflow says code component bundles got "up to 75% smaller" in December 2025, but we found no Webflow figure for what a component adds to a page. Before a component reaches production, test a page with and without it against the Core Web Vitals thresholds: LCP of 2.5 seconds or less, INP of 200 ms or less, and CLS of 0.1 or less.

We build Webflow and headless sites for B2B SaaS companies, so we have an interest in this topic.

Questions about Webflow DevLink