White-label
White-labeling replaces the Aglyn brand everywhere your organization and its sites are shown: the console your team signs in to, the sites you publish, and the transactional email your members and customers receive.
It is one setting card, and the fields are short. The part worth reading closely is what each field actually replaces — a few of them change a surface you never look at yourself.
White-labeling is the whiteLabel entitlement. Exactly two plans carry it by
default: Agency and Enterprise. No lower tier does, and no add-on
buys it.
Entitlements can also be granted per organization on top of a plan's defaults, which is how an Enterprise agreement enables it for one organization — the card's own upgrade notice says so.
An organization that white-labels and then downgrades reverts cleanly: the stored brand is ignored, not deleted, and the Aglyn brand comes back everywhere at once. Upgrade again and the same values return.
Where the settings are
- Open your organization's Settings page — the heading reads Organization Settings.
- Choose the Branding tab.
- The card is White-label brand.
You need the admin role. The Branding tab is not shown at all to members below it, so a teammate who cannot find it is looking at a shorter tab strip than you are, not at a hidden card.
While your plan is still being read the card says "Checking your plan…". On a plan without the entitlement it shows an information notice instead of the editor: "White-labeling the platform is included on the Agency plan — see Billing to upgrade. Enterprise plans can enable it per organization."
The fields
Every field is optional. Leave one blank and it keeps the Aglyn default for that field — the grayed-out placeholder text in each box is that default, so a blank box is showing you exactly what will be used.
Two fields are the exception, and neither falls back to an Aglyn value: Support URL falls back to nothing, as its placeholder says, and Email logo URL to your product name, set as text. Leaving Support URL blank means no support link is shown anywhere — your customers are never sent to Aglyn's support desk, which could not help them and would name us to someone who was never told we exist.
| Field | Helper text under it | What it replaces |
|---|---|---|
| Product name | Shown in the console chrome, site badge, and emails. | The word "Aglyn" wherever the product names itself |
| Email from-name | Display name on transactional email (the verified sending address is unchanged). | The display name in the recipient's inbox |
| Support URL | Linked from branded surfaces and email footers. Leave it blank and no support link appears at all — your customers are never sent to Aglyn. | Where a "need help?" link points, or nothing |
| Primary color | CSS hex color used for the console primary and site badge. | The console's primary color, live |
| Logo URL | Console chrome + site badge. Browse the org media library or paste an https URL. | The Aglyn wordmark in the console header |
| Dark mode logo URL | Console chrome in dark mode, and the site badge, which always sits on a dark background. Leave it blank to use the logo above. | The logo above, wherever the ground is dark |
| Favicon URL | Browser tab icon for branded console surfaces. | The browser-tab icon |
| Dark mode favicon URL | Used when the visitor's browser is in dark mode. Leave it blank to use the favicon above. | The favicon above, in a dark browser |
| Email logo URL | Logo shown in transactional email headers (a hosted PNG works best). | Your product name, which heads your system email as text until a logo is set. See below |
| Custom console domain | Saved now; domain routing to it ships in a later phase. | Nothing yet. See below |
Every logo and favicon field carries a Browse button that opens your organization's media library, so you do not have to host the file yourself or paste a URL by hand.
Press Save brand. A confirmation reads "Brand settings saved".
Support URL must begin with https://, and every logo and favicon field
must be an https:// URL or an image picked from your media library. A plain http:// or a bare hostname is rejected by
name — "Logo URL must be an https:// URL" — rather than saved and quietly
ignored later.
Primary color must be a hex color: #1a73e8 or the three-digit #1ae.
Anything else is refused with "Primary color must be a hex color like
#1a73e8". Color names and rgb() are not accepted.
Where you will see the change
- Console header. Your Logo URL replaces the Aglyn wordmark, and your Dark mode logo URL takes its place when the console is in dark mode. Set a Product name but no logo and the name is rendered as text in the same place instead.
- Console theme and tab. Primary color and Favicon URL are applied to the page you are already on, so the change is visible without a reload.
- Published sites. The site badge and the site favicon follow the same brand. The badge is white text on a dark pill in both light and dark mode, so it shows your Dark mode logo URL when you set one. A site that sets its own favicon keeps it; otherwise the site uses your favicon, and your Dark mode favicon URL in a dark browser.
- Email stays on the light logo. Mail clients paint a light background and do not reliably honor dark mode, so Email logo URL has no dark partner.
- Site fingerprint. The
<meta name="generator">tag and thex-powered-byheader that otherwise credit Aglyn are suppressed on a white-label organization's published sites. This one is worth knowing about because it is invisible in a browser and is the part a technically curious visitor would otherwise read. - Transactional email. Covered in its own section next.
One counter-intuitive rule governs all of it: the branded chrome activates only once you have actually set a product name or a logo, not the moment your plan grants the entitlement. An Agency organization that has never opened this card keeps the plain Aglyn wordmark — there is no half-branded state and no flash of one brand turning into the other.
The email half
Email is where white-labeling used to leak, and it is the part that changed most recently.
Merge tokens
Every system email resolves three brand tokens, for every organization:
| Token | Resolves to |
|---|---|
{{brand.productName}} | Your Product name, or Aglyn |
{{brand.fromName}} | Your Email from-name, or Aglyn |
{{brand.supportUrl}} | Your Support URL, or empty |
They resolve on Aglyn's own organizations too, which is what lets one email template be correct for both populations instead of hard-coding the majority case. If your organization is not white-labeled, the tokens render the Aglyn values.
{{brand.supportUrl}} is the one that can render as nothing, and only for a
white-labeled organization that left the field blank. Aglyn's own support page
is never substituted — the email your customer receives reads as you
throughout, and a link to our desk in it would be the one thing on the page
that is not. Aglyn's built-in emails drop the whole "Need help?" line rather
than leave a dangling phrase; a template you design places the token yourself,
so put it somewhere a blank reads cleanly.
The email logo
Email logo URL renders as a centered header row at the top of the email body, above whatever the template itself lays out, inside the same 600-pixel column — so on a phone it scales with the message rather than floating against the viewport. Its height is capped rather than fixed, so a wide wordmark and a square mark both land at a sensible size without you supplying dimensions.
Two details are deliberate and quiet:
- A blank Email logo URL puts your product name there instead, in bold text — never Aglyn's logo, and never an empty row or a broken image. The same happens when the logo is set but cannot be fetched from an inbox.
- The image's
alttext is your product name. Most inboxes block remote images by default, so for a large share of recipients the alt text is the header. Setting Email logo URL without setting Product name gives those recipients a blank box where your identity should be.
There is no {{brand.logoUrl}} token, and that is on purpose: the logo is
structural, placed by the renderer, so a template can never forget to include
it or place it twice.
The email footer
Under the message, system email carries a short footer: a line saying why the recipient is getting it, which names your product — "You're receiving this because someone invited you to join Client Co on Acme Sites." — and a link to your Support URL, when you set one. There is no copyright or postal line. Aglyn's own mail carries Aglyn's; yours never shows Aglyn's name or address.
Aglyn's own mail can also carry a header and footer that staff design on the Aglyn marketing site. Mail to your organization's people always leaves those out and wears yours instead.
The sending address does not change
Email from-name changes the display name only. The address the mail is actually sent from stays the deployment's verified sending address, because that is what the receiving mail servers authenticate against.
Mail a site sends to its own visitors and members, such as receipts, booking confirmations and gift cards, leaves under that site's business name instead, so the reader sees the business they dealt with. The from-name is used for a site that has no name set, and for mail to your organization's people.
Known limitation: the custom console domain
Custom console domain is saved but does nothing yet, and the field says so in its own helper text: "Saved now; domain routing to it ships in a later phase." Your team still signs in at the standard console address.
Saving it is not entirely inert. The name is reserved for your organization when you save it, so nobody else can claim it in the meantime, and the reservation is released if you clear the field or change it to a different name. What has not shipped is the routing and certificate half — until that lands, a reservation is all the field buys, and pointing DNS at it achieves nothing.
Not the same as renaming a self-hosted platform
These two get confused constantly, and they are unrelated mechanisms:
| White-label brand | Platform brand | |
|---|---|---|
| Who sets it | An organization admin, in the console | Whoever runs the deployment, in its environment |
| Scope | That one organization | The entire installation, every organization on it |
| How | The card on this page | NEXT_PUBLIC_PLATFORM_BRAND_NAME and friends |
| Gated on | The whiteLabel entitlement | Nothing — it is deployment configuration |
| Takes effect | On save | On the next image build, not a restart |
If you are running Aglyn yourself and want the product to stop calling itself
Aglyn for everybody, that is the platform brand, not this card — see
Self-hosting. The two compose:
on a self-hosted installation, an organization without the whiteLabel
entitlement falls back to the operator's platform brand rather than to
Aglyn's.