Login Branding & Custom Domains

Every tenant can fully brand the enterprise login page their users see — logo, colors, background, headline and supporting copy, and the feature highlights — and serve it on a custom domain. When a user opens the tenant's custom domain, the login page automatically loads that tenant's branding.

How it works

The login page resolves branding by hostname. When a request arrives on a tenant's configured custom domain, Beak matches it to the tenant and applies that tenant's branding, layered onto the platform default for any field left blank. With no matching domain, the platform default branding is shown.

A tenant's branding is composed from two layers, with the more specific value winning:

1. The platform default (the baseline every tenant inherits)
2. The tenant's own branding overrides

This means you only configure what differs from the default — everything else falls through to a sensible baseline.

Configure branding

1. Sign in to the admin console and open Branding.
2. Choose the scope:
   • Platform admins can edit the platform default (applies to every tenant that hasn't overridden a field) or any individual tenant.
   • Tenant admins edit their own tenant only.
3. Edit any of the fields below. A live preview of the login page updates as you type.
4. Click Save.

The preview is the login page itself, rendered at a desktop window size and scaled to fit beside the editor — not an approximation of it. What you see is what your users get, down to the type, spacing, and colors. Use the Light / Dark toggle above it to check the sign-in card in both modes; the strip above the preview shows the browser tab, so you can confirm your favicon and platform name there too.

Customizable fields

Area	What you can set
Identity	Platform name, a highlighted word within it (with its own color), tagline, version label, browser-tab favicon — see Platform name and highlight
Logos	Two uploads (PNG/SVG): a dark-background logo for the sign-in panel, and a light-background logo for the sign-in card in light mode — see Where your branding appears after sign-in
Typography	One text font applied to every piece of text on the login page — see Text font
Hero	Headline, a highlighted phrase within it (with its own color), and a supporting subtitle
Login card	Welcome title and subtitle
Background	A two-stop gradient (start/end colors), optionally overlaid with a full background image or a background video, at an adjustable transparency — see Background transparency
Colors	Accent/primary color, text color, secondary text color
Feature highlights	Any number of cards up to six — see Feature highlight cards
Login methods	Toggle password, SSO, and social sign-in options
Links	Terms and privacy URLs, shown beneath the sign-in card — see Terms and privacy links

Images can be uploaded directly (stored inline) or referenced by URL. Uploads are limited to 2 MB; PNG, SVG, JPEG, and ICO are supported. Background videos are limited to 8 MB; MP4, WebM, OGG, and MOV are supported.

Tip: Leave a field blank to inherit the platform default for it. Saving an empty field does not blank the login page — it falls through to the default. Feature highlight cards are the exception: they are a list you add to and remove from, so an empty list really does mean "no cards".

Feature highlight cards

Feature highlights are the cards stacked below the headline on the sign-in panel. They are a list — add cards, remove them, and edit each one independently.

In Branding > Feature Highlights:

• Add Feature appends a new blank card. You can have up to six; the button is disabled at the limit.
• Remove deletes that card. Removing every card is allowed — the sign-in panel then shows just the headline and subtitle.
• Each card has an Icon, a Title, and a Description. Pick the icon from the list (support, security, cloud, automation, and so on); it is shown next to the card's title on the login page.

The live preview updates as you edit, so the card list you see is exactly what users will get.

Note: Blanking a card's title does not remove it — use Remove. A card with neither a title nor a description is skipped when the login page renders.

Tenants that have never edited their feature cards keep showing the four default highlights. The first time you add, remove, or edit a card, the current four are captured as your starting list, so nothing is lost.

A card's two lines take their color from your palette, not from a fixed one:

• Title — uses the Text Color you set under Background.
• Description — uses the Secondary Text Color.

Set both so the cards stay legible against your background.

---

Platform name and highlight

Platform Name is shown on the sign-in panel beneath your logo, above the tagline. Highlighted Text tints part of it in Highlighted Color — enter a substring of the platform name exactly as it appears, including capitalization; a phrase that does not match leaves the name in one color.

Leave Platform Name blank and no name is drawn — the panel shows your logo and tagline alone. The name still sets the browser-tab title either way.

Text font

Branding > Platform Identity > Text Font sets one typeface for the whole login page — headline, feature cards, sign-in card, and footer all follow it. Pick from the supplied list; the live preview re-renders in the selected font so you can compare before saving. Leaving it unset keeps the default (Inter).

Background transparency

The gradient is always painted first. A background image or video, when you upload one, sits over it — so Background Transparency controls how much of the gradient shows through:

• 100% — the image or video alone, as before.
• Lower values — the media blends into your gradient colors.
• 0% — the gradient only.

The slider is disabled until an image or video is uploaded. An image and a video are mutually exclusive: remove one to upload the other.

Note: A background video is downloaded on every visit to the login page, so a large file slows the first (cold-cache) load. Keep it as small as the design allows.

Terms and privacy links

Terms URL and Privacy URL are rendered as Terms of Service and Privacy Policy beneath the sign-in card. Set either, both, or neither — each appears independently and nothing is shown when both are blank.

Each must be an https:// address or a path on the login domain itself (for example /privacy-policy). Any other value — including plain http:// — is ignored and no link is drawn, because the login page is served before a user has signed in.

---

Set a custom domain

1. Open the tenant (Platform Administration > Tenants) or use the tenant setup wizard.
2. In the Custom Domain field, enter the fully-qualified domain (e.g. login.acme.com).
3. Save. Beak displays the CNAME target to point your domain at.
4. Create a CNAME record at your DNS provider pointing your custom domain to the displayed target.
5. Once DNS propagates and the certificate is issued, the domain's SSL status changes from Pending to Active.

When users visit the custom domain, the login page loads automatically branded for that tenant — no additional configuration is required.

Signing in on a custom domain

A custom domain is one organization's front door, so the login page treats it as one. When someone enters their email address there, Beak looks them up only within the tenant that owns the domain:

• No organization picker. On the shared Beak login page, an address that belongs to more than one tenant is asked which one to sign in to. On a custom domain that question is already answered by the domain itself, so the user goes straight to their password or SSO provider.
• Other tenants are never listed. A person who also has an account elsewhere in Beak sees no trace of it here. Your login page never reveals where else that address is registered.
• An address with no account in this tenant cannot sign in here. The page reports that no account was found, rather than offering a different tenant. Users with accounts in several tenants reach each one through its own domain, or through the shared Beak login page.

This applies to a domain set on a company as well as one set on a tenant — a company's domain resolves to the tenant that owns the company.

Note: The shared platform login page is unchanged. It still asks which organization to sign in to when an address belongs to more than one, because no domain has made that choice there.

How applications are addressed on a custom domain

A custom domain does more than brand the login page: the applications follow it automatically. There is nothing to configure per application.

Every Beak application is served as a path — /aistudio/, /aihub/, /itsm/ — so a single hostname carries the whole portfolio. Setting the domain once moves every product onto it:

	Beak AI Studio	Beak Hub
Platform default	https://platform.beakops.com/aistudio/	https://platform.beakops.com/aihub/
With beak.acme.com	https://beak.acme.com/aistudio/	https://beak.acme.com/aihub/

Only the host changes. Each application keeps the path that identifies it, which is what lets one domain serve them all — and it is why no per-application setting is needed.

Which domain an application uses

Beak picks the most specific domain available to the person signing in:

• The company domain — the custom_domain on the user's company, if it has one. Where a tenant has several companies on different domains, each company's users get their own.
• The tenant domain — used when the company has no domain of its own.
• The platform host — used when neither is set. This is the default for most tenants, and nothing changes for them.

Because the company is a property of the user, two people in the same tenant can be sent to different domains — each to the one their own company owns.

Signing out returns to the same domain

Signing out of any product follows the same order. Someone who signed in on their company's domain is returned to that login page, not to the tenant's and not to the product's own — so the brand they arrived on is the brand they leave on.

Products decide where to send a user at sign-out from a value Beak returns with the sign-out response, rather than from a list of hosts built into the product. That is what allows a domain you own to work at all here: the set of valid destinations is per-customer, so no product could recognise yours in advance.

Note: A product must be new enough to read that value. An older one falls back to its own sign-out page, which is the behaviour it has today — nothing breaks, the user simply lands somewhere less branded.

Applications that keep their own hostname

A few products are served at the root of a hostname of their own rather than under a path — Beak ELM, Beak FinOps and Beak M365 Lite. They have no path to distinguish them, and the root of a custom domain is already the login page, so these keep their own address on every tenant. They are unaffected by a custom domain.

Note: A custom domain changes the link only. The domain must also route the application paths, exactly as the platform host does. Until that routing is in place the address resolves to the login page instead of the application — the link appears to work, but the wrong page is served. Confirm one application opens on the domain before rolling it out to users.

Where your branding appears after sign-in

Branding does not stop at the login page.

• The sign-in card carries your logo. The card itself shows the logo at every screen size, picked to suit the card's own light or dark surface. Both variants are set in Branding > Custom Logos: the light-background logo is used on the card in light mode, the dark-background logo on the sign-in panel and on the card in dark mode. Upload both so the mark stays legible either way — with only one uploaded that one is used on both surfaces, and with neither the default Beak wordmark is shown.
• The module selector names your company. After signing in, the header on the module-select screen labels the session with the company that owns the domain the user arrived on — the same company whose logo and colors they are seeing. Where a domain is not tied to a company, the tenant name is shown instead.

Sign-in buttons on a company domain

The hostname that selects a company's branding also selects the identity providers offered on its login card. Where a company has its own SSO configured, its users get a Continue with … button and never type an email address or a password. See Company SSO & Sign-In Buttons.

Notes

• Branding applies to the enterprise login page; the admin console login uses the same platform-default identity settings.
• Custom CSS is not served to the public login page (it is intentionally excluded for security).
• Changes are picked up on the next page load; the public branding response is briefly cached (about a minute) at the edge.