Silex: a visual static site builder that exports plain HTML

What Silex is for, and who it is not for

Silex is a visual website builder that outputs static HTML and CSS. The README frames the problem bluntly: most no-code tools lock users into proprietary formats, forced hosting and subscriptions. Silex's answer is to keep the artifact standard. You design in a browser-based editor, and what you get out is HTML and CSS you can host anywhere.

The audience named in the README is specific. Web agencies that want a visual workflow with static output. WordPress developers who want to replace the theme layer with a custom frontend fed by GraphQL. Freelance web designers producing client sites without writing markup by hand. No-code users who have hit the ceiling of Wix or Squarespace and want full CSS control.

That list already tells you who should look elsewhere. If you want a hosted service with a support contract, Silex is not that. If your content workflow lives entirely inside WordPress and you are happy with themes, the GraphQL binding is extra machinery for no gain. And if you need to hand a non-technical client a login and forget about it, you are running a Node server and a build pipeline on their behalf.

How the editor, the server and the export fit together

The repository is a pnpm workspace with a clear split. The editor directory holds the client-side visual editor, which is built on GrapesJS. The server and server-rust directories hold the backend. The desktop directory holds a Tauri application with a Rust component under desktop/src-tauri. A root Cargo.toml lists server-rust and desktop/src-tauri as workspace members, so the Rust side is a first-class part of the tree rather than a side experiment.

The data flow described in the README runs from the editor to static output. You build a page visually, and the result is HTML/CSS. Separately, components can be bound to a CMS: the README names WordPress, Strapi, Squidex, or any GraphQL API. The examples directory contains the configuration surface for this, with files such as examples/server-config-connectors.js, examples/server-config-directus.js and examples/client-config-grapes.js. So the integration model is configuration files loaded by the server and client, not a plugin marketplace you click through.

The editor is also 11ty compatible according to the README, meaning Silex templates can feed a static site generator and deploy through CI/CD. That matters because it changes what Silex is in a pipeline: not the thing that serves pages, but the thing that produces the templates the generator consumes.

There is a third surface, the MCP server. The README states that Silex uses Model Context Protocol so you can point an AI tool at the running desktop app. The endpoint given is http://localhost:6807/mcp, and the README says the server is optimized for small local models of 7B parameters and up. This is documented as part of the desktop app, which the README labels alpha.

Installing Silex and opening the editor for the first time

The README gives a contributor-oriented quick start. It clones with submodules, installs with pnpm, builds, and starts the server. Node 24 or newer is required according to the engines field in package.json.

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

After that the README says to open http://localhost:6805. That is the editor. If the page does not load, the build step is the first thing to check, because pnpm start runs the compiled server from dist rather than the TypeScript sources.

If you would rather not install Node and pnpm locally, the repository ships a Dockerfile and a docker-compose.yml. The compose file mounts two host directories into the container and publishes port 6805.

services:
  silex:
    build:
      context: .
      dockerfile: Dockerfile
    volumes:
      - $PWD/storage:/silex/silex/storage
      - $PWD/hosting:/silex/silex/hosting
    ports:
      - "6805:6805"

The Dockerfile sets a long list of environment variables with defaults, including SILEX_PORT=6805, SILEX_HOST=localhost, SILEX_SESSION_NAME=silex-session and a placeholder SILEX_SESSION_SECRET that the file itself tells you to replace. It also sets STORAGE_CONNECTORS=ftp and HOSTING_CONNECTORS=ftp,download, which means the container as shipped expects FTP credentials to be supplied before storage will work. Those are the values to look at first if the editor opens but cannot save anything.

The README also points at a hosted instance at v3.silex.me and a desktop download, and says the online version requires a GitLab account for storage. For a production self-hosted setup, the README defers to the self-hosting guide on docs.silex.me, and the Dockerfile notes that the default SaaS configuration lives in server/deploy/ and can be overridden with the SILEX_SERVER_CONFIG and SILEX_CLIENT_CONFIG environment variables.

The connector configuration is where self-hosting gets real

The single most important thing to understand before adopting Silex is that storage and hosting are connector-based, and the defaults are not neutral. The Dockerfile sets STORAGE_CONNECTORS=ftp and HOSTING_CONNECTORS=ftp,download. The GitLab variables (GITLAB_DOMAIN, GITLAB_CLIENT_ID, GITLAB_CLIENT_SECRET and a second set prefixed GITLAB2_) are present but empty in the image.

