Separate sign-ins
There are several places you might sign in on CTXR: the account app at account.ctxr.app, the onboard wizard at onboard.ctxr.app, and any space at its own yourname.ctxr.app. A reasonable assumption is that one login carries you across all of them. It doesn’t — and that is a deliberate design choice, not a missing feature.
The way you sign in is identical everywhere. The session you get is not shared. Each place checks you in on its own.
One mechanism, many doors
Every sign-in across the platform works the same passwordless way: a six-digit code arrives at your email, and after you enter it you hold a short-lived session for that one place. The full mechanism — single-use codes, session tokens, the one actor model — is described in Access & permissions.
That sameness is a convenience for you to learn once. It is not a shared account behind the scenes. Signing in to your account does not sign you in to a space; signing in to one space does not sign you in to another. There is no single session that the whole platform trusts.
| When you sign in to… | it checks your email against… | and gives you… |
|---|---|---|
your account (account.ctxr.app) | the platform’s account registry | a dashboard of the spaces tied to your email |
onboard (onboard.ctxr.app) | a fresh verification of the email you’re onboarding with | the right to create a space and attach it |
a space (yourname.ctxr.app) | that space’s own list of editors | an editing session in that one space |
Each row is its own door with its own lock. None of them hands you a key to the others.
Why they’re kept apart
This follows directly from the platform’s first principle — isolation as architecture. Every tenant, whether a space, the account app, or a management module, is its own boundary with its own data and its own actors. Authentication lives inside that boundary like everything else.
Centralising login would mean a single identity service that every tenant has to trust — one thing to breach, one session that, if stolen, reaches everywhere, one cross-tenant lookup that could leak who has access to what. Keeping sign-in local to each boundary removes that shape entirely. A session for one space is meaningless to another. There is no master key, because there is no master door.
The trade is intentional: a little more signing in, in exchange for no single point that, once defeated, opens the whole platform.
You don’t need a platform account to collaborate
This is the part that surprises people most. To edit a space alongside others, you do not need an account at account.ctxr.app. You need to be an editor in that space: an entry holding your email and a set of permissions, created when the space’s owner invites you.
When you sign in, the space matches your email against its own editors and emails you a code. It never asks the account layer whether you exist — the account layer isn’t part of the question. An account is a separate convenience that gives you one dashboard over every space linked to your email; it is not a prerequisite for doing the work. Many editors collaborate on a space without ever creating one.
The difference between holding an account, owning a space, and merely following along is drawn out in Owning vs following.
The one place the islands meet
There is a single, deliberate point where one of these stands reaches into another: onboarding a space and attaching it to your account.
When you create a space and want it to appear under your account, the email you verify during onboarding has to match your CTXR account — same email, same identity. If the email is new to the platform, an account is created for you at that moment so the new space has something to attach to. Either way, that email match is the link between the space and your identity.
That is the only crossing. Everywhere else the boundaries simply hold, which is exactly what makes them trustworthy. How that coupling plays out step by step is covered in the quick start — Getting an account and Onboarding a space.