Access groups

A member with the developer or viewer role can be limited to chosen projects. They see and use only what they, or one of their groups, are given. Everything else in the team does not exist for them: any route that names it answers 404, exactly as for something that is not there.

• Lists (apps, functions, databases, caches, buckets, alerts) show only their own.
• Any action on a project outside their access is 404: deployments, builds, logs, variables, crons, domains, observability and usage.
• Anything team-wide is 403: billing, members, the audit log, shared variables, support and making new resources.
• API keys this member makes, and keys made with those, are limited the same way; the MCP server and the CLI work with those keys. Builds they start also deploy with a limited key.
• A seat is what their role says: a developer, even a limited one, takes a seat; a viewer is free.

A group is a set of members. Each group gets one of two roles on an app, function, database, cache or bucket: developer (may change it) or viewer (reads only). A member in several groups, or with access of their own, keeps the highest role, but never above their own role in the team: a viewer given developer on a project is still a viewer.

Owners and admins (with step-up) make groups, add and remove members and give access. In the dashboard: Settings → Members (each member's role and limit), Settings → Access groups, and in a project Settings → Members, which shows who has access to it and through what.

An invite can also make the member limited and put them in groups; once they join they have that access.

All of it is in the API reference under “Access groups”: /v1/team/groups, /v1/team/members/<person>/access and …/<name>/members for each project. MCP tools: list_access_groups, get_access_group, create_access_group, delete_access_group, set_group_member, set_group_access, limit_member, project_access.