Skip to content

Team & roles

Bring other people into your account and give each of them the right amount of access. This guide walks through it from the console. For the concepts, see Team & roles; for the endpoints, see the API reference.

Everything here lives under Account Settings - look for the Team, Roles, and API keys tabs (they sit alongside your profile, notification, and account tabs).

Invite a member

  1. Go to Account Settings -> Team.
  2. Click Invite Member and fill in their name, username, and email.
  3. Pick a role. If you are not sure, leave it on Read-only - you can change it later, and least privilege is a good default.
  4. Send it.

They get an email invitation, click the link, set their own password, and they are in. You never create or see a temporary password for them.

Off, not gone

Need to cut someone's access for a while? Disable them from the Team tab instead of removing them. Their account stays, their access stops, and you can switch them back on later.

Assign or change a role

Each member has exactly one role, and it decides what they can do. From Account Settings -> Team, open a member and change their role whenever you need to. The change takes effect on their next request.

Create a custom role

The four built-in roles (Full access, Developer, Read-only, Billing) cover the common cases. When you need something more specific:

  1. Go to Account Settings -> Roles.
  2. Click New role and give it a name and description.
  3. Choose the permissions it should have. They are grouped by resource (Pods, Domains, Billing, and so on) with actions under each: read, create, update, delete, plus a few special ones like console, ssl, and pay.
  4. Save, then assign it to members from the Team tab.

You can only grant permissions you hold yourself, so you cannot accidentally build a role more powerful than you are. The built-in roles cannot be edited - if one is close but not quite right, base a new custom role on it.

How API keys fit in

An API key is a credential for scripts and automation, and it carries permissions just like a member does:

  • A key's permissions are drawn from your own access - a key can never do something you cannot.
  • Create a key from Account Settings -> API keys, and scope it to just the permissions the job needs. Leave the scope empty for "everything I can do".
  • Some things are always off-limits to keys: managing the team, roles, and account settings. Those stay interactive, Owner-level actions. Automate the resources, not the org chart.

A good pattern: put a person on a tight role, and give their scripts an even tighter API key.

What each built-in role can do

RoleRough shape
Full accessEverything except managing team, roles, and account settings.
DeveloperPods, networking, domains, snapshots, backups, SSH keys, monitoring, support; read-only email and activity log.
Read-onlyView everything, change nothing.
BillingFull billing; read-only account.

Need the exact permission list behind each? It is in the API reference.

See also

Built for the long tail.