Team members

Invite teammates to your SupaHost instance. What invited members can see, which actions stay with the owner, and how to give teammates' tools safe access.

You can invite teammates to your SupaHost account so they can see your instance and its projects. Today the model is simple: invited members can view, and the owner makes changes. This page spells out what that means in practice and how to work with it.

Invite someone

Open Dashboard → Team (under Account in the sidebar).
Enter their email address and pick a role: Developer, Admin or Read-only.
Send the invite. They get a team invite email with a link to join.

To take someone off the team, use Remove next to their name.

The role you pick is recorded with the invite, but at the moment every role has the same access: view only. Don't rely on the role label to grant or limit anything.

What members can and can't do

Action	Owner	Invited member
See the instance, projects and their settings	Yes	Yes
See Auth settings, functions, cron jobs, queues, backups	Yes	Yes (read-only)
See the Activity log	Yes	Yes
Open Studio	Yes	No
Reveal the `service_role` key	Yes	No
Create or delete projects and branches	Yes	No
Change Auth settings, providers and email templates	Yes	No
Deploy, edit or delete Edge Functions and secrets	Yes	No
Create cron jobs, enable Queues	Yes	No
Add custom domains	Yes	No
Back up now, restore, export	Yes	No
Add SSH keys	Yes	No
Change plan, add-ons and billing	Yes	No

Every write goes through the owner. These checks are enforced on the server, not just hidden in the interface.

Working as a team today

Because only the owner can make changes, teams usually split the work like this:

Schema changes go through migrations in git. Teammates write migration files and open pull requests. The owner, or an automated step the owner sets up, applies them. See Migrations workflow: local to SupaHost.
Day-to-day development happens locally. Each developer runs the Supabase CLI on their own machine, so they don't need write access to the hosted project. See Local development with the Supabase CLI.
AI tools get their own tokens. The owner can create a project-scoped, read-only access token for a teammate's Claude Code or Cursor setup, so their agent can list tables, read data and check advisors without being able to change anything:

{
  "mcpServers": {
    "supahost": {
      "type": "http",
      "url": "https://mcp.supahost.space/mcp?project=app-one&read_only=true",
      "headers": { "Authorization": "Bearer ${SUPAHOST_TOKEN}" }
    }
  }
}

Each person should get their own token, named after them, so it shows clearly in the Activity log and can be revoked on its own. See Access tokens.

Things not to do

Don't share the owner's login. New sign-ins send the owner a "new sign-in" security email, and a shared password can't be taken back from one person without changing it for everyone. If you think the login has been shared or exposed, change the password and use Log out everywhere in Settings.
Don't paste the service_role key into team chat so that someone can work around the view-only limit. It bypasses Row Level Security and can't be rotated. See Keeping keys safe.

When someone leaves

Remove them on the Team page.
Revoke any access tokens made for them on the Access tokens page.
If they had SSH access to a Business instance through a key you added, remove that key.
If they ever saw the service_role key, treat it as exposed. Keys can't be rotated on SupaHost, so read Rotating API keys and the JWT secret for your options.

Updated 11 November 2026 · View as Markdown · Something wrong or missing? Tell us