Silex vs Webstudio: Connecting a Website to a CMS, Honestly

If you design websites visually and you want them to show real content from a CMS, you are looking for the same thing a lot of people want today: a visual web design tool that builds pages from actual data, not lorem ipsum. Silex, Webstudio, and Webflow all belong to this family of visual, no-code web design tools. This article compares how Silex and Webstudio connect a site to your data, and what that choice really costs you down the line.

We wrote about this design-on-real-data idea when we rebuilt Silex from scratch. If you want the background, read Why Silex v3: the short version is that a modern website builder should let you drag and drop lists, texts, and images, then design pages using the content that lives in your CMS, with a free, libre and open source stack underneath.

What "connect a CMS" actually means

Neither of these tools asks you to hand-code an integration. The idea is the same in both: you keep your content in a backend you already like (WordPress, Strapi, Directus, a headless CMS, a database with an API), and the visual builder becomes the front end. You design a layout once, point a component at a content field, and the tool repeats and fills that layout from your data.

But before any of that works, there is a question people often skip: how does the tool know that a page has a title, or that a "hero" block contains one image and two texts? That is the real heart of connecting a CMS, and it is worth slowing down on.

The content model comes first

Every data-driven site rests on a content model: the shape of your data. A blog might have a Post type with a title, a body, a publishedAt date, and a hero group that holds one image and two text fields. That structure does not live in the visual builder. It lives in your CMS: WordPress custom fields, a Strapi content type, a Directus collection, a database table. The CMS defines the fields; the visual tool reads them and lets you map each field to a component.

The two tools discover that model in different ways.

Silex connects to a GraphQL data source and introspects its schema. Because GraphQL describes its own types and fields, Silex knows in advance that a Post has a title, that hero contains an image and two texts, and so on. Those fields show up as tokens you pick with autocomplete while you build. In Silex terms, a token is a property of the data source such as post.data.attributes.title. You then bind a token to a component: drop the hero.image token into an image's src, put title into a heading's content, and so on. Silex calls these bindings on properties like innerHTML, src, href, alt, class, and style. See the Silex CMS basics page for the full model.

Webstudio discovers the model from the data it fetches. You create a Resource (an HTTP request to your CMS or API), and the fields in the response become variables you can bind. Access a nested field by typing a dot, like CMS Data.title, and the editor autocompletes the children. The shape comes from your query and the JSON that comes back, so in practice your GraphQL query or REST endpoint defines which fields are available to bind. Webstudio documents this in its data variables guide.

The takeaway: neither tool invents your content model. Your CMS owns it. Silex learns it by reading the GraphQL schema; Webstudio learns it by reading the response of a Resource. Either way, the job you do in the builder is mapping fields to visual components.

Binding fields, and building real expressions

Mapping a single field to a single component is the easy case. Real projects need composed values: an alt text that helps SEO, a permalink built from a page name, a label that mixes a date with a prefix. Both tools have an expression editor for this, and they take different routes.

Silex builds expressions the no-code way, by clicking. An expression is made of tokens, and you can pipe those tokens through Liquid filters to transform them. Silex writes expressions in a readable form like object > property | filter: option1, option2. Two concrete examples:

• An SEO-friendly alt attribute that reads "image name plus page title": take the image's name token, then chain a filter that appends the page title token. You compose the two pieces in the editor, and Silex assembles the final string.
• A permalink built from the page name: take the page name token and pipe it through a URL-encoding filter so the result is safe to put in a URL.

The important detail: you never write Liquid yourself. Silex generates Liquid under the hood and exposes the Liquid filters in the expression editor as options you pick and configure. You do not need to know the templating language to build these expressions. Filters can even take other tokens as arguments, which is how you combine several fields into one value.

Webstudio uses a small, safe subset of JavaScript in its expression editor. You concatenate values with + or with template literals, and you have access to safe string methods like toLowerCase, replace, slice, and split. The same two examples in Webstudio's style:

• The alt text: CMS Data.imageName + " " + Page.title, or a template literal that places both variables inside one string.
• The permalink: take the page name variable and run string methods on it (lowercase it, replace spaces) to produce a clean slug.

