The web builder's version table is its most honest documentation

The backend is a content system, not a data layer

Most drag-and-drop builders assume a content management system of their own and store your data inside it. This one inverts that.

The backend is a general-purpose content management system used headless, and the project describes itself as the first open source low-code platform built this way in its home market. The builder reads the backend through its JSON API and its view system, and the view system is described as the mechanism for flexibly configuring dynamic components and dynamic endpoints.

That choice shows up in the dependency list, which is unusual for a front-end project. There is a library for querying that JSON API, and authentication is delegated to the backend's own OAuth module rather than implemented here.

The stated advantage of the arrangement is that components and data sources are configured where you would already configure them. The stated cost is implicit: you now depend on a content system, its view layer and its authentication, not just on the builder.

The editor itself is a separate product with a Pro tier for generating interfaces, pages and tool applications with a model, so the free tier is the visual builder and the AI work sits above it.

The naming has an origin worth knowing: the product is named after the first known interstellar object to pass through the solar system, a term that means a distant messenger.

Nine versions of framework requirements, tabulated

There is a compatibility table, and it is more useful than anything else in the readme.

It lists the builder's own major versions against the framework major, the runtime major and the language minor it needs, running from the fourth release through the twelfth. The current line needs the twentieth framework major, a runtime of twenty-two or newer, and the language at five point eight or newer.

What the table makes obvious is the shape of the maintenance. Early versions are pinned to much older combinations and are effectively frozen: version four and below sit on a framework two major versions behind and an early language four. Each major bump moves the framework and usually the language together, and the runtime moved twice, once for the eighteenth major and once for the twentieth.

The current package manifest encodes the same requirement more precisely, pinning specific patch floors across three runtime majors rather than a single range, and requiring a minimum package manager version.

So the answer to which line you should be on is unambiguous: the newest one, because the older ones are pinned to runtimes long out of support. The table exists because people arrive at the repository through search and land on documentation for a version they are not running.

That is a courtesy most projects skip, and on this repository it is the single most useful page.

The install is strict, and the container is not

The installation guidance is unusually emphatic, and it is worth reading closely because the container build contradicts it.

The instruction is to use the default package manager with a lockfile, explicitly warning that there are many dependencies so you should wait, and stating that using the other two popular package managers will produce errors. The reason given is strict lockfile version pinning.

Then look at the container build. It uses the legacy peer dependency flag during install, which is precisely the escape hatch for dependency conflicts that a strictly pinned tree would not need.

So the two paths through this repository have different policies. A developer working locally is told to install exactly what the lockfile says. Someone building the image is told to let the installer resolve peer conflicts.

Both are defensible in isolation. A large tree with a strict lockfile will hit peer conflicts on an older package manager, which is why the flag exists, and the container build is run on a recent runtime so it mostly works. But the documentation does not acknowledge the tension, and someone who follows the strict instruction and then hits a peer conflict has no guidance other than the container file to go on.

One other thing worth knowing before running it: the development server proxies its API calls to a hosted backend automatically, so a local instance is talking to someone else's service unless you change the proxy configuration.

The current line drops zone-based change detection

The front end is on the twentieth framework major, and the stack list names the specific modern features rather than the version numbers.

Standalone components. The signal-based change detection model. Zoneless change detection, which is the notable one. And incremental hydration, which is what makes server rendering fast rather than shipping everything on first paint.

Zoneless in particular is a meaningful choice for a builder that manipulates large component trees constantly during a drag operation. Zone-based detection works by patching the browser's async APIs and letting a global tick tell the framework something changed, which is convenient until you have a lot of churn.

The rest of the stack is a broad component catalogue, and the selection tells you what the builder is expected to produce. A form library for dynamic forms, a charting library, a video player, a calendar suite with several view modes, and three editors: a rich text editor, a JSON editor, and the Monaco editor, which is what makes JSON editing a first-class feature rather than a text field.

There is also a loading bar wired to both the HTTP client and the router, an internationalisation package, a Chinese map provider loader, and a set of utility libraries.

The published container exposes a port in the four-thousands and starts the server-rendered output rather than a static file server, which is consistent with the SSR entry point in the build configuration.

Page history is created by the operations that overwrite

The versioning feature is defined in terms of which operations trigger it, rather than as a general save-history model.

A new history version is created when an operation overwrites existing content: submitting, clearing, or loading an example. That is a narrower definition than most people expect from undo, and it means the history captures destructive replacements rather than every incremental edit.

Alongside it there is a draft detection feature: when what you are looking at is behind what is saved, it prompts you to pull the latest.

Those two together are a concurrency story rather than an editing story. The builder is assumed to be usable by more than one person against the same page, and the design responds to last-writer-wins rather than trying to merge.

The rest of the feature list is mostly about getting content out of the editor and into a system. You can copy a component's JSON, or copy a whole page's JSON and deploy it to the backend to publish, which is the bridge between the visual editor and the headless content system underneath.

There is a media library you can upload to, view and update from the interface, a template and example library to generate pages from, and a rule-based page generator that builds a page from the component library.

Preview is unusually thorough: a new window showing the real page, device-size switching for checking the responsive layout, a multi-theme preview, and a full-width toggle for editing on a large screen without the surrounding interface getting in the way.

The skills package targets Storybook and one specific image model

There is a separate skills repository, and it is a Claude Code skill pack rather than a plugin or a command.

Three skills, each scoped to one job.

The first creates and optimises interface components in Storybook, and generates both the stories and a document of AI prompts alongside them. Storybook is a deliberate choice here: the builder's component library is where a visual change should be made and demonstrated, and producing a story is how you show a change in isolation rather than in a page.

The second translates the visible copy inside a page or component's JSON, and adds the matching language prefix to internal links as it goes. That second half is the part that matters. Translating strings is easy; translating a site means every relative link has to resolve in the target locale too, and forgetting that produces a page that reads correctly and navigates wrongly.

The third generates image prompts in Chinese for page components, and it targets one specific image model by name, with support for several styles and aspect ratios. Targeting a named model rather than a generic interface suggests the prompt format is tuned to that model's behaviour.

So the pack covers the three places a builder project actually needs help: making a component, translating the result, and filling the images. Nothing about wiring the backend.

Three test runners, and a pre-commit that formats your work

Testing is split across three runners, and the split is by source directory rather than by test type.

The default command runs the unit tests under the main source tree and deliberately excludes the server directory. A separate command runs the server tests, through a different configuration file at the repository root. End-to-end tests are a third runner, with an interactive mode for driving them in a browser.

The split exists because the server code runs in a different environment from the browser code, and putting them in one runner would mean one of the two runs with the wrong configuration.

Linting is a fourth command, on the current flat configuration format. There is also a dependency checker that reports packages declared but never imported, which is worth having in a tree this wide.

The commit hook is the part that will affect you most as a contributor. It runs on commit and fixes your files for you: linting and auto-fixing script and template files, and formatting markdown. The flag used means your changes are not stashed first, so what gets committed is what you have on disk rather than a temporary index.

There is a separate configuration file for continuous integration analysis, and three separate TypeScript configurations for the application, the base project and the specs.

Editorial conclusion

This suits someone already invested in that content system, since the builder's distinguishing feature is that it renders from the same views and JSON API the backend already exposes rather than inventing a parallel data layer. It suits you less if you want a self-contained tool, because you are adopting a content management framework along with a builder. Before starting, read the version table and install notes together, because the strict lockfile instruction and the legacy peer dependency flag in the container build are a real inconsistency, and check the copyleft licence if you plan to host anything client-facing.

Frequently asked questions

Official sources

1. biaogebusy/web-builder on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases