Serve sign-in from your own domain

By default your users sign in at a Base316 URL. On your own hostname — accounts.yourcompany.com — they never see somebody else's brand at the moment they are typing a password, which is also the moment they are most alert to anything that looks wrong.

Setting it up is two DNS records and a button. The work is in somebody else's DNS panel, so most of this page is about what to put there and what each thing is for.

Add the domain

In the dashboard, open the environment and go to Settings → Custom domain, and add your hostname under Custom domain. Base316 answers with two records.

They do different jobs and they fail differently.

The TXT record proves you control the name. Until it resolves, Base316 refuses to answer for the hostname at all — otherwise anyone could point a hostname they do not own at us and have a branded sign-in page served under it.

The CNAME sends traffic to us. Without it nothing reaches Base316 to be refused, so the page simply does not load.

Add both, then press Check DNS. Propagation is usually minutes and occasionally an hour; the panel shows when it last looked and what it saw.

Set a default redirect

This is the step people miss, and it is not optional.

A sign-in that starts on your own hostname carries no redirect_uri — accounts.yourcompany.com/hosted/sign-in with nothing in the query string is the whole point of the feature. Without somewhere to send people afterwards, they sign in successfully and stop on an error page.

Set Default redirect under Settings → Sign-in methods & design, to the same URL you would have passed as redirect_uri. It is checked against your allowed redirect URIs like any other destination, so add it to that list too.

Set Home page as well if you want the logo and "back" links to point at your application rather than at the sign-in page.

The certificate

You do not request one. Once DNS is verified, a certificate is issued for the hostname and the panel shows Issuing certificate until it answers. The page starts loading over HTTPS when that finishes.

Base316 never sees a private key for your domain — the certificate lives on the load balancer, and the only thing recorded against your environment is which certificate answers for the hostname.

What your users see

Everything hosted moves with the domain: sign-in, sign-up, the forgotten password flow, emailed sign-in links, the second-factor prompt and the account page. The links are listed under Settings → Hosted pages, and they update to your hostname once it is serving.

Your application does not change. It keeps the same issuer and discovery URL. When it sends somebody to Base316's authorize endpoint, and your domain is serving, the browser is moved to your domain before any page is shown, and the rest of the sign-in runs there. Signing out moves the same way, because that is where the session lives. Tokens are still issued by Base316's host, and your server's code exchange is unaffected.

Your branding — name, logo, colours — is already what those pages use. The domain changes the address bar, which is the part your users read without being asked to.

When it does not work

"Awaiting DNS" after several minutes: the TXT record is not resolving yet. Check it with dig TXT _base316-challenge.accounts.yourcompany.com — some DNS panels append the zone name to what you type, giving you _base316-challenge.accounts.yourcompany.com.yourcompany.com.

The page does not load at all: that is the CNAME, not the verification. Nothing is reaching us.

Signing in ends on "Nowhere to return you to": the default redirect is not set. See above — this is the commonest one.

The page loads but the certificate is untrusted: issuance has not finished. It does not need anything from you.

Removing it

Removing the domain returns sign-in to the default hostname immediately. Your users are not signed out, and nothing else changes — but any link you have published on the custom hostname stops working, so change those first.