Hosted portal appearance

The hosted portal renders in your brand rather than a Torii default. Four settings, per environment, under Project → Shrines → Customization:

Setting	Values	Effect
Color mode	Auto, Light, Dark	Which color scheme the pages render in. Auto follows the visitor’s system setting and tracks changes live.
Primary color	hex	Your brand color — buttons, links, focus rings, active states.
Background color	hex	The card background and the page behind it.
Hide the Torii footer	on / off	Drops the “Powered by Torii.so” footer under the card.

Each is optional. Leave a color unset and the SDK default applies. Settings are per environment, so you can try a color in sandbox before it reaches production.

Color mode and your two colors interact

Auto is the default and is usually what you want: the SDK ships both a light and a dark token set, and the pages follow the visitor’s OS preference.

If you set a background color, understand what it means in each mode — the color is applied literally, in both. A light background pinned while the visitor is in dark mode gives you a light card on a light page with dark-mode text tokens. If you set an explicit background, pin Color mode to match it rather than leaving it on Auto.

Primary color is safe in every mode; it is a brand accent, not a surface.

The Torii footer is plan-gated

Note

Hide the Torii footer is a request, not a guarantee. The server decides: footer removal is a Pro and above entitlement, and on the free plan the footer renders regardless of this setting. Nothing errors — the toggle simply has no effect until the plan allows it. Same rule as the SDK’s appearance.hideFooter; see customization overview.

What the hosted pages cannot do

These four knobs are the whole surface. The portal deliberately does not expose:

• Layout — the card is centered on the page; that is fixed.
• Element overrides — no per-element class or style injection.
• Custom labels — the pages use the built-in copy for the visitor’s locale. You cannot reword them.
• Custom fonts or CSS.

If you need any of those, mount <SignIn> in your own app instead, where the full theming and appearance surface is available. The two approaches are compared in hosted pages or your own UI — and you can use both, hosted pages for sign-in and your own UI elsewhere.

Checking your work

Every change applies on the next page load; there is nothing to deploy and no cache to clear. Project → Shrines → Overview has a View link that opens the live sign-in page for the selected environment — the fastest way to see a color land.

Test both schemes if you leave Color mode on Auto: your OS appearance setting is what the pages follow, so flipping it is the check.