Skip to content
Zautha

Custom domains

A production instance serves sign-in from a subdomain of your own site, such as accounts.example.com. It is the instance’s Frontend API host: the SDKs talk to it, the hosted login pages live on it, and its session cookie is your domain’s, not Zautha’s.

Set it up

Section titled “Set it up”
  1. In the dashboard, choose Go to production on the application, or open the production instance’s Domains page, and enter the host. It must be a subdomain of a domain you own (apex and reserved explain the refusals).
  2. Add the CNAME record the dashboard shows at your DNS provider: your host, pointing at a target of the form {token}.frontend.zautha.com. The token is unique to this domain, so the record proves you control the host.
  3. Zautha checks the record by itself (every 10 minutes while the domain is pending), or at once with Verify now. Once it matches, the domain is active and Zautha gets its TLS certificate automatically.

A pending domain that is not verified within 7 days expires. To move to another host, add the new one: the active domain keeps serving until the new one is verified and replaces it.

An active domain is checked again every day. If its CNAME record no longer points at Zautha for 7 checks in a row, the domain is disabled and the workspace’s owners and admins are emailed with the record Zautha expects. Restore the record and it becomes active again at the next check.

Cookies and origins

Section titled “Cookies and origins”

The session lives in the __Host-zautha_client cookie, host-only on your Frontend API host and SameSite=Lax. Because the host is on your domain, your app (example.com, app.example.com) and the Frontend API are the same site: the cookie works without third-party cookies, and Zautha writes __Secure-zautha_client_uat on your domain so your servers know whether a session may exist. For the same reason, every https origin on your domain and its subdomains is an allowed origin of the instance; list any other origin in Auth settings — https only: a production instance refuses http origins, localhost included (use a development instance for local work), so its prefixed cookies (__Host-, __Secure-) are always set.

A development instance has no custom domain and sets no cookies on Zautha’s host: the SDK keeps the session itself (see Instances and environments).