Webstudio: an AGPL visual builder you can self-host, with a note on the animation package

The problem Webstudio targets: a visual editor that does not own your stack

Most visual site builders make an implicit trade. You get a fast canvas, and in exchange the page tree, the content and the hosting all live inside the vendor. Export is partial or absent, and the CMS is whatever the vendor ships. Webstudio is aimed at teams that want the canvas but not that trade. The README describes it as an "Open Source Visual Development Platform for developers, designers, and cross-functional teams" and states that you own the data, components, and infrastructure. It is for people who are already comfortable with a React and TypeScript toolchain and who want the marketing site to be part of the same deployment pipeline as the application. A design agency building client sites on its own Cloudflare account is the obvious fit. A solo user who wants a drag-and-drop page and never wants to see a terminal is not, and the install path below will make that clear quickly.

How the builder, the runtime and the data split apart

The repository is a pnpm monorepo, and the layout tells you more about the architecture than the README does. There are apps/ and packages/ directories, a codemod/ directory, a fixtures/ directory, and a vite.sdk-components.config.ts at the root. The root package.json declares "packageManager": "[email protected]" and a build script that runs recursively across every workspace package except the fixtures: pnpm -r --filter='!./fixtures/*' build. There is also a check:package-boundaries script, which implies the project enforces which packages may import from which, a real constraint if you plan to fork.

The scripts point at a generated-contract workflow. check:generated-api runs generate-runtime-operation-contracts in @webstudio-is/project-build and generate-server-only-api-metadata in @webstudio-is/builder, then verifies the generated files are clean. check:generated-docs does the same for docs.generated.ts in @webstudio-is/project-build and @webstudio-is/cli, and for docs/university/mcp.md. So the builder API surface and the documentation are generated artifacts kept in sync with source, not hand-written files. That is a meaningful design decision: the editor talks to the server through a typed operation contract, and the CLI and MCP documentation are derived from the same definitions. It also means a fork that changes the server API has to regenerate those files or the check scripts fail.

The presence of a docs:mcp:sync script and an MCP documentation file indicates the project exposes a Model Context Protocol surface. The README does not explain what an MCP client can do with it, and I would not assume more than the script names imply.

Installing Webstudio locally and starting the builder

The repository does not ship a one-line installer in the README. The install story is the monorepo itself: clone the repository, enable the pinned pnpm version, install, and run the dev script. The root package.json defines a webstudio script that runs node packages/cli/local.js, and a dev script that runs the builder in local mode. The CLI entry point is the closest thing to a documented local launch.

Start by installing dependencies with the pinned package manager. The packageManager field is [email protected], so use that version rather than whatever pnpm is on your PATH.

corepack enable
corepack prepare [email protected] --activate
pnpm install

Then start the builder in local mode. The dev script targets the @webstudio-is/builder package specifically, so it does not build the entire workspace first.

pnpm dev

If you would rather go through the CLI, the root exposes the same entry point directly. The README does not document what arguments this accepts, so treat it as the local launcher and read packages/cli for flags.

pnpm webstudio

What you should see is a locally served builder. What the README does not tell you is which database or storage the local mode expects, what port it binds, or what environment variables it reads. None of that is in the README, and the repository root does not list an .env.example. Expect to read apps/builder and packages/cli source before the first successful start. That is a real friction point, not a documentation gap you can paper over with a search.

The animation package is not AGPL, and that changes your options

The README's licence section is unusually direct and worth reading twice. It says the Webstudio core, meaning all functionality in the repository, is free and open source under AGPL-3.0-or-later. It then carves out one package: sdk-components-animation is proprietary, and you must accept the Webstudio, Inc. EULA located at packages/sdk-components-animation/LICENSE before using it.

