Overview

What you can customize about your white-label platform, and where each control lives

Everything your customers see — the app name, colors, fonts, navigation, dashboard layout, onboarding, and component styling — can be reshaped to match your brand. This section documents every customization surface, with the exact names, values, and limits the platform enforces.

All of it happens in the Branding studio: open your Platform workspace and go to Settings → Branding. Developers can drive the component-styling channel through the theme API as well.

The three customization modes

At the top of the Branding page you pick a customization mode. The mode changes which authoring sections the studio shows you — it never changes what your customers see until you save and publish.

Mode	Sections shown	Availability
Guided	Brand basics, theme presets, dashboard builder, onboarding builder, version history	Everyone (default)
CSS / Code	Brand basics, visual rules editor, raw CSS, version history	Everyone
Templates	Brand basics, template builder, version history	Admin-enabled per account (`templates_enabled`)

Think of them as tiers of increasing control:

Guided — pick from built-in controls: brand basics (name, logo, colors, fonts), one-click theme presets, the dashboard surface builder, and the onboarding flow builder. No code.
CSS / Code — style individual UI components with the rules editor (a validated, allowlisted CSS dialect), and — if enabled for your account — write raw CSS against the real DOM.
Templates — re-author the structure of the sidebar and dashboard by composing typed building blocks as data.

Independent of mode, you can also customize navigation (rename, hide, reorder, add links) and product terminology.

Self-serve vs. admin-enabled

Most of the surface is self-serve. Two tiers need a per-account capability that Swarmz enables on request:

Raw CSS — requires the raw_css_enabled bit on your account (plus a global feature switch on Swarmz's side). Everything else about the tier — drafting, previewing, publishing — is then self-serve. Turning raw CSS off is never gated.
Templates — requires the templates_enabled bit. Without it, the Templates mode falls back to Guided.

Contact Swarmz support to have either enabled.

The security model, honestly

Your customizations run inside an app that other tenants and Swarmz itself also depend on, so every channel is constrained by design:

Structure is data, not code. Navigation schemas, dashboard configs, onboarding flows, and templates are validated JSON against closed catalogs — unknown ids and component types are dropped, caps are enforced, and a broken config degrades to the stock UI rather than crashing.
CSS is validated or sanitized. The rules channel accepts only allowlisted parts, properties, and value grammars. The raw CSS tier parses your stylesheet, strips anything dangerous (@import, non-HTTPS url(), unsupported at-rules), and force-scopes every selector to your white-label surfaces.
No arbitrary JavaScript. There is no channel for injecting scripts into the hosted app. If you need full code control over the frontend, that's the headless/bring-your-own-frontend direction — it's on the roadmap, not shipped. The theme API is the current programmatic surface.

Publishing and version history

Brand-basics saves apply live. The rules and raw-CSS channels use a draft → preview → publish flow with content-addressed, immutable artifacts: you always publish the exact hash you previewed, and every publish is recorded in the version history shown in the studio, with one-click restore.

Where to go next

Branding basics — name, logo, colors, fonts, presets, terminology
Design tokens — the CSS custom properties everything is built on
Navigation · Dashboard surface · Onboarding
CSS styling · Raw CSS · Templates
Developer API