TILLAUTH · OPERATE

auth.your-domain.com

Customer DNS, our certificate. The hosted-login page lives at your domain — end-users never see tilldev.app.

State machine

From tillauth_custom_domains.status:

  • pending — row created, owner hasn't published the TXT record yet.
  • verifying — background job is checking DNS.
  • verified — TXT record found; certificate provisioning has started.
  • active — cert is live, the domain serves your branded login page.
  • failed — TXT not visible after 24 hours, or cert provisioning failed. The last_error column says why.

Setup, step by step

  1. In the per-app Domains tab, click + Add domain, paste auth.your-domain.com. We persist a row with a random verification_token and show it.
  2. Add a TXT record on _tilldev.<your-domain> with the verification token as the value. Most DNS providers propagate within a few minutes.
  3. Add a CNAME on auth.your-domain.com pointing to <slug>.tilldev.app. (Apex domains aren't supported — use a subdomain.)
  4. Click Verify. We re-check DNS within seconds and transition pending → verifying → verified. Background cert provisioning starts immediately.
  5. When the cert is issued, activated_at fills in and the status flips to active. The hosted-login page now serves on your domain.

What runs on your domain

  • The hosted-login page — email + password, magic-link send/consume, OAuth start/callback, passkey UI. All branded with your app's Branding settings (logo, accent, copy).
  • The OAuth callback endpoint — Google + GitHub redirects land here. Update your OAuth client's authorized redirect URI tohttps://auth.your-domain.com/v1/oauth/<provider>/callbackbefore you cut over.
  • The OIDC callback endpoint — same pattern.
  • The JWKS endpoint at https://auth.your-domain.com/v1/apps/<public_id>/jwks.json. Your server-side verifier can use this URL instead of the tilldev.app one once the custom domain is active.

Cert lifecycle

  • Issued via ACME automatically. You don't upload anything.
  • Renewed ~30 days before expiry. If renewal fails for 5 consecutive attempts, you get an alert in the dashboard and the tillauth_custom_domains.last_error column fills in.
  • We pin the cert hash in our reverse proxy, so even if your DNS gets taken over, an attacker can't transparently swap the cert without tripping detection.

Removing a custom domain

Removing a custom domain from the app's Settings retires the cert and removes the record. The <slug>.tilldev.app URL keeps working. Active sessions are not invalidated — JWTs are app-scoped, not domain-scoped.

Limits

  • One custom domain per app, today. Multi-domain is on the roadmap for B2B-with-many-tenants use cases.
  • Apex domains aren't supported — use auth., login., or whatever subdomain.
  • Cert provisioning takes seconds to minutes. The dashboard surfaces a live progress badge.

Next: the React SDK · the Node SDK.