Custom domains

By default your Production sign-in happens on an Atlas host. A custom domain moves it onto a subdomain of your own — for example accounts.yourapp.com — so the URL bar, cookies and branding are all yours end to end.

Why a custom domain matters

• Trust — users stay on your domain through sign-in; no jarring redirect to a third-party host.

• Cookies — the session lives on your domain, which matters for same-site behavior.

• Passkeys/WebAuthn — credentials are bound to a domain, so a stable custom domain gives your users durable passkeys.

The two roles

A custom domain is claimed for a specific role:

• Frontend API (FAPI) host — where the SDK and hosted pages talk to Atlas (e.g. accounts.yourapp.com).

• Hosted-pages host — where the hosted sign-in/account UI is served.

Custom domains must be subdomains (a subdomain you control), not bare apex domains.

Set one up

1. Open Customization → Domains and choose Add domain.

2. Enter the subdomain and pick its role (FAPI or hosted pages).

3. Atlas gives you a CNAME record to publish in your DNS, pointing the subdomain at Atlas.

4. Publish the CNAME with your DNS provider.

5. Back in the dashboard, Verify — Atlas checks what DNS actually returns and records it. It also runs a cookie-domain check so the session cookie will be valid on the domain.

6. Atlas provisions TLS for the domain; the dashboard shows the certificate status as it goes live.

Safeguards

• A live production FAPI host can't be removed — pulling it would instantly break every signed-in session and sign-in attempt. Migrate deliberately.

• Until DNS and TLS are confirmed, the domain stays pending and the existing host keeps serving, so a half-finished change never takes users offline.

After it's live

Update your app's SDK configuration (the frontendApi/publishable-key host and JWKS/issuer URLs) to the new domain, and reproduce it in Production only — Development can keep using the default host.

Next

Speak your users' language → Localization.