Teams & project access

A role answers what someone may do. A team answers where. A contractor can be a deployer on the two projects their team owns and not know the others exist. Teams are free, like everything else here.

How it works

• A team is a name, a set of people, and a set of projects — all three editable at any time under Settings → Organization → Teams
• Every member has a project scope: organization (the default — sees every project) or teams (sees only the projects their teams reach)
• Nothing changes for anyone until you switch a member to the teams scope, so adding teams to a running install is safe
• Deny by default: a teams-scoped member who is in no team sees no projects at all
• Owners and admins administer the whole organization and cannot be scoped to teams — lower their role first
• You cannot change your own project scope; ask another admin, so nobody scopes themselves out of the projects they administer

What a hidden project looks like

Not found, never forbidden. A project outside a member's teams is indistinguishable from one that does not exist, for reads and for writes alike — otherwise the error code itself would confirm it is there. The same applies to everything inside it: applications, compose stacks, databases, domains, backups, schedules and the live event stream.

Roles still decide capabilities

A team never grants a capability. Someone who cannot deploy does not gain the ability by joining a team that owns a project, and the rank-bound capabilities (servers, Docker, organization settings, members) stay admin-only. Combine the two axes: the role sets the ceiling, the team sets the reach.

From the API

• team.all lists teams with their members and projects
• team.setMembers and team.setProjects replace either list wholesale
• team.setMemberScope switches one member between organization and teams
• All of them require members.manage, and every change writes an audit row