Skip to main content
Livry is whitelabel theming as a service. You store one set of design tokens; each of your customers’ brands overrides only what makes it different; Livry renders the result and serves it to your app from cdn.livry.dev. If you build a product that has to look like somebody else’s — a reseller programme, a white-label tier, a platform with branded customer portals — Livry is the piece that holds the branding and gets it to your frontend fast enough to sit on the render path.

Quickstart

Sign up, define a theme, add a brand, and render it. End to end.

Core concepts

Team, Environment, Theme, Variant — four objects and the boundaries between them.

Integration guides

Plain CSS, Tailwind, Chakra UI, or a build-time token pipeline.

API reference

The REST API for automating everything the portal does.

​
The shape of it

Your app fetches one file per brand:
Swap that one href and every component restyles — nothing in your app holds a value, only var() references, so the browser recomputes them with no re-render.

​
What Livry is not

  • Not a CMS. It holds branding, not content.
  • Not a component library. You bring your components; Livry supplies the values they render with.
  • Not a design tool. It competes with the theming system you would otherwise build in-house, not with Figma.
  • Not a reseller-facing editor. Your staff manage brands, through the portal or the API. If you want your customers editing their own brand, you build that against the API.
Livry is developer-first. There is no drop-in widget and no visual page builder. If your team already thinks in design tokens, it will feel familiar; if it does not, Tokens is the place to start.

​
Honest status

Livry is early. What is not built yet lists what exists, what is partial and what is still a plan — read it before you commit an integration to a date.