Both approaches let you build composed, real-world expressions. Silex leans on visual tokens and Liquid filters so no code is required; Webstudio leans on a familiar JavaScript-like syntax. Neither is wrong. Pick the one that matches how you like to work.

How Webstudio connects to a CMS

Webstudio's stance is refreshingly clear: it does not ship a CMS. It positions itself as "connect to any headless CMS, visually," and it means it. Webstudio is a visual front end for any backend that speaks HTTP.

The core building block is the Resource described above: a variable whose value comes from an HTTP fetch. That can be a plain REST call or a dedicated GraphQL Resource with its own query, variables, and headers. Because REST is supported natively, you can wire up an enormous range of services with no bridge in between. Webstudio documents 20-plus integrations, including WordPress, Drupal, Strapi, Sanity, Contentful, Hygraph, Directus, Payload, Ghost, Notion, Airtable, and Baserow, and in practice anything with an HTTP API is fair game.

From there the visual model is strong. Dynamic pages use path parameters (/post/:slug). Nested Collections repeat a component per item. The expression editor binds CMS fields to component fields, with conditions and fallbacks, and it even lets you drop dynamic values inline inside otherwise static text. Authentication goes through headers, pagination supports both offset and cursor, and you can drive a 404 from an expression. This is genuinely mature dynamic-routing and data-binding work.

The runtime model is the thing to understand. Webstudio sites fetch data at request time, on Cloudflare Workers, edge-cached according to your CMS's own cache headers. Content is therefore near-live: change it in the CMS and it shows up without a rebuild. The trade-off is that this is not a static build, so the page depends on that hosting layer and on your CMS being reachable when a visitor arrives. One more limit worth knowing: rich text can embed HTML or Markdown, but you cannot place Webstudio components inline inside CMS rich text.

On openness, Webstudio is honest, and so should we be. The builder is AGPL and can be self-hosted via Docker. But the platform is open-core: self-hosting the builder in production is described as "not recommended," and in practice you are pushed toward Webstudio Cloud on Cloudflare. You can export a site as a Remix/React app, which is a clean and portable exit, or push it one-click to their cloud.

Credit where it is due: native REST, live content, a polished binding experience, and a clean Remix export make Webstudio a good tool. None of what follows is a knock on its quality.

How Silex connects to a CMS

Silex approaches the same problem from the other end. Its data layer is GraphQL-first: you add a data source in the settings dialog, Silex introspects the schema, and your fields autocomplete as tokens while you build. You then bind a component's content, attributes, classes, or visibility to those tokens visually. Field states control what gets output and what stays internal: hidden states help build other expressions and shape the generated query without being rendered, public states expose reusable values, and private states carry element-specific data like innerHTML, src, or href. You get loops and collections with offset, limit, and sort.

Silex's collection pages follow the model Webflow made popular, where one design generates many pages from a list, each with its own URL and SEO. If you know Webflow, how it structures and styles collection pages will feel familiar. In Silex, collection pages are driven by the 11ty pagination object, which you also reach through the expression editor.

REST is not native here. If your backend only speaks REST, you wrap it with a layer like GraphQL Mesh or Graphweaver to expose it as GraphQL. That is real setup work, and it is the honest cost of Silex's approach. On the plus side, any GraphQL API works: WordPress via WPGraphQL, Strapi, Squidex, Directus, KeystoneJS, and Supabase (mind the CORS caveat).

The key difference is the build model. When you publish, Silex generates Eleventy (11ty) pages and data files that query your API at build time. The build itself runs on CI, on GitLab pipelines, and produces a plain static site: HTML you can deploy anywhere. Most people never think about that build step; it just runs when you click publish. Advanced users can care about it, because it is where you add 11ty plugins or customize the build, but you do not need to touch it to ship a normal site. Your CMS is queried during the build and is *not exposed at runtime at all*. Nobody visiting the site touches your CMS or any live server function. That means better security (no live data endpoint to attack), strong performance (static files on any host or CDN), and a completely standard, portable stack: Eleventy plus GraphQL, with no proprietary runtime.

