Documentation

Build Configuration and Environment

Build configuration controls how the site builder compiles and serves your site. Most of these settings sit at the site level and apply to every build — image processing, locale support, key-naming defaults, and similar baseline choices. This page covers what's configurable, where each setting lives, and which configuration belongs to the builder versus the site as a whole.

Two Kinds of Configuration

SleekCMS splits build-related configuration across two surfaces:

Site Configuration (Site Configuration) — The site-level toggles: whether the site builder is enabled, the image processing backend (default vs. Imgix), localization, key-naming style, and similar choices. These settings are global across the site.

Builder-specific config — In-template settings authored directly in EJS or assets: layout selection, head injection, CSS/JS includes, Tailwind customization. These are per-template or per-block decisions.

The split is intentional. Site-level toggles are admin decisions that affect the whole site; template-level choices are developer decisions made where the code lives.

→ Site Configuration

Enabling the Site Builder

The site builder is a per-site toggle. When enabled, templates compile into static HTML and the deploy targets become available. When disabled, the site operates as a pure headless CMS — content flows out through the API, and there's no built-in HTML rendering.

You can enable or disable the builder at any time without losing content. Disabling hides the template editor and deploy options but leaves all your content, models, and assets in place.

→ Site Configuration

Image Processing

The default image backend handles transformations on the fly — resizing, format conversion, cropping, color adjustments — through query parameters on the image URL. This is documented fully on Image Management & Optimization.

Sites can opt to route image requests through Imgix instead. Imgix is a third-party image processing service; configuring it requires an Imgix account and a web-folder source pointing at your image origin. With Imgix enabled, the same transformation query parameters work, but the URLs route through Imgix's CDN.

Switch image backends at the site-configuration level — templates don't change. The same src(), img(), picture(), and svg() helpers produce URLs for whichever backend is active.

→ Site Configuration → Image Processing with Imgix

Localization

Localization is a site-level toggle. When enabled, content can be edited and delivered in multiple locales — each content record stores translated values, and the API and builder pick the right translation based on the requested language.

Templates don't need to be duplicated per language. The same template renders content in any locale; the differences appear in the data, not in the templates.

→ Site Configuration → Localization and Translations

Key-Naming Style

When you create a field or model in the editor, SleekCMS auto-generates the handle (the programmatic key used in API responses and templates) from the display name. The naming style controls the convention: snake_case, camelCase, or kebab-case.

This is purely a default. Auto-generated handles can always be edited manually, and changing the site-level default doesn't rename existing handles.

→ Site Configuration → Attribute Key-Name Style

Layouts and Per-Page Configuration

The builder's per-page configuration lives in the page templates themselves, not in a separate config file. The main knobs:

Layout selection — Comment in a page template chooses which layout wraps the page:

<% // layout: marketing.ejs %>

Or opt out of layouts entirely (for XML, plain-text outputs):

<%# layout: none %>

Head metadata — Page-specific titles, descriptions, and OG tags via title(), meta(), link() from the template.

Asset includes — link() and script() calls in the template control which CSS and JS files the page pulls in.

→ Layout → Assets and Static Files

Tailwind Configuration

Tailwind is enabled by the presence of /css/tailwind.css. The file itself acts as the configuration surface — theme tokens, plugin imports, and custom utilities are all declared in this file using Tailwind v4's CSS-first config approach.

→ Tailwind and Styling

What's Not Configurable

A few things are intentionally not surfaced as config:

  • The build engine. EJS is the only template language. There's no swap-to-Pug or swap-to-Liquid setting.
  • Routing. Page URLs are derived from page-model file keys (_ → /, + for collections). There's no routes file.
  • Asset bundling rules. No webpack config, no Vite config — the build pipeline handles compilation internally.

This is by design. Reducing the configuration surface keeps sites portable and makes the platform easier to reason about. If you find yourself wanting a knob that doesn't exist, the answer is usually a template- or asset-level workaround rather than a config setting.

What's Next