Skip to main content
Every B2B SaaS vendor that resells, white-labels or offers a “your brand here” tier ends up building the same thing badly: a themes table, a pile of CSS variables, a settings page nobody loves, and a backlog item called “make branding self-serve” that never gets prioritised. Livry is that system, as a service.

​
How it works

1

You define a Theme

A Theme is your product’s default token set — colours, spacing, radii, type, shadows. It is a W3C DTCG document: typed, nested, with aliases.
2

Each brand is a Variant

A Variant holds only the token values that make that brand different. It cannot add, rename or retype a token — the Theme owns the structure. See Variants.
3

You publish

Publishing freezes the current draft as an immutable version and materialises the resolved result — Theme overlaid with each Variant — into rendered files. See Versioning.
4

Your app fetches one file

tokens.css is a complete integration on its own. Four other renderings exist for stacks that need JSON. See What gets served.

​
Why tokens

Design tokens are framework-agnostic, diffable and small. Livry stays out of the business of dictating a design system: you bring your own token vocabulary, and Livry stores, resolves and serves it. Nothing in the product knows that color.brand means a brand colour — that is a naming convention, and it is yours. The document format is the W3C Design Tokens Community Group’s, because that is what your tools already emit. Tokens Studio, Figma Variables and Style Dictionary all import today — a vendor who has to preprocess their tokens before they can try us has not tried us.
This was not always true. Livry originally stored tokens as an untyped flat map. That model could not take a vendor’s tokens as they already existed, and typing turned out to pay for itself twice: an editor can show a colour swatch, and a migration can tell a token that was retyped from one that was renamed.

​
What makes it fast

The serving path does no work at request time. A publish materialises every (Theme, Variant, version) combination into static files ahead of time, so a request is a blob read behind a cache — there is no resolution, no database and no merge on the hot path. Two addresses per brand: See Caching.

​
Who it is for

Small-to-mid B2B SaaS vendors with reseller, partner or white-label programmes — large enough to need multi-brand theming, too small to justify building a theming platform in-house. The buyer is usually the engineering lead who owns the “make branding self-serve” backlog item, and the comparison is build-vs-buy: weeks of engineering plus permanent maintenance, against an API and a settings page you embed.

​
What Livry is not

  • Not a CMS. Branding, not content.
  • Not a component library. You bring the components.
  • Not a visual theme editor for your customers. The access model has no scope finer than an Environment role, deliberately. Build a reseller-facing editor against the API if you want one.

Core concepts

Team, Environment, Theme, Variant — and which boundaries are deliberately impermeable.