This is the single most consequential fact for anyone evaluating Webstudio as infrastructure. A monorepo under AGPL-3.0-or-later with one proprietary optional package means the licence boundary is not the repository boundary. If your product embeds the builder and you distribute it, the AGPL network clause is the question your legal team will ask about, and the README does not answer it. If you only want the animation components, you are outside the open source grant entirely and inside a commercial EULA. The root also contains a submodules.sh script and a .gitmodules file, so at least part of the tree is pulled in as a submodule; whether the animation package is one of them is not stated in the README, and you should check before assuming a plain clone gives you everything.

Where Webstudio is the wrong tool

Webstudio is not a hosted CMS with a support contract and a status page. If the site goes down at 2am, the README's promise that you own the infrastructure cuts the other way: you are the on-call. Teams without anyone who can read a Cloudflare Workers configuration or a Postgres connection string should use the hosted version rather than self-hosting, or pick a managed builder.

The second limitation is the local development story. There is no documented docker compose file, no published image, and no environment variable reference in the README. The root does contain a .devcontainer/ directory, which suggests a container-based development path exists, but the README does not describe it and I cannot confirm what it provisions. If your team standardizes on containers for local development, budget time to read that directory rather than expecting a documented onboarding flow.

The third is release cadence versus stability. The recent releases are 0.299.0, 0.298.0 and 0.297.0, published on 2026-09-17, 2026-09-11 and 2026-09-09. Three releases in eight days at a 0.x version number means the API and the generated contracts move. A fork pinned to an old release will drift from the generated files, and the check:generated-api and check:generated-docs scripts will tell you so loudly. That is fine for a team that tracks main. It is painful for one that wants to freeze and forget.

Webstudio against Webflow and WordPress: different ownership models

Webflow is the comparison the project invites. The difference is not the canvas, it is who holds the artifact. In Webflow the published site, the CMS collections and the hosting account are all inside Webflow's system, and leaving means rebuilding. Webstudio's README states you own the data, components, and infrastructure, and that it can be hosted anywhere including with the vendor. So the migration question is answerable in principle: the builder produces output you deploy, and the content lives in a database you control. Whether that is true in practice depends on the CMS you connect, which the README does not specify beyond saying it connects to any headless CMS.

WordPress is the other comparison people search for, and it is a different kind of tool. WordPress is a content management system with a theme and plugin ecosystem; Webstudio is a visual development platform that expects you to bring the CMS. If your site is mostly editorial content with a plugin for everything else, WordPress is the shorter path. If your site is a marketing surface for an application you already deploy, Webstudio's model of generating output you ship alongside that application is closer to how your team already works.

Maintenance cost and what the release cadence implies

The last push to the default branch was on 2026-09-21, and the most recent tagged release was 0.299.0 on 2026-09-17. The repository is not archived. That combination means you are tracking a project that is moving, not one you can adopt and leave alone.

Concretely, upgrading means re-running pnpm install against [email protected], rebuilding the workspace, and checking that the generated contracts still match. The check:generated-api and check:generated-docs scripts exist precisely because those files are derived, and a version bump that changes the server API will require regenerating them if you have forked. The check:package-boundaries script adds a second constraint: if you add a package that imports across a boundary the project forbids, your build fails. These are guardrails that make upstream contributions cleaner and forks more work.

The licence cost is separate from the engineering cost. AGPL-3.0-or-later on the core is a copyleft licence with a network clause, and the animation package sits outside it under a commercial EULA. This is not legal advice, and the README does not state how the two interact for a hosted derivative. If you plan to offer Webstudio-based sites to third parties, get that question answered by someone qualified before you build on it.

Editorial conclusion

Adopt Webstudio if you want a visual editor whose output you can deploy on your own Cloudflare Workers or other infrastructure and whose data stays in your database. Do not adopt it if you need a permissively licensed core to embed in a closed product, or if you want the animation components without accepting a separate EULA. Before committing, verify two things in the repository: which packages the AGPL-3.0-or-later notice actually covers, and whether the sdk-components-animation package is one you are willing to license under the Webstudio, Inc. EULA. Then run pnpm dev and confirm the builder starts against your own Postgres before you move a client project onto it.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. webstudio-is/webstudio on GitHub