# Build-knowledge — accounts: creating one, and which door your install opens

The rule behind the table: password signup is open everywhere except the public platform. The deployment's role decides it, and an operator can override it with LEUMAS_PUBLIC_SIGNUP.


> There are exactly four ways an account comes into existence, and **which one is available is
> decided by the deployment, not by a setting you pick**. Knowing which kind of Leumas you are
> looking at answers almost every question about signing in.

## Which Leumas am I looking at?

| You are on | What it is | How you get an account |
|---|---|---|
| `leumas.tech` | The public platform, run by Leumas | **Continue with Google.** The password form is closed here |
| `studio.leumas.tech` | The same platform's Studio | The same Google account |
| **Leumas Studio on your own machine** | The desktop app — your own instance, your own database | The **first-run wizard**, then email + password for anyone you add |
| Your own server running Leumas | A self-hosted install | Same as the desktop app |

The rule behind the table: password signup is open **everywhere except the public platform**. The
deployment's role decides it, and an operator can override it with `LEUMAS_PUBLIC_SIGNUP`.

## Creating an account on leumas.tech

Use **Continue with Google**. There is no password form to find, and asking for one returns a refusal
that says so: *"Accounts here are created with Google — use 'Continue with Google'."*

Two things surprise people, and both are deliberate:

**You get a member account, never an admin one.** Signing in with Google grants exactly one role,
`user`. On a desktop install the first account becomes that install's administrator — but applying
that rule to a public platform would mean the first stranger to click the button owned the instance.

**Staff accounts cannot use Google at all.** An account holding `admin` or `leumas_staff` is
refused at the Google door — before any write, and before any cookie is set — and sent back with
`staff_password_only`. Those accounts sign in with a password. This is one-directional on purpose:
it stops a staff identity being reachable through an external provider.

Sign-in is also **origin-locked**. Only the platform's own front doors may start a Google sign-in;
a tenant's subdomain never can, and a guard asserts that refusal still happens.

Already have a password account from before Google sign-in existed? **Signing in still works.** Only
*signup* is closed on the platform, never login.

## Creating an account in Leumas Studio (your own copy)

The first time you open Studio it does not show you the app. It checks two things — whether this
install has a licence, and whether it has any accounts yet — and shows a first-run wizard until both
are answered. Which wizard you get depends on how the build was made:

**One step, if your Studio points at the Leumas platform.** Enter the email and password of your
leumas.tech account. Studio verifies it against the platform, saves the licence for this device, and
signs you in. There is no licence key to find and no second password to choose.

**Two steps, otherwise.** Enter a licence key in the form `LEUMAS-XXXX-XXXX-XXXX-XXXX`, then create
the local administrator. That account **lives only on that machine** and controls that Studio.

Either way the account you end up with is that instance's `admin`. Adding teammates afterwards uses
the ordinary email-and-password signup, which is open on a desktop install.

## What protects the first-run wizard

Only one thing, and it is worth understanding rather than trusting: **the wizard is available only
while the account table is completely empty.** The check is re-run inside the same transaction that
creates the account, so two people racing it cannot both win. Once one account exists, it is a hard
refusal for everyone — including whoever ran it: *"already set up — an account exists on this
instance."*

On the desktop app there is a second, stronger protection that is easy to miss: **the Studio API
binds to loopback only.** Nothing on the network can reach it, so "a stranger" would already have to
be sitting at your keyboard.

[warning] **That protection is a property of the desktop build, not of the wizard.** If you run the API
yourself on a public address with seeding disabled, the empty-table race is all that stands between
the internet and the first-run wizard, and the endpoint that reports "setup needed" is public. Bind
it to loopback, put it behind something that authenticates, or complete the wizard immediately.

Passwords must be at least ten characters. That is enforced on the wizard and on signup alike.

## The roles, and what they actually mean

| Role | Means | Granted by |
|---|---|---|
| `user` | A member | Every signup path |
| `admin` | **This instance's** administrator — not "Leumas the company" | The first-run wizard, or the boot seed |
| `leumas_staff` | The vendor axis: Leumas staff, on the control plane | The seed, and only on a control-plane deployment |
| `developer`, `verifier` | Narrower grants used by specific surfaces | — |

`admin` holds every permission that exists on its own instance. That is precisely why staff is
checked by **role** and never by permission — an instance administrator having "all permissions"
must not become a way to hold vendor authority.

`leumas_staff` refuses to be granted on any deployment that is not the control plane, and the
read-side check requires it too. A control-plane backup restored onto a customer's machine therefore
does not hand that customer a vendor account.

**There is no "promote a user to admin" screen, and no endpoint that grants a role.** The admin API
can list, read, patch and delete users, grant and revoke membership, and adjust tokens — but role
assignment happens at signup and at seed time only. If you need a second administrator today, that
is a gap, not a setting you have failed to find.

## Signing in from a site you host

A website served by Imperium on a Leumas subdomain is **same-origin with the API**, because the
worker forwards `/auth`, `/membership`, `/tokens` and `/entitlements` to it while preserving the
visitor's host and cookies. A page on your site can therefore read the visitor's session with no
configuration and no API key — which is the whole reason the hosting lane is shaped that way.

## Related

- [Imperium hosting](imperium-hosting.md) — putting a site on the internet once you have an account.


---
Source: shared/services/knowledge/build-knowledge/accounts.md
Canonical: https://docs.leumas.tech/p/how-to/accounts