Builder.io: Fusion vs Publish, Features, and Setup

Direct answer

Builder.io is a visual development platform with two main products. Fusion is a visual IDE for generating and editing real code against repositories, design systems, branches, and pull requests. Publish is a visual CMS for creating pages, sections, and structured data that an existing site or app renders. Choose Fusion for product-code changes, Publish for managed content, or both when new components and editable content need one governed workflow.

Open the official Builder.io platform and choose Fusion or Publish for the job you need.

Summary

Fusion: connects to a repository, learns code and design-system patterns, supports visual or prompted changes, and delivers branches and pull requests.
Publish: connects a visual editor and content models to an existing application so editors can manage pages, sections, and structured data.
Hosting: Publish content is delivered to the application, while the team continues to control the site, code, and hosting.
Guardrails: registered components, roles, environments, review, tests, previews, and normal deployment controls determine how safely non-engineers can contribute.
Best fit: an established product or marketing site with a component system and repeated work split across engineering, design, product, and content.
Poor fit: a simple hosted site, an ungoverned AI build, or a team that cannot maintain the integration and review generated or visual changes.

Choose between two connected products

The current pricing and documentation split Builder.io into Fusion spaces and Publish spaces. A space organizes the relevant projects, users, code, content, models, and usage for one product. This distinction should drive the evaluation, contract, access model, and implementation plan.

Use Fusion when the intended output is a code change that belongs in a repository and must pass normal engineering review.
Use Publish when the intended output is content or composition that should change without editing application source for every update.
Use both when Fusion creates or changes governed components and Publish exposes approved properties for content teams to use.
Use neither until the team can name the source of truth, owner, access boundary, review gate, deployment path, and rollback for each change type.

Confirm the Fusion and Publish distinction in the official pricing FAQ.

What Builder Fusion does

Fusion is an AI-powered visual development environment for teams with existing codebases. Builder documents connections to repository providers, additional design-system repositories, visual editing, prompts, Figma import, branches, previews, peer review, and pull requests. The intended result is code that follows the team's stack and existing Git workflow.

Connect a disposable or test repository first. Define the default branch, protected branches, allowed repositories, and credentials before inviting a wider team.
Index the relevant application and design-system context. Remove secrets, generated files, unrelated repositories, and stale rules from the evaluation scope.
Start from a small prompt, selected issue, Figma design, or branch from another supported coding agent.
Inspect the generated code and visual output together. Confirm component reuse, tokens, types, state, data flow, responsive behavior, and accessibility.
Use a branch and pull request for the final change. Run the repository's tests, type checks, linting, build, security checks, and visual review outside Fusion.
Require a code owner to approve the diff and deployment. Record defects, review time, changed lines, agent credits, and rollback effort.

The platform also describes an MCP workflow that can move branches between Fusion and tools such as Claude Code, Cursor, or Codex. Treat every handoff as a source-control event. Confirm the repository, branch, commit, working tree, pending changes, and next owner rather than assuming two interfaces show identical state.

Read the official Fusion overview, repository, design-system, visual-editing, and pull-request workflow.

What Builder Publish does

Publish is Builder.io's visual CMS. The team integrates selected content models and the Builder SDK or API into an existing application. Editors then use a Visual Editor to arrange approved blocks, edit content, set data, preview responsive behavior, collaborate, and publish or schedule entries.

Visual Pages: Builder manages the page area between the application's existing header and footer, often for landing and marketing pages.
Visual Sections: Builder manages a selected part of a page or application, such as a hero, promotion, product editorial, or cart upsell.
Structured Data: Builder stores modeled data such as navigation links, product information, or author records for the application to render.
Custom components: developers register owned components so editors work with approved behavior and properties rather than arbitrary production code.

Publish is not simply a separate hosted copy of the whole website. Builder's documentation says the application remains where the team hosts it, and Builder passes managed content to that site or app. The team retains responsibility for integration, application code, frontend behavior, analytics, SEO, core flows, hosting, performance, and deployment.

