Team & roles

MicroApps accounts are not single-player. You can invite other people, and control what each of them can do with roles.

Owner and members

• The Owner is whoever created the account. There is exactly one, and they can do everything. No permissions to configure, no role to assign - it is implicit.
• Everyone you invite is a Member. A member can do exactly what their assigned role allows, and nothing else. Invite someone without choosing a role and they get Read-only, which is the safe direction to be wrong in.

If you are a solo builder, you are the Owner and you will never think about any of this. It is here for when you are not solo.

Roles bundle permissions

A role is a named set of permissions - small resource:action grants like pods:read or billing:pay. A grant can also be a whole resource, pods:*, meaning every action on pods. Instead of ticking dozens of boxes per person, you build a role once ("Deployer", "Support handler", "Read-only auditor") and assign it.

Roles apply in two places:

• Members - each member has one role that defines their access.
• API keys - a key carries a set of permissions too, drawn from what its creator can do. Same permission model, different kind of credential.

Nobody can hand out access they do not have. A member with permission to manage roles still cannot create or edit a role that grants more than they themselves hold.

System roles

Every account comes with four ready-made roles you can assign right away:

Role	Can do
Full access	Everything except managing team members, roles, and account settings.
Developer	Full control of pods, networks, firewalls, domains, snapshots, backups, SSH keys, monitoring and support tickets; read-only on email and the activity log.
Read-only	Every read action and nothing else. Auditors, stakeholders, anyone who should look but not touch.
Billing	Full control of billing, including payments; read-only on account details and the activity log.

These four are read-only - you can assign them but not edit or delete them. When they do not fit, create your own custom role with exactly the permissions you want.

Sensitive actions

Most permissions are routine. Three are flagged as sensitive, and deserve a second thought before you hand them out:

• Console access (pods:console) - full terminal access inside a pod.
• Enable/disable SSL (domains:ssl) - issue and change certificates for your domains.
• Make payments (billing:pay) - top up credit, which means spending money.

Keep these on the roles that genuinely need them.

See also

• Team & roles API - the endpoints, the full permission catalogue, and the exact grants in each system role.
• Team & roles guide - a walkthrough from the console.
• API keys - how automation credentials inherit these same permissions.