Skip to main content
Accounts are the human half of identity: an email and password, a session, and a role. The tai42-accounts-postgres plugin provides them — it stores email/password accounts on Postgres, mints sessions, drives invites, and contributes the Studio’s Users screen.

Postgres accounts

Install and wire the store, run its migrations, create the first admin, and invite the team — with the TAI_ACCOUNTS_* session and login-limit settings.

​
What every accounts deployment shares

  • Accounts ride on access control. Turn it on (ACCESS_CONTROL_ENABLE=true) and name the provider in ACCESS_CONTROL_AUTH_PROVIDERS. Keep redis in the list so minted API keys keep working next to human sessions.
  • A sign-in does not provision authority. A logged-in human resolves to a user id, and until a policy exists for that id every protected route denies the request. Provision the policy first, then invite the person — the access-control guide writes the jq policy end to end.
  • Provider order matters. Members of ACCESS_CONTROL_AUTH_PROVIDERS are tried in order and fail closed: an outage in an earlier member denies the members after it.
  • Every admin principal counts. The platform keeps at least one enabled admin principal — an account on the admin role, the owner from setup, an admin service principal — and refuses the change that would leave none. Demoting your last admin account is allowed while the owner is still enabled. See the last enabled admin stays.
  • A member’s role is read from access control. The Members page shows the role every login of the member holds, No role when that member’s access was set directly rather than from a role, or Mixed roles with each login’s own role when the member’s logins hold different roles. A provider’s change-role action gives every login of the member one role, which clears it.

​
See also