# 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.

Source: https://supahost.app/docs/platform/team · Updated 2026-11-11

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

1. Open **Dashboard → Team** (under Account in the sidebar).
2. Enter their email address and pick a role: **Developer**, **Admin** or **Read-only**.
3. 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](/docs/local-development/migrations-workflow).
- **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](/docs/local-development/overview).
- **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:

```json
{
  "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](/docs/platform/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](/docs/security/api-key-safety).

## When someone leaves

1. **Remove** them on the Team page.
2. **Revoke** any access tokens made for them on the Access tokens page.
3. If they had SSH access to a Business instance through a key you added, remove that key.
4. 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](/kb/rotating-jwt-secret) for your options.

## Related

- [Access tokens](/docs/platform/access-tokens)
- [Shared responsibility](/docs/security/shared-responsibility)
- [Production checklist](/docs/security/production-checklist)