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

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?

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

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 — putting a site on the internet once you have an account.