Reader sign-in on your own domain

Embed
Preview of the card
<a href="https://forumulate.com/guides/reader-sign-in-domain"><img src="https://forumulate.com/guides/_api/public/orgs/046a9bc0-d530-43ae-9bae-af7945008cda/spaces/36aa4df0-1e95-4cef-8ae9-795169441345/pages/0337bc79-05a3-4d1e-bf9d-6d091260466e/social-card.svg?v=3e7ae33eec8b" alt="Reader sign-in on your own domain" width="600" height="315"></a>

If you publish on your own custom domain (like docs.yourcompany.com) and you want readers to sign in there, this one setting makes the login smooth and first-party. If you're on a *.forumulate.com address, or your custom domain is public with no sign-in, you don't need this at all.

Why it exists

Browsers are strict about cookies. When a reader signs in on docs.yourcompany.com, the session cookie has to belong to yourcompany.com — otherwise the browser treats it as a third-party cookie and drops it, and sign-in silently breaks.

To set a first-party cookie, sign-in has to be served from a host on your domain. So you dedicate a small subdomain to it — for example readers.yourcompany.com — and point it at our identity edge. Sign-in then happens on your own domain, the session cookie is set on .yourcompany.com, and it's shared cleanly with docs.yourcompany.com.

Set it up

  1. Open your organization → Sign-in & auth → the Reader sign-in domain panel.

  2. Enter the host you want to use for sign-in, e.g. readers.yourcompany.com, and click Set up.

  3. We show you a single CNAME record to publish. It looks like:

    Type

    Name

    Target

    CNAME

    readers.yourcompany.com

    origin.atlasauth.net

  4. Add that record wherever you manage DNS for the domain.

  5. Back in the panel, click Verify DNS. Once the record resolves, the domain flips to Live.

That's the whole setup: one subdomain, one CNAME.

What happens once it's live

  • Reader sign-in on your custom domains is served from your own host.

  • The session cookie is issued on your parent domain (.yourcompany.com), so it's first-party and shared across your subdomains.

  • Nothing else changes for you or your readers — it just works, the way a login on your own site should.

It's safe to skip

This is an upgrade, not a requirement. Without it, a reader on a custom domain still gets signed in — just with a fallback session instead of a first-party cookie. Nothing breaks if you never set it up; the custom domain simply doesn't get the smoother first-party experience. Set it when you're ready.

Remove it

Use Remove in the panel to unbind the sign-in host. You can also delete the CNAME record from your DNS afterward.

Next: Sync readers into your own directory →

The Forumulate teamUpdated