Static sites, dynamic data: how Silex connects your content to a visual design

Static sites are the fast, secure, low-footprint way to publish on the web. But they carry a reputation: "static" sounds like "frozen", a set of hand-written pages that nobody but a developer can change. That reputation is out of date. With Silex, you design a page visually, connect it to a data source — a headless CMS or any API — and publish a site that is 100% static files yet driven by content your clients keep editing on their own.

This is the distinctive mechanism at the heart of Silex, and it is generic: the same approach works whether your content lives in WordPress, Directus, Supabase, Strapi, Squidex, or any GraphQL API. This article is the foundations guide. It explains what a data source is, how you bind fields, loop over collections, generate one page per item, handle slugs and permalinks without a plugin, and publish the whole thing as a static site that rebuilds itself when the content changes. The applied, CMS-specific guides (like Headless WordPress with Silex) all build on what is described here.

The problem: static is fast, but content changes

Editing content directly inside a visual builder is fine for a one-page site or a small brochure. It falls apart the moment you have real volume. As the Silex team put it on stream: typing 500 pages of content into a design tool "is just not possible, it is a nightmare." Your client wants to log into a familiar back office, add a blog post, swap an image, fill in a section — and see the public site update, without touching the design or the code.

The classic answer is a database-driven CMS that renders every page on every request. That gives you editable content, but it costs you the very things static is good at: speed, a small attack surface, and a light energy footprint. Silex takes a different route. It keeps the editable content and the static output, by pulling the two apart and joining them only at build time.

The core idea: bind a data source, build to static files

Here is the whole mechanism in one sentence: Silex reads your content from a data source while you design, and bakes that content into plain static files when you publish.

Nothing dynamic runs on the public server. The content is fetched once, at build time, and written into HTML. When the content changes, the site is rebuilt. Concretely, the workflow has four moving parts:

1. Your content lives in a headless CMS or API. Posts, products, team members, custom fields — whatever your data is — stay in the tool your client already uses.
2. Silex connects to it as a data source. In the CMS settings you point Silex at the source (a GraphQL API is the native format; REST APIs can be bridged into one). Silex reads the available content and its structure, so you design against real data, not placeholders.
3. You bind fields and define loops in the visual editor. You pick which element shows which field, and where the site should repeat a design across a list of items.
4. Publishing runs a static build. Silex generates the site with Eleventy (11ty), which downloads exactly the data it needs and writes out static pages. The result is standard HTML and CSS you can host anywhere.

Because the published site is only files, you get static's full benefit — and because those files were generated from your CMS, the content stays as editable as ever.

The two mechanisms you need to understand

Everything Silex does with data comes down to two building blocks. Get these two, and the rest follows.

1. Lists (loops): one design, repeated per item

A loop takes a single element you designed — a card, a row, a list item — and repeats it once for every entry in a collection. You build one card, tell Silex to loop it over your list of blog posts (or products, or continents, or team members), and at build time it produces one card per entry.

Inside the looped element you bind fields to content: this heading shows the item's title, this image shows its photo, this paragraph shows its description. You can also filter and sort the list — show only published items, order by date, reverse the order — all from the editor. One design in, a full list out.

2. Collection pages: one page, generated per item

A loop repeats an element within a page. A collection page goes a level up: it generates one whole page per entry in a collection. Design a single "article" page, attach it to your collection of posts, and Silex produces a separate page — with its own URL — for every post.

This is how you get a real content site out of one template: one product page design becomes hundreds of product pages, one article layout becomes your whole blog. Each generated page can itself contain loops (an article page that lists related posts, a category page that lists its products), so the two mechanisms nest naturally.

Slugs and permalinks, without a plugin

A page per item is only useful if each has a clean, unique URL. In a traditional CMS this is a job for a permalink plugin. In Silex it is built in.

For a collection page you define the permalink from the item's own data. Typically you take a field — the item's name or title — and pass it through a slug filter that strips spaces and accents and lowercases it, so "North America" becomes north-america. You can prepend and append slashes to shape the final path, /north-america/. The same slugified value drives the links between pages: a card in a list links to its detail page by building the href from the item's data, so navigation stays correct no matter how the content grows. No plugin, no manual URL management — the URLs come from the content itself.

Dynamic attributes: links, images, alt text, SEO

The binding is not limited to visible text. In Silex you can set any HTML attribute from data, which is what makes the output feel like a real, hand-built site rather than a filled-in template:

