Team, roles and permissions
Who is in the organization, what each role reaches, who may spend money in the cloud, and how new people join.
- Reading time
- 3 min read
- Who
- Owner
How it works
Access is a person's role plus a workspace's assignees:
| Role | Workspaces they reach | Also |
|---|---|---|
| Owner | Every workspace in the organization | Roles, invite codes, API keys, organization settings |
| Maintainer | Every workspace in the organization | Chooses which show on their own board |
| Member | Only the workspaces they are assigned to, plus any they created | , |
The rule lives in one place and is applied to the query itself rather than checked after an object has been fetched, so a member asking for someone else's workspace by id gets a plain "not found", and no screen can leak one by forgetting a check. The same rule guards the two things that are not JSON: the box's terminal, and the chat socket. A member kept out of a workspace's API but able to reach its box would not be kept out of it at all.
Anyone on a workspace can change its assignees. That is not weaker than it looks: the only people it grants access to are members, being invited onto a workspace by somebody already on it.
Can manage deployments
This is a separate flag, and no role implies it, not even owner. "Owners and maintainers" would make "who can deploy to production?" a question with two answers that drift apart, and it would bind a decision about trusting somebody with infrastructure to a decision about workspace visibility. A maintainer who reaches every workspace is not automatically the person you want spending money in the AWS account; the person who actually looks after the boxes is often not an owner.
It gates Apps and run recipes, App databases and their seeds, the organization's deploy settings, cloud accounts and provider integrations, where an environment points and its update script, and deploying or stopping anywhere but DevBench compute. Reads are gated too, letting everyone read an App's seed data while only some may change it would be a strange place to draw the line.
Two things stay open to everybody: DevBench compute previews (throwaway, free, reaching nobody, the test loop the whole team works in), and an environment's URL, login and notes (the team's shared record of a running system; a card the team cannot keep current stops being true).
An owner may grant it to themselves. That is the intended way an organization gets its first person who can deploy to production.
Invite codes
A code is how somebody joins. It carries the role they join as, and can have an expiry and a use limit. No emails are involved, you hand over the code.
Steps
Open Team from the organization's menu at the top left (or the search: Ctrl Ctrl, ⌘ ⌘ on a Mac). It opens as a tab where you are.
Set each person's role with the Owner / Maintainer / Member buttons on their row.
Tick Manages deploys for the people who look after your infrastructure.
That is Can manage deployments. No role gives it on its own, and every member can still deploy a preview.
Press Generate code under Invite codes to make an invite.
Choose the role it joins as.
Press Copy and send the code to your teammate.
They paste it at sign-up.
Press Revoke on a code once it has done its job.
Worth knowing
You cannot change your own role, that is what stops an organization losing its last owner by accident.
Repeated refusals at the container or chat gate, five for one person on one workspace inside 15 minutes, notify the owners once. A workspace accidentally hidden from someone looks identical, from the server's side, to somebody trying ids at random.