Review the official Publish concepts, Pages, Sections, Data, integration, and hosting boundary.

The Visual Editor is shared, but outcomes differ

The Visual Editor is the central interface for both products. Its tabs can support AI generation, block insertion, layers, styling, data, options, and comments. The final action depends on the space. Publish sends content live or schedules it. Fusion shares a preview or submits a pull request for a code update.

A visual control does not remove engineering or design constraints. A component can still expose unsafe options, create invalid combinations, break at a smaller width, harm performance, lose semantic structure, or contradict the design system. Register fewer high-quality components with clear property names, defaults, validation, and previews.

Open the Visual Editor guide and compare the Publish and Fusion final actions.

Design the component contract before editor access

The quality of Publish depends heavily on what developers register. Registered components remain in the codebase while Builder makes them available as visual blocks. Treat registration as a public authoring API for the content team.

Expose content decisions, not internal implementation details. Prefer Label, Tone, and Destination over raw class names or unbounded style objects.
Provide safe defaults and validation. Define which properties are required, optional, constrained, localized, responsive, or hidden from editors.
Preserve semantics. A heading level, link destination, form label, image alternative, and button action need rules that visual styling cannot replace.
Limit layout freedom where inconsistency would damage the brand, accessibility, performance, or responsive behavior.
Document every component with purpose, examples, forbidden combinations, content limits, data needs, ownership, and deprecation path.
Version changes carefully. An altered component contract can affect many existing content entries after deployment.

Check the custom-component registration requirements and framework limits.

How Fusion and Publish work together

The official guide documents a Fusion for Publish flow for new custom components. A team identifies the missing component and prototypes it on a Fusion branch. It registers editable properties and previews the branch inside a Publish test entry. An engineer then reviews and deploys the pull request. Only after deployment should normal Publish content depend on the component.

A previewed component does not yet exist in production. Builder explicitly warns against publishing entries that use it before the component is merged and deployed. After deployment, restore the Publish preview to the normal production URL and verify the entry again.

Follow the documented Fusion for Publish handoff and deployment sequence.

Run a controlled Builder.io evaluation

Choose one repeated bottleneck: a landing-page update, a registered hero variation, a Figma-to-component task, or a small existing feature.
Record the baseline: people involved, handoffs, elapsed time, engineering time, defects, review time, deployment steps, and current tool costs.
Select Fusion, Publish, or both based on whether the source of truth is code, content, or a component-plus-content contract.
Use a test space, test repository or branch, non-production data, least-privilege credentials, and a preview that cannot be mistaken for production.
Define acceptance criteria for content, brand, responsive behavior, accessibility, performance, security, tests, source control, and rollback.
Train each role on the exact decisions it owns. Restrict layout, code, model, environment, and publish access to people who need it.
Complete the workflow with real review and deployment gates. Do not count a visual preview or generated pull request as success by itself.
Compare the result with the baseline. Include integration maintenance, plan cost, agent credits, editor learning, support, and recovery effort.

Authoring: how quickly can the intended editor finish without help or escape the component rules?
Engineering: how much review, repair, integration, and upgrade work remains after generation or visual editing?
Quality: did the result pass content, accessibility, responsive, performance, security, browser, and automated checks?
Governance: can owners see who changed code or content, approve release, separate environments, and reverse a mistake?
Economics: does saved handoff time exceed subscriptions, seats, agent usage, implementation, training, support, and ongoing maintenance?

Match roles to real decisions

Publish documents standard Contributor, Editor, Designer, Developer, and Admin roles with increasing access. For example, a Contributor can change basic content but not rearrange layouts, while a Developer can edit code and models. Enterprise custom roles can add finer control, including publish requests and environment permissions.

Content authors should control approved copy and media without receiving code, model, billing, or broad layout authority.
Designers should adjust approved visual decisions without bypassing semantic, responsive, token, or accessibility rules.
Developers should own component contracts, code changes, data models, integrations, tests, and production readiness.
Release owners should control environment promotion and publication. Separate request, review, and approval where mistakes carry material risk.
Admins should manage access, billing, security, and spaces without using an all-powerful account for routine authoring.

Inspect the Publish role matrix before inviting editors or granting publish access.

Pricing needs a product and space decision

Subscriptions are organized by product space, users, features, and usage. The pricing page can present Fusion and Publish separately, so confirm the selected tab and billing period before comparing a quote. Do not apply a Fusion price or credit limit to Publish without checking.

On 11 August 2026, the monthly Fusion view showed Free at $0 per user and Pro at $24 per user. Team was $40 per user, while Enterprise used custom pricing. Free showed 60 monthly Agent Credits. Pro and Team showed 500 monthly credits. The page also listed different user limits, preview privacy, roles, training settings, support, repository providers, and enterprise controls.

Which product and how many spaces, projects, brands, sites, environments, repositories, and design systems are required?
How many people need each role, and does pricing count included seats, maximum users, or added seats differently?
Which activities consume Agent Credits, what resets or rolls over, and how do on-demand credits affect the monthly ceiling?
Are public previews acceptable, or does the team require password protection, privacy mode, private networking, or enterprise repository access?
Which support, onboarding, SLA, audit, SSO, training, data, security, and contract terms are required before production use?
What is the cost to migrate content or code, maintain SDKs and components, train authors, and exit the platform later?

Check the live Builder.io pricing page for the selected product, billing period, features, and limits.

Who should use Builder.io?

Choose Fusion when an existing product team wants visual and AI-assisted code work but must preserve repositories, components, branches, pull requests, and deployment controls.
Choose Publish when a content or marketing team repeatedly needs visual page composition on an existing application with developer-owned components and hosting.
Choose both when the team regularly creates new components and then hands safe, editable properties to content authors.
Consider a structured headless CMS when editorial modeling, workflows, and multichannel content matter more than free visual page composition.
Consider a hosted site builder when the team wants an all-in-one site and hosting experience without maintaining an application integration.
Keep the current code and CMS workflow when visual autonomy or AI generation does not offset integration, governance, usage, and maintenance costs.

Independent reviews commonly praise Builder.io's visual flexibility and component-based collaboration. They also report setup effort, learning curve, documentation friction, AI cleanup, responsive refinements, and cost concerns. These observations are useful evaluation questions, not universal outcomes. Reproduce them with your stack and team.

Compare broader prompt-to-app choices in our best AI app builder guide.

Frequently asked questions about Builder.io

It includes visual page-building capabilities, but its current platform is broader. Fusion changes repository code through a visual IDE and Git workflow. Publish adds visual CMS content to an existing site or application that the team hosts.

Publish documentation says the application remains on the team's hosting. The platform provides managed content to the integrated site or app. Confirm any separate preview, asset, infrastructure, or enterprise service in the current contract.

Fusion is designed to work with real codebases and pull requests, but generated code still needs repository-specific review and verification. Run the same tests, security checks, accessibility review, performance checks, and deployment gates as any human change.

The live pricing page showed a Fusion Free plan on 11 August 2026, with user and Agent Credit limits. Publish has its own product selection and may have different terms. Recheck the current product tab before relying on any price or limit.

Sources and verification

Official Fusion product and key-concept pages: repository, design-system, visual-editing, branch, review, MCP, and pull-request workflow.
Publish key concepts: Pages, Sections, Data, integration, site hosting, content models, spaces, entries, blocks, and responsive behavior.
Visual Editor and custom-component documentation: editor tabs, final actions, registration, SDK, code ownership, and framework limits.
Fusion for Publish guide: component prototype, registration, branch preview, engineering review, merge, deploy, and production verification sequence.
Roles, permissions, request-to-publish, environment, and enterprise pages: standard roles and plan-specific governance controls.
Pricing checked 11 August 2026: Fusion monthly prices, Agent Credits, users, previews, training settings, support, and product-space FAQ.
Independent current reviews from Gautam Khorana, G2, and All About AI: competitor coverage, reported strengths, friction, and evaluation questions; not proof of Builder claims.

Connect Better Design