• Links — the href attribute is built from the item's data (see permalinks above).
• Images — the src attribute is bound to a field, so each looped item shows its own image; you can even build the URL for an image service from a data field (a country code driving a flag image, a product ID driving a photo).
• Alt text and SEO — because alt can be an expression, every generated image gets a meaningful, per-item description instead of one repeated string, which is good for both accessibility and search. The same goes for per-page SEO title, description, and social share image: they are fields you map, so every generated page is individually optimised.

The build: content baked in, rebuilt on change

When you publish, Silex runs a build (on GitLab CI, using Eleventy). The build reaches out to your data source, downloads only the data it needs, and writes the static pages and their content. A site with one page per country and one per continent is a few minutes of build for a full, browsable static site.

The important consequence: once the build has run, the live site is independent of the source. If the CMS changes, the published site stays exactly as it was until the next build — which is a feature, not a bug, for stability and security. To reflect new content you rebuild, and that can be automatic: a webhook from your CMS (for example a small plugin on WordPress) tells the build system that content changed, a fresh build runs, and a few minutes later the live site carries the new data. Your client edits in their back office, hits publish, and never opens Silex.

Why static + data, instead of a live CMS

Splitting design from content and building to static buys you four concrete things.

Speed. No server code to run and no database to query when a visitor arrives — pages are served as files.

Security and low maintenance. With nothing dynamic on the public server, there is almost nothing to attack. The CMS can be restricted or kept off the public internet entirely; content flows out to the build, nothing flows back in. An un-updated live CMS is a target; a static site is not.

Sobriety. The web's energy cost is real. Rendering a page from a database on every single visit, multiplied across the internet, adds up to a heavy footprint. Building once and serving files is dramatically lighter — and a clean static base gives you a solid foundation for accessible, standards-based pages.

No lock-in. A Silex site is standard HTML and CSS. Host it on GitLab Pages for free, on FTP, on your own server, on any CDN. There is no proprietary runtime underneath and no platform holding your live site hostage. Your content stays in your CMS; your pages stay portable.

The same mechanism, any CMS

Because the data source is just an API, this pattern is not tied to one tool. The mechanism above is exactly what powers our applied guide to Headless WordPress with Silex — WordPress as the back office your clients already know, Silex as the fast static front end. (For WordPress custom fields, we reach for Pods first: it is fully libre, GPL, and has WPGraphQL support built in.)

Swap WordPress for Directus, Supabase, Strapi, Squidex, or any GraphQL API and nothing about the approach changes: connect the source, bind fields, loop, generate collection pages, build to static. Pick the CMS your project needs; Silex reads from it the same way.

When static + data is not the right choice

This approach is a trade-off, not a free win. Be honest about where it does not fit:

• Real-time interactivity. Anything that must react to each visitor as it happens — live search over a large dataset, on-page personalisation, a live chat, a shopping cart with instant stock — needs code running at request time. A static front end will fight you here.
• Content per logged-in user. If each visitor should see a different, authenticated view (a member dashboard, a private account area), that state cannot be baked in at build time.
• Content that must update the instant it changes. A rebuild takes a few minutes. For most sites that is invisible; for a live scoreboard or a stock ticker it is not.
• Very frequent writes from visitors. User-generated content submitted and displayed continuously is a poor fit for a build-then-serve model.

If any of those are core to your project, a live, server-rendered setup is the honest recommendation. For the very large space of content sites — brochures, blogs, catalogues, portfolios, documentation, marketing sites — static with a data source is often the better tool.

See it in action

Silex creator Alex Hoyau walks through this entire mechanism live, data source, loops, collection pages, permalinks, dynamic attributes, and the static build, alongside Brice Martin, a long-time Silex contributor and web designer working with the Internet 2000 studio:

From CSS to CMS: creating static sites with dynamic data, with Alex Hoyau (lead developer of Silex) and Brice Martin (Silex contributor, Internet 2000).

A libre-framed close

Static does not mean frozen. With Silex, a static site can carry all the dynamic, client-editable content of a database-driven CMS, while keeping everything static is good for: speed, a tiny attack surface, a light footprint, and standard files you can host anywhere. You design once, bind your content, and let the build do the repetitive work.

And Silex is free software, libre — not just "open source" in the marketing sense. It is licensed AGPL and stewarded by the non-profit Silex Labs, with no premium tier and no open-core catch: every feature is included, forever. That matters for a tool you build client work on. No single company can quietly close it, fence off the feature you will need next year, or take your live site hostage — it is standard files and a community-owned tool, all the way down. "Open source" is the phrase people search for; freedom is the reason it is built this way.

If that fits how you want to work, open the editor, read the docs, and come ask questions in the community. Then pick your CMS and start designing on real data.