---
title: "White-label and multi-tenancy"
description: "How one installation becomes your branded network — branding, themes, locales, domains, per-entity serving hosts, and the classic-to-new UI rollout mechanics."
type: "concept"
audience: [admin, network-manager]
keywords: [white label, branding, multi-tenancy, network, theme, locale, language, ad-serving domain, UI version, rollout]
ui_path: "Admin → Ad serving → White label preferences"
---

Fetch the complete documentation index at: https://epom.com/ad-server/docs/llms.txt. Use this file to discover all available pages before exploring further. Append .md to any documentation page URL to get its markdown version.

# White-label and multi-tenancy

An Epom Ad Server installation is *your network*: one platform instance, your domains,
your brand, your users. There is no separate "network" object to administer — a network
is the sum of its **white-label configuration** (what the platform looks like) and its
**ad-serving domains** (what it serves from), with the
[sharing and permission model](https://epom.com/ad-server/docs/concepts/sharing-permission-model.md) drawing the tenant
boundaries between the people inside it.

## What you control

Everything a client sees carries your network's identity, configured once in
[White label preferences](https://epom.com/ad-server/docs/guides/admin/white-label.md) and applied platform-wide:

| Area | What is overridable |
|---|---|
| **Identity** | Company name, website, contacts, founded year, social links, terms-of-use URL, support page URL |
| **Colour theme** | One of 20 preset palettes, each with a light *and* dark variant, plus per-colour fine-tuning per mode |
| **Images** | Logos and visuals for the account UI, emails, email reports, ad serving, favicon |
| **Language** | Default locale (15 available), and whether users may switch language on public pages and/or in their preferences |
| **Appearance defaults** | Default light/dark theme, default UI density, and whether visitors may change them on public pages |
| **UI version** | Which interface users land in — classic (the default) or new — and whether they may switch themselves |
| **Auth flows** | Hide sign-up (classic sign-in only), external sign-up / login / logout / forgot-password / set-password URLs, password policy at signup |
| **Ad-serving touches** | Branded placement overlay (text, colours, landing page), ad-serving domain redirect for bare hits, the `<AdSystem>` name in VAST responses |
| **Client-facing details** | Referral program naming, payment-details labels, email header colour, analytics decimal precision and top-N grouping |
| **API identity** | The network-level REST API key pair |

Two practical properties of this configuration:

- **It is global.** One installation carries one white-label configuration; every user of
  every role sees the same brand. Per-client differentiation happens through roles,
  shares and masking — not through per-client branding.
- **It is cached.** The servers keep white-label settings for about a minute, and the
  new UI additionally caches the theme in the browser for instant painting. A saved
  change can take a minute (or a reload) to appear everywhere; that is normal.

## Themes and language, mechanically

- The **colour theme** is applied for every user on top of their personal light/dark
  choice: the network administrator picks the palette, the user still picks the mode. The theme also
  covers anonymous pages, so the login screen is branded before anyone signs in.
- The **default locale** governs anonymous pages and new users. Each user's own language
  choice (where allowed) is stored on their account and remembered per browser for the
  login page. Both language-change toggles ship **off** — until an administrator enables them,
  users cannot switch language anywhere and everyone gets the default locale.

## Domains

Serving and UI hostnames are part of the tenant identity:

- A **system default ad-serving domain** is set in White label preferences; your own control-panel
  hostname is registered for your network by Epom support.
- Sites and advertisers can be served from a specific ad-serving host (without one they follow
  the system default) — the host decides which hostname appears in that entity's ad tags and
  tracking URLs. This is how one network runs several serving hostnames side by side (brand
  separation, cookie-scope separation, migration). To add a host or move sites and advertisers
  between hosts, ask Epom support or your account manager; see
  [Test pages and your ad-serving domain](https://epom.com/ad-server/docs/guides/admin/networks-and-domains.md).

## UI-version rollout (classic → new)

The platform ships two interfaces over the same data — the classic UI and the new UI — at
near-complete functional parity, the exception being a few newer controls that exist only in the
new UI (the placement's VAST version picker among them, which is why a
[viewability-measurable](https://epom.com/ad-server/docs/concepts/viewability-and-open-measurement.md) video tag has to be copied there).
You get a two-knob rollout:

1. **Default UI version** decides where a login lands when the user has expressed no
   preference: classic or new.
2. **Allow UI version switch on public pages** exposes switch controls — on the public pages and
   in the signed-in user menu — so users can move themselves. A user's switch is stored in an
   `epom-ui-version` cookie in their browser and **wins over the default** on later logins.

The mechanics enable a gradual rollout: keep the default on classic and allow switching
(early adopters opt in per browser); later flip the default to new (everyone lands in the
new UI, but anyone who switched back stays in classic on that browser); finally disable
switching once the migration is done. Because the preference is per browser rather than
per account, a user can be on the new UI at their desk and on classic on a spare laptop —
worth remembering when supporting users mid-rollout.

## Where the tenant boundary really is

White-label makes the platform *look* single-tenant to your clients; the actual isolation
between clients is enforced by the permission model:

- **Roles** trim features per client type ([Users and roles](https://epom.com/ad-server/docs/guides/admin/users-and-roles.md)).
- **Shares** scope each user to their own advertisers and sites.
- **Masking** anonymizes other parties' entities where clients must coexist on shared
  inventory without seeing each other's names.
- **Demo mode** ([Demo mode](https://epom.com/ad-server/docs/concepts/demo-mode.md)) adds a time-boxed trial flavour for prospects:
  demo-role users see shared example entities at *Can View*, and their account UI locks when the
  window ends.

> **Corner case:** the white-label configuration includes things clients receive *outside*
> the UI — report emails, notification templates, the branded overlay on served ads, and
> the referral program's naming. When rebranding, audit those surfaces too, not just the
> logo and theme.

> **Corner case:** the **REST API keys** tab holds the network-level key pair that signs the public
> registration calls, so changing it breaks every integration still using the old value.
> **Regenerate keys** replaces and saves both keys at once; typing a key and clicking **Save**
> replaces just that one. Treat the tab as a credentials rotation, not a cosmetic setting.

## Related

- [Configure white-label branding](https://epom.com/ad-server/docs/guides/admin/white-label.md)
- [Test pages and your ad-serving domain](https://epom.com/ad-server/docs/guides/admin/networks-and-domains.md)
- [Sharing and permission model](https://epom.com/ad-server/docs/concepts/sharing-permission-model.md)
- [Demo mode](https://epom.com/ad-server/docs/concepts/demo-mode.md)
- [User preferences](https://epom.com/ad-server/docs/guides/collaboration/preferences.md)