That shape tells you something about the hosted service: the online instance at v3.silex.me authenticates users through GitLab and stores their work there. A self-hosted instance does not inherit that. You either configure GitLab OAuth yourself, or you point storage at FTP, or you write a connector. The examples directory shows the pattern with server-config-connectors.js, which is the file to read before assuming a connector exists for your backend.

This is a genuine trade-off rather than a flaw. A connector model is what lets Silex avoid owning your data. It also means the out-of-the-box self-hosted experience is less finished than the hosted one, and the README does not pretend otherwise: it sends you to a separate self-hosting guide for Docker and production setups. Budget time for that step. Teams that expect a single docker compose up to yield a working multi-user instance will be surprised by how much of the configuration is empty placeholders.

Where Silex is the wrong tool

The desktop application is alpha. The README says so twice, once in the feature list and once in the quick start, and links to a roadmap post for progress. Anyone whose requirement is an offline editor with no account should read that label literally. The MCP server, which is the AI-assisted authoring path, is documented as part of the desktop app, so it inherits that status.

The release history reinforces the point about maturity in a different way. The most recent releases listed are v3.10.0-canary.2 from 2026-07-31 and v3.10.0-canary.0 from 2026-07-26, with the last stable release v3.9.0 on 2026-07-26. Canary builds are being published alongside stable ones, which is normal for an active project, but it means the version you get from a canary tag is not the version a cautious team should deploy.

A second limitation is the build requirement. Node 24 or newer, pnpm, a webpack client build and a TypeScript server build. There is no single static binary you can drop on a shared host. If your deployment target is a cheap PHP host with no Node runtime, Silex's server will not run there, even though its output would.

Third, the AGPL-3.0 licence is a real constraint for some business models. More on that below.

How Silex differs from Webflow and from page builders inside a CMS

The README quotes a line calling Silex "the only open source alternative to Webflow." The useful comparison is not feature parity, it is where the artifact lives. Webflow hosts the site and the design lives in Webflow's system. Silex's stated position is the opposite: standard HTML/CSS output, export everything, host anywhere. If you stop paying a subscription, a Webflow site has a migration problem. A Silex site is a directory of files.

The second comparison is against the visual builders that ship inside content management systems. WordPress has block editors and page builder plugins; Strapi and Directus have their own admin interfaces. Those tools keep the design inside the CMS, which is convenient until you want to change the frontend stack. Silex inverts it: the CMS becomes a data source reached over GraphQL, and the design lives in Silex. The README's WordPress entry describes exactly this, using GraphQL for content and dropping the theme layer.

That inversion is the whole argument. It costs you the convenience of a single system. It buys you a frontend you can rebuild without touching content, and content you can move without rebuilding the frontend. Whether that is worth it depends on how likely you are to change one without the other.

Maintenance, licence and the cost of staying current

The repository is not archived, and the last push was on 2026-09-11. Releases are being cut, with canary builds appearing days before stable ones. The project is owned by Silex Labs, which the README describes as a non-profit recognized as being of general interest, with finances published on Open Collective. That structure removes the usual commercial pressure to change the licence or move features behind a paywall, but it also means the maintenance capacity is whatever the contributor base provides.

Upgrade cost depends on how you deploy. If you self-host from the repository, you are tracking a pnpm workspace with a webpack client build and a TypeScript server build, plus a Rust workspace for the server-rust and desktop crates. Upgrades mean rebuilding. If you use the hosted instance at v3.silex.me, upgrades are someone else's problem but your data lives in GitLab storage under their configuration.

On licence: Silex is AGPL-3.0. The README's own framing is "free forever" with all features included and no premium tier. The practical implication for a business is that AGPL is a strong copyleft licence, and if you modify Silex and let users interact with it over a network, the licence's network clause is generally understood to require you to offer those users the corresponding source. Running an unmodified self-hosted instance for internal use is a different situation from building a commercial product on top of it. This is not legal advice; if you plan to modify and redistribute Silex, or to offer it as a service, get your own counsel to read the licence text in the repository's LICENSE file.

Editorial conclusion

Silex fits teams that want a visual editing surface but insist on owning the output: agencies producing client sites, WordPress or Strapi users who want a custom frontend, and anyone who needs a self-hosted editor rather than a subscription. It is the wrong choice if you need a mature desktop offline editor today, since the README labels the desktop app alpha, or if your team cannot run Node 24 and a build step. Before committing, verify that the storage and hosting connectors you need are actually configured for your instance, check that the FTP or GitLab credentials in the Docker environment are set, and confirm the export path produces the HTML you expect from a real page.

Frequently asked questions

Official sources

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