Custom domains

On plans that include a custom domain, your sign in pages can live on your own subdomain, such as login.example.com, instead of acme.microauth.dev. People see your address in the browser, and your apps trust it as the issuer. HTTPS is set up for you. The pricing page shows which plans include it.

Add the domain

1. Open Branding and domain, enter the domain under Custom domain and click Add domain.

2. Add the two records the dashboard shows where your DNS is managed:

   Type	Name	Value
   CNAME	login.example.com	<slug>.microauth.dev
   TXT	_microauth.login.example.com	The token from the dashboard

3. Wait a few minutes. MicroAuth checks pending domains every 10 minutes, or click Check now, up to 20 times an hour.

The badge moves from Waiting for DNS to Issuing certificate, then to Live, usually within a couple of minutes. Only subdomains are supported.

Cloudflare

Set the CNAME to DNS only, the grey cloud. With the orange cloud on, Cloudflare hides the record and the certificate can't be issued.

Two addresses, two issuers

Your microauth.dev address keeps working after the domain is live. Each address is its own issuer: tokens name the address that issued them, and codes and refresh tokens only work at that address. Your apps should use one of them, and the custom domain is the one to pick once it's live.

Switch your apps

1. External sign in. At each provider, such as Google or GitHub, add the callback URL on the new domain next to the old one. The dashboard shows it on each connection.
2. Your apps. Set MICROAUTH_ISSUER=https://login.example.com and deploy. With another library, point it at the new discovery URL.
3. Your APIs and MCP servers. Change MICROAUTH_ISSUER there too, at the same time as the apps that call them, because tokens from the old address name the old issuer.

What people notice:

• They sign in again once, because their sessions and refresh tokens belong to the old address.
• Passkeys belong to the exact address they were made on, so passkeys made on acme.microauth.dev don't work on login.example.com. People sign in another way and add a new passkey. Passwords, external sign in and two step verification keep working.
• AI clients connected to your MCP server ask the person to connect again.

Removing the domain

Removing the custom domain sends your sign in pages back to the microauth.dev address, and links to the custom domain stop working. Switch your apps back to the microauth.dev issuer first. If your plan stops including a custom domain, the domain stops being served in the same way.