How Quilium builds the site

What you will understand

Quilium has one job at request time: turn content plus a template into the finished HTML a visitor loads. This page is the mental model of that render pipeline, not a procedure. For the step-by-step, see Quickstart.

It also draws a clear line: the CSS and JavaScript your pages reference are yours. How you produce them is your own local stack, not something Quilium prescribes. More on that below.

The render pipeline: content plus template to HTML

Quilium is a structured SaaS CMS with a server-side templating layer. Nothing renders in the browser as a framework. A request comes in, Quilium resolves which page it maps to, gathers that page's data, runs the template, and returns finished HTML.

The mental model is a separation of three concerns:

The point of keeping these apart is that content can change forever without anyone touching a template, and a template can be rewritten without migrating content. Each side evolves on its own clock.

When Quilium renders a page, it does roughly this:

1. Resolve the route. The incoming URL is matched to a page (a fixed page, or a detail page driven by a route like /article/{{param}}).
2. Run the page-type queries. A page-type declares route-aware queries; Quilium runs them and exposes the results as page.custom.<key> arrays for the template to read. This is where a detail page fetches its current item, and a listing fetches its collection.
3. Render the template. The page-type's Liquid layout fills the root layout, iterates the page's content blocks, and includes one element template per content-type. Each element reads its own fields from content.custom.
4. Return HTML. The output is a complete document. The visitor's browser does no data fetching to assemble the page.

For the why behind each piece, the deeper pages are Architecture, The content model, Routing and URLs, and Templating philosophy. This page only needs you to hold one idea: HTML is produced on the server, from data the page-type gathered, by a template you wrote.

Your front-end assets are your own

The HTML Quilium renders references a stylesheet and, often, a script. Quilium serves those static files, but it does not build them and does not impose a toolchain. How you produce your CSS and JavaScript is entirely your call:

• a bundler and a utility framework (Tailwind, esbuild, Vite, whatever you like),
• plain hand-written .css and .js files with no build step at all,
• or a CDN, the way the Quickstart demo loads Tailwind from a <script> so there is no build to run on day one.

Quilium's only contract is the rendered HTML and the static files it serves alongside it. Pick the front-end stack that fits the project; the docs do not standardise one.

When Quilium re-renders

Quilium re-renders on content and template changes; building your assets is a separate concern on your own trigger.

• Content changes (an editor edits a block, an agent updates a collection entry) change the data, not the template. The next render reflects them; nothing is "built". An editor can publish all day without any build.
• Template changes change the markup the render pipeline emits. The next render reflects the new template.
• Asset changes (your CSS or JavaScript sources) are rebuilt by your stack, on your own trigger, into the static files Quilium serves. Quilium does not run that build.

Knowing which of these you just changed tells you what could have moved, and who is responsible for rebuilding it.

Where to go next