The flip side is fair to state. Content is only as fresh as your last build, so live updates mean triggering a rebuild, usually via a webhook. There is a bit more configuration up front, and the ecosystem and docs are smaller than a venture-backed competitor's. You can try the whole flow in the Silex editor before committing, and there is a short getting started with a CMS walkthrough that builds a live list from a public GraphQL API in a few clicks.

Where Silex is uncompromising is ownership. It is fully libre, AGPL, with no open-core catch: no premium tier, no CLA, no feature held back for a paid cloud. It is stewarded by the non-profit Silex Labs, has been going since 2009, and every feature is free. When we say "free," we mean free as in freedom, not only free of charge.

See it in action

Reading about data binding only goes so far. Two short videos on the Silex channel show the workflow end to end:

• Silex Quick Start: create and publish your first website
• The Silex editor: a guided tour

More walkthroughs live on the Silex video channel, and the written docs cover the CMS feature, the core concepts, and a Supabase integration guide. Developers who want to customize the build can read the Silex CMS developer docs.

Side by side

	Webstudio	Silex
Content model source	CMS defines it; read from Resource response	CMS defines it; read via GraphQL schema introspection
Field discovery	Variables from fetched JSON, dot-access autocomplete	Tokens from the schema, autocomplete while building
Data protocol	REST and GraphQL, both native	GraphQL native; REST needs a bridge (Mesh/Graphweaver)
CMS reach	Any HTTP API, 20+ documented	Any GraphQL API (WPGraphQL, Strapi, Squidex, Directus, KeystoneJS, Supabase)
Expressions	JavaScript subset, + and template literals, safe string methods	No-code tokens piped through Liquid filters, no Liquid to write
When data is fetched	At request time, on the edge	At build time, on CI (GitLab)
Output	Dynamic app on Cloudflare Workers; Remix/React export	Static HTML site, deploy anywhere
Content freshness	Near-live	As fresh as the last build (rebuild via webhook)
Routing and pagination	Dynamic routes, offset and cursor, expression-driven 404	Collection pages (Webflow-style) with SEO, offset/limit/sort
Rich text	HTML/Markdown embed, no components inline	Bound via expressions and filters
Runtime dependency	Depends on hosting layer and live CMS	None; CMS never exposed at runtime
Licensing model	Open-core (builder AGPL, production self-host discouraged)	Fully libre AGPL, no open-core, non-profit
Cost	Free tier plus paid cloud	All features free

Who should choose what

Reach for Webstudio if native REST matters to you, if you need content to appear live the moment it changes, or if you want the most mature dynamic routing and pagination out of the box and are comfortable running on their cloud. It is a capable, well-built tool, and for a marketing site backed by a headless CMS that changes hourly, its runtime-fetch model is a genuine advantage.

Reach for Silex if you want a static site you can host literally anywhere, if you care that your CMS is never exposed to the public at runtime, and if you want a tool you fully own with no premium tier waiting to gate the feature you will need next year. If your content changes on a human schedule rather than by the minute, a rebuild-on-publish flow is a fine trade for that robustness and independence.

A libre-framed conclusion

The honest core distinction is this: Silex is static-first, fetches data at build time, and is fully libre; Webstudio does runtime edge-fetch, reaches a broader "any CMS" surface, and is open-core. Silex trades native REST and live-content convenience for ownership, portability, and static robustness. That is a real trade, and for some projects Webstudio's side of it is the right call.

But open-core and fully libre are not the same thing, and the difference is not academic when you are choosing a tool to *depend on*. Open-core means the vendor decides where the free edition ends and the paid one begins, and that line can move. It is a case-by-case risk, not an accusation, and Webstudio is upfront about how its platform works. Still, a tool that is fully libre and community-stewarded cannot be quietly bought, shut down, or fenced off behind a new paywall. You keep the source, you keep the site, you keep control.

That is why we build Silex the way we do. Not because "open source" is a nice badge, but because the freedom to run, study, modify, and share the software is what actually protects the person relying on it. If that matters to you, try the editor, read the docs, watch the videos, and come say hello in the community. And if Webstudio fits your project better, that is a good outcome too. Choosing your tools with open eyes is the whole point.