Skip to main content
This gets you from nothing to two visibly different brands rendering from the same application. Everything below happens in the developer portal at app.livry.dev.

1. Sign up

Go to app.livry.dev and enter your work email. Sign-in is passwordless — Livry emails you a code, and there is no password to choose. Signing up creates your Team and makes you its Owner.

2. Create a sandbox Environment

Signup does not create one. The welcome wizard asks for the first, and you should take the default: sandbox. The slug you choose becomes a URL segment, so /acme/sandbox/… is where you will be working. You are granted Admin on any Environment you create.
The Free plan allows exactly one sandbox Environment and no staging or production. See Plans and limits.

3. Create a Theme

Themes → New theme. Give it a slug and a display name, and pick your integration — the framework you build with and the library you style with.
The integration is not a label. It decides which files Livry builds for this Theme. Pick Plain CSS if you are unsure — it serves tokens.css, which is the zero-code integration and what the rest of this page uses. You can change it later on the Theme’s Integration tab.

4. Add some tokens

On the Theme’s Tokens tab, add a group and a couple of tokens. The minimum worth doing: The second one is an alias — it follows the first, and will follow it in every brand too. That is usually what you want: override one colour and everything derived from it moves. You can also import a file instead: DTCG, Tokens Studio, Figma Variables and Style Dictionary all work. See Importing tokens.

5. Publish the Theme

Publish on the Tokens tab. This freezes your draft as version 1 and builds the files. Nothing is served until you do this. A Theme with a draft and no published version has a serving URL that answers 404.

6. Add a Variant

Variants → New variant. Call it northwind. On its Overrides tab, override one token: Leave color.brand.hover alone — it is an alias, so it follows. Then Publish the Variant.
A Variant can be published once per Theme version. If you need to publish it again, publish the Theme first. See Versioning.

7. Render it

The Theme’s Integration tab shows your real URLs. They look like this:
Link one from your page:
Put the <link> before your own stylesheets. The custom properties have to be defined before the rules that reference them are evaluated on first paint, or you will see a flash of unstyled values.
Now reference the properties instead of writing values:
The fallback after the comma keeps your app styled if the stylesheet ever fails to load.

8. Switch brands

Call it with a different Variant id and every component restyles, with no re-render. Nothing in your app holds a value — only var() references — so the browser recomputes them when the stylesheet changes. Server-rendered? Pick the Variant per tenant (by hostname, say) and write the <link> with it.

Where to go next

Your framework

Tailwind, Chakra UI, or a build-time token pipeline instead of raw var().

Lock it down

Signed URLs, origin allowlists and IP ranges, before production.

Pin a version

Why you probably want /{n}/ rather than /latest/ in production.

Automate it

Everything above, through the REST API.