Cloud docs
Teams and people
Who a project belongs to, and what each role in a team can do.
Everything in the console belongs to a team. Projects, machines, disks, integrations and access tokens are all owned by one, and a person sees exactly what their teams own — nothing else. SSH keys are the exception: they belong to you, because you are the same person in every team you are in.
The team is in every console address — /{team}/projects/…, where {team} is
a short id the team was given when it was made — so a link always says which
team it belongs to.
If you belong to a single team, you will rarely notice it exists: the console fills it in for you and the field is not shown. It only becomes a choice once you belong to more than one.
#Roles
Roles are a ladder. Each one can do everything the roles below it can, plus its own.
| Role | Can |
|---|---|
| Viewer | See projects, environments, machines and their state. Changes nothing |
| Developer | Everything above, plus work on the sites: deploy, open a shell, edit variables, take and restore backups, and add staging or development environments where the subscription has room |
| Admin | Everything above, plus run the team: start projects and change their terms, resize and remove machines, delete environments, reset a database, switch the maintenance page on, change secret variables, manage integrations, notifications, people, invitations and the audit log |
| Owner | Everything above, plus the money: billing, invoices, cancelling, deleting a project, and making another owner. A team always keeps at least one |
The line worth knowing is between Viewer and Developer: it is the line between reading the console and changing what it runs. Developer is kept deliberately narrow, because it is the role you give an outside developer: it works on the sites and decides nothing for the team. Anything that spends money, removes something or changes who can do what is Admin and above.
A protected environment — production, unless you turned it off — needs the Owner for anything that reshapes or overwrites it, a restore included. Deploying to it stays ordinary Developer work.
#Adding somebody
Invite them by email address from the team's People page. They get a link, and they join with the role you chose — an invitation is a role, not just an opening.
An invitation you regret is withdrawn from the same page. A person you remove loses access immediately, including anything they had open.
#Only some projects
An invitation covers every project the team owns unless you say otherwise. When you invite somebody you can instead name the projects they should reach, which is what a contractor brought in for one site wants: everything a full member could do, inside those projects and nowhere else.
It narrows, never widens. The role still decides what somebody may do; this only decides where. A viewer named against every project is still a viewer. An Owner cannot be narrowed. What belongs to the team rather than to a project — the team itself, its keys and its billing — is untouched by it.
#How people are counted
The first person on a project is free. Everybody after that is counted per project — the configurator and the Commercial terms dialog quote what that comes to before you agree to it.
Counted for the people who can actually reach it, which is the point of narrowing an invitation: somebody brought in for one site moves the price of that site and no other. Somebody who works across the team counts everywhere, because they can work everywhere.
It was four bands by team size until September 2026, and the bands were worse than the thing they approximated — adding a fifth person cost nothing for four of them and then double for the fifth, at an edge nobody could see coming.
#Integrations
Services your team already pays for, connected once and used by any project: a log collector, storage for your backups, somewhere to send notifications, and an APM account — see Monitoring for what APM covers. Under your team's settings, and managed by Admins and Owners.
Each one carries whatever that service needs to know which account it is — a Datadog site, an Axiom dataset, a Loki endpoint — and its token. Tokens are encrypted and never shown again; you can replace one, but not read it back.
Why here and not on the project. One token is usually used by several projects, and it has to be rotated in one place. Putting it on the project means finding every project that had a copy the day the token changes.
Integrations covers what can be connected and what each one is used for.
#Audit log
Every change that costs money or alters access is recorded: machines bought and destroyed, disks grown, people added and removed, roles changed. Admins can read it from the team page.
It answers the question that comes up after something has gone wrong — when did this change, and who changed it — which is exactly the question nobody can answer from memory.
#Next
Projects covers what a team actually owns, Shell access covers the SSH keys you add, and The API covers access tokens.