Silex: a GrapesJS-based visual builder that exports static HTML

The lock-in problem Silex is aimed at

Proprietary site builders keep the design in a format only they can read. The README frames the contrast directly: most no-code tools mean "proprietary formats, forced hosting, subscriptions," while Silex promises "standard HTML/CSS output, export everything, host anywhere, leave anytime." That is the whole pitch. The artifact you walk away with is a directory of HTML and CSS, not a database row in someone else's product.

The audience named in the README is specific: web agencies scaling client work, WordPress developers who want a visual frontend on top of GraphQL content, freelance designers who cannot write code but need to hand over a real site, and no-code users who have hit the ceiling of Wix or Squarespace and want full CSS control. What these groups share is that the deliverable leaves their hands. An agency handing a site to a client, or a freelancer handing files to a host, has a different requirement from someone publishing only inside a walled platform. Silex is built for the handover case.

GrapesJS in the editor, plugins on the server

The editing surface is GrapesJS, the open source drag-and-drop page builder. Silex wraps it with HTML, CSS and JS editors so you can drop to source when the visual controls are not enough. The repository is TypeScript, and the README describes a plugin system for extending the tool with server and client plugins written in JS or TS. That split matters: a client plugin changes what the editor can do, a server plugin changes what the running instance can do, which is where you would add storage backends or publishing steps.

On the content side, components can be bound to WordPress, Strapi, Squidex, or any GraphQL API. The README also states 11ty compatibility, meaning Silex templates can feed the 11ty static site generator and be deployed through CI/CD. So the data flow has three stages: content lives in a GraphQL source, the visual editor binds components to that data, and the output is static HTML/CSS that either ships as-is or passes through 11ty. The README does not spell out the binding syntax or the template file format, so anyone evaluating this should treat the CMS integration as something to verify against their own endpoint rather than assume.

Running it locally and pointing an MCP client at it

The contributor quick start is the clearest install path in the material. Clone with submodules, install with pnpm, build, start:

git clone --recurse-submodules https://github.com/silexlabs/Silex.git cd Silex pnpm install && pnpm build && pnpm start

The server then listens on http://localhost:6805. The --recurse-submodules flag is not decorative; skipping it is a common way to end up with a broken build.

For the AI integration, the desktop app exposes an MCP server at http://localhost:6807/mcp. The README gives a concrete command for Claude Code:

claude mcp add --transport http silex http://localhost:6807/mcp

OpenCode and Goose are configured through their own config files with the same URL, and any other MCP client should use Streamable HTTP transport. The README states the MCP server is tuned for small local models of 7B parameters and up, and that Ollama can be used if you want the model to run locally. The desktop app itself is described as alpha and built with Tauri for Windows, macOS and Linux. For production and Docker setups the README defers to the self-hosting guide at docs.silex.me, which is not reproduced here.

Where the alpha label and the hosting model bite

Two constraints are stated plainly and both affect planning. The desktop app is alpha. Building a client deliverable on an alpha desktop binary means accepting that the offline, no-account workflow may change under you. The README also notes the online editor at v3.silex.me requires a GitLab account for storage, which is a real dependency: your project storage is tied to a third-party account, even though the output is not.

The CMS binding is the other place to slow down. "Any GraphQL API" is a broad claim, and GraphQL endpoints differ in schema shape, authentication and pagination. The README does not document how a component maps to a query or how credentials are stored. If your content source needs token refresh or nested relations, that is unverified territory. There is also a mismatch worth naming: the project markets itself to people who do not write code, but the self-hosting path is Docker or Node.js and the contributor path is pnpm with submodules. The no-code promise applies to the editing experience, not to the deployment.

How Silex differs from Webflow and from a plain static site generator

The README quotes a line calling Silex "the only open source alternative to Webflow." The meaningful difference is not the visual editor, which both have, but what happens at the end. Webflow hosts the site and the design lives in Webflow. Silex exports files. That changes your cost structure and your exit options, and it also changes what you are responsible for: hosting, forms, redirects and anything else the platform used to handle now sit with you.

Against a plain static site generator like 11ty alone, the difference runs the other way. 11ty has no visual canvas; you write templates and content files by hand. Silex adds the drag-and-drop layer and then, per the README, can hand off to 11ty for generation. So the honest comparison is not Silex versus 11ty but Silex plus 11ty versus hand-written templates. If your team already writes templates comfortably, the visual layer is overhead. If a designer needs to move boxes without waiting on a developer, it is the point of the tool.

Licence and the cost of staying current

Silex is AGPL-3.0. That is a strong copyleft licence with a network clause: if you run a modified version as a service that users interact with over a network, the licence requires you to offer those users the corresponding source. For an agency running Silex internally to produce client sites, the calculus is different from a company that wants to host a modified Silex as a public product. The README says the project is "always free software (AGPL), all features included, no premium tier," so there is no commercial licence to buy your way out of the obligation. This is not legal advice; get your own review before shipping a modified instance.

Maintenance cost is visible in the release cadence. The supplied release list shows v3.9.0 in late July 2026 and two v3.10.0 canary builds around the same window, with the last push to main in September 2026. Canary releases alongside stable ones mean you should track the stable tag rather than main if you are deploying for clients. The project is maintained by contributors and owned by the non-profit Silex Labs, with finances published on Open Collective. That structure removes investor pressure but does not remove the need for someone to keep the project moving, and the contributor list in the README shows a small group across recent years.

Who should pick this up, and what to check first

Silex fits teams that treat the site as a deliverable rather than a subscription. If you are an agency or freelancer producing static sites for clients, and you want a designer to work visually while the output stays as plain HTML/CSS, the model matches. The GraphQL binding is the feature to test before you commit, because it is the one that decides whether your content workflow survives contact with a real endpoint.

It does not fit teams that want a fully managed service with no local setup, or teams that need the editor to be stable today rather than alpha. It also does not fit anyone who cannot accept AGPL-3.0 terms for their deployment model. If you are evaluating, the concrete first step is the local build: clone with --recurse-submodules, run pnpm install && pnpm build && pnpm start, open localhost:6805, and connect one component to a GraphQL source you already run. That single test tells you more than the feature list does.

Editorial conclusion

Adopt Silex if you build static client sites and want visual editing that ends in standard HTML/CSS you can host anywhere, and if the AGPL-3.0 licence fits how you distribute your work. Do not adopt it if you need a hosted service with no local setup, since the online editor expects a GitLab account for storage and the desktop app is still labelled alpha. Before committing, verify three things: that the CMS binding works against your specific GraphQL endpoint, that the 11ty export path matches your CI/CD pipeline, and that your legal review is comfortable with AGPL-3.0 obligations for the way you deploy the editor.

Official sources

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