# BuilderIO/builder: a visual editing layer for React, Vue, Svelte and Qwik apps

> Builder.io connects a hosted visual editor to your existing components, so marketing pages can be edited without a redeploy. This is what the repository actually contains, how the SDKs install, and where the approach stops being the right call.

**BuilderIO/builder** — Visual Development for React, Vue, Svelte, Qwik, and more

- Repository: https://github.com/BuilderIO/builder
- Website: https://builder.io
- Stars: 8,858 · Forks: 1,164
- Language: TypeScript
- License: MIT
- Published: 2026-09-21 · Updated: 2026-09-21 · Language: en
- Canonical page: https://hysenlabs.com/projects/builderio-builder

## The problem BuilderIO/builder addresses: editing components without handing over the codebase

Most marketing pages on a component-based site are built from the same primitives as the rest of the app: a hero, a pricing table, a feature grid. Changing the copy or reordering blocks means a pull request, a review and a deploy. Builder.io's answer is to keep the components where they are and attach a visual editor on top, so the person editing sees the real component rather than an approximation of it. The README states the platform "connects to your existing site or app, so you can visually edit and generate code using your existing components", and mentions Figma designs or the drag-and-drop editor as the two entry points, with publishing through the SDKs.

The audience is therefore a specific one: product and marketing teams on a React, Vue, Svelte, Qwik or Angular codebase, where the components already exist and a design system is in place. It is not aimed at someone starting from nothing. If you have no component library, the visual editor has nothing meaningful to drag.

## What is actually inside the BuilderIO/builder repository

This repository is not the editor. It is a monorepo of the client-side pieces: SDKs under packages, runnable examples under examples, starter projects under starters, and plugins under plugins. The root package.json declares Yarn workspaces covering packages, packages/sdks, packages/react, packages/core, packages/sdks-tests, packages/sdks/e2e/* and packages/sdks/snippets/*, and requires Yarn 3 or newer through the engines field, with packageManager pinned to yarn@3.6.1. Nx is the task runner, and Changesets handles versioning.

The examples directory is the most useful part for evaluating fit, because the framework coverage is visible in the folder names: next-js, next-js-app-router, nextjs-app-dir-v2, nextjs-pages-dir-v2, gatsby, gatsby-minimal-starter, qwik, astro-solidjs, angular-gen1, angular-gen2, angular-universal, node-express, plain-js, material-ui, next-js-localized, next-js-on-demand-isr, next-js-headless-shopify and next-js-cms-blog among others. Two things follow from that layout. First, the framework support is broad but uneven in depth: there are separate "gen1" and "gen2" Angular examples, and a directory named next-js-sdk-gen-2-experimental-app-directory, which tells you the Next.js App Router story has moved through more than one generation. Second, the presence of next-js-headless-shopify and next-js-cms-blog suggests the intended use case is landing and content pages inside a larger application, not replacing the application.

## Installing an SDK and rendering your first Builder content

The README does not contain install commands. It points to the SDK list at builder.io/c/docs/developers and to signup for an account. The package names are visible in the repository: the root resolutions reference @builder.io/react and @builder.io/sdk as workspace packages, the README's badge links to the @builder.io/sdk npm page, and the recent releases list @builder.io/sdk-vue, @builder.io/sdk-svelte and @builder.io/sdk-solid at 5.2.12. So the install is a normal package install of the SDK matching your framework, not a clone of this repository.

The repository does not spell out the install command in prose, but the root package.json declares the published package names through its resolutions block, where @builder.io/react and @builder.io/sdk are both pinned to workspace:*. In your own application, that corresponds to installing the published package by name.

```bash
npm install @builder.io/react
```

After installing, the general shape of integration is: register the components you want exposed to the editor, then render Builder content in a route. The README does not give the registration API, so treat the exact call as something to confirm against the framework example that matches your stack before writing code. The examples directory is the reference to open first, for instance examples/next-js-simple for a minimal Next.js setup or examples/qwik for Qwik.

Working inside this repository instead means using the scripts the root package.json declares. The g:nx script changes into INIT_CWD and runs nx, and Nx is a devDependency, so a local build starts with the Yarn 3 workspace installed.

```bash
yarn install
```

```bash
yarn g:nx
```

The first command installs the Yarn 3 workspace; the second runs the g:nx script, which delegates to nx from the current working directory. The README does not list per-package Nx target names, so check each package's own configuration before relying on a target name. If you only want to use the SDK in your own app, skip the clone entirely.

## Where the SDK approach becomes a constraint

The SDKs are clients. The visual editor, the content storage and the publishing pipeline live on Builder.io's hosted platform, which is why the README's "Try it out" step is signing up for an account rather than starting a container. That is the central trade-off and it is worth stating plainly: this repository is MIT licensed, but the thing that makes it useful is a service. Teams with a hard requirement that content authoring run entirely on their own infrastructure will not find that here, regardless of the licence on the code.

There is a second, quieter cost. Registering components means every component you expose becomes part of an interface that non-engineers can rearrange. A component with required props that only make sense in one context, or one that assumes a specific parent, will produce broken pages when it is dropped somewhere unexpected. The examples folder shows the intended pattern of small, self-contained, presentational components; the further your codebase is from that, the more work the integration becomes. Finally, the versioning picture is spread across many packages. The recent releases show sdk-vue, sdk-svelte and sdk-solid moving together at 5.2.12, but a monorepo with this many published packages means you should check the version of the specific SDK you install rather than assuming one number applies across frameworks.

## Builder.io compared with a headless CMS plus a component library

The obvious alternative is a headless CMS that returns structured content, combined with your own components rendering that content in code. The difference in approach is where the layout decision lives. A headless CMS typically stores fields: a title, a body, an image URL, a list of items. Your code decides how those fields are arranged, and an editor cannot move a block from the left column to the right without a developer changing the template. Builder.io inverts that: the arrangement is part of the content, and the editor manipulates the layout directly against your registered components.

That inversion is the whole value proposition and also the source of its limits. A headless CMS gives you a stable schema that is easy to validate, migrate and query, and it does not care what your frontend looks like. Builder.io gives editors freedom over composition, which means the set of valid page states is much larger and correspondingly harder to reason about. If your content is mostly articles, product records or documentation, where the shape is fixed and the variability is in the text, a schema-first CMS is the better fit. If your content is landing pages, campaign pages and one-off layouts built from a known component set, the visual approach removes a real bottleneck.

## Maintenance, release cadence and what the MIT licence does and does not cover

The repository is not archived, and the last push was on 2026-09-21. The recent releases listed are all dated 2026-09-18: @builder.io/sdk-vue@5.2.12, @builder.io/sdk-svelte@5.2.12 and @builder.io/sdk-solid@5.2.12. The repository is a Yarn 3 workspace driven by Nx and Changesets, which is a normal setup for a multi-package TypeScript monorepo and means upgrades arrive as per-package versions rather than one repository-wide release.

Upgrade cost depends on which SDK you use. A Vue, Svelte or Solid user tracking the 5.x line has a single package to bump. A React user has both @builder.io/react and @builder.io/sdk in play, and the root resolutions pin both to workspace:*, which is a monorepo-internal mechanism and not something that applies to your app. The root package.json also carries a resolutions block pinning tar-fs, minimist and json5 to specific versions; those are dependency overrides for this repository's own build, not guidance for consumers.

The licence is MIT, stated in both the LICENSE file and the package.json license field. MIT covers the code in this repository: you can use, modify and redistribute it. It does not grant you anything with respect to the hosted Builder.io service, which is governed by separate terms. That distinction matters for procurement conversations, and it is not a legal opinion; read the actual terms before committing.

## Conclusion

Adopt it when a non-engineer needs to edit pages that are built from components your team already owns, and you accept that the editor itself is a hosted service rather than something in this repository. Do not adopt it if you need an entirely self-hosted page builder, or if you expect a drop-in CMS for content models and editorial workflows. Verify first that the SDK for your framework is published at the version you need, that the registration path for your component library is documented for your framework, and that your team is comfortable with the platform dependency the SDKs imply. The repository itself is MIT licensed, but the licence covers the code here, not the hosted editing experience the code talks to.

## FAQ

### How do I install BuilderIO/builder?

You do not install the repository itself for normal use. You install the SDK for your framework, for example npm install @builder.io/react, and the README points to builder.io/c/docs/developers for the SDK list. The repository is cloned only if you intend to work on the SDKs, which requires Yarn 3.

### Is BuilderIO/builder open source and self-hostable?

The repository is MIT licensed, so the SDK code can be used and modified freely. The visual editor and content platform are hosted at builder.io, and the README's getting-started step is signing up for an account rather than running a server. The licence does not extend to that hosted service.

### Which frameworks does BuilderIO/builder support?

The repository's examples directory includes Next.js, Gatsby, Qwik, Astro with Solid, Angular (gen1 and gen2), Node/Express and plain JavaScript, and the recent releases list Vue, Svelte and Solid SDKs at version 5.2.12. The README describes the platform as visual development on any stack.

## Sources

- [BuilderIO/builder on GitHub](https://github.com/BuilderIO/builder)
- [License: MIT](https://github.com/BuilderIO/builder/blob/main/LICENSE)
- [Project website](https://builder.io)
- [README](https://github.com/BuilderIO/builder/blob/main/README.md)
- [Releases](https://github.com/BuilderIO/builder/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/builderio-builder