Identity and access

Signing in

Email and password against your own Supabase project, a session in an HTTP-only cookie, and a Studio auth provider instead of a hosted login.

Identity is Supabase Auth in the project the Deploy Button provisioned for you. There is no hosted login service in the path.

The flow

  1. A visitor opens /admin without a session and is sent to /login.
  2. They sign in with email and password against your Supabase project.
  3. The session is set as an HTTP-only cookie on your own origin.
  4. The Studio boots, asks the API who it is, and gets a user and a grants payload back.

The Studio's own auth provider was replaced for exactly this reason: the stock one expects a hosted service and a redirect dance that does not exist here.

The administrator

The first build creates one administrator — the address is fixed, the password is the one value you typed into the Deploy Button — confirms it, and never touches it again. Not on the next build, not on any later build. A build step that silently reset a password would be indistinguishable from an account takeover.

Adding people

An administrator can elevate an existing account from the Studio. New accounts arrive with the default role, which grants nothing at all until somebody does.

Tokens

There is no long-lived API token surface. Server-to-server work runs with the service credentials the deployment already has, inside the deployment; anything else uses a session.