Roles and permissions
Every membership carries one of two roles: admin or member. There are no custom roles and no per-resource permissions. The role applies to one organization — you can be an admin in one and a member in another.
The short version: admins control money and membership, members control compute.
Permission matrix
| Area | Action | Admin | Member |
|---|---|---|---|
| Billing | View balance, transactions, and daily spend | Yes | Yes |
| Billing | Add credits with 支付宝 (Alipay) or 微信支付 (WeChat Pay) | Yes | No |
| Invites | Create an invite link | Yes | No |
| Invites | List pending invites | Yes | No |
| Invites | Revoke an invite | Yes | No |
| Members | View the member list | Yes | Yes |
| Members | Change another member's role | Yes | No |
| Members | Remove a member | Yes | No |
| Members | Rename the organization | Yes | No |
| Instances | Deploy a new instance | Yes | Yes |
| Instances | Start and stop any instance in the org | Yes | Yes |
| Instances | Destroy any instance in the org | Yes | Yes |
| Instances | Read logs and connection details | Yes | Yes |
| Templates | Create, edit, and delete the org's templates | Yes | Yes |
| Templates | Duplicate a system, public, or org template | Yes | Yes |
| API keys | View the org's keys, their prefixes and creators | Yes | Yes |
| API keys | Create a personal key | Yes | Yes |
| API keys | Create a team key | Yes | No |
| API keys | Revoke their own personal key | Yes | Yes |
| API keys | Revoke any key in the org | Yes | No |
| Usage log | Read the organization's usage log | Yes | Yes |
| SSH keys | Add or remove keys on their own account | Yes | Yes |
SSH keys sit outside the role system entirely: they belong to a user, not to an organization, and no role grants access to anyone else's. See Switching organizations.
What members can do that surprises people
A member is not a read-only observer. A member can:
- Deploy, which starts spending the organization's shared prepaid balance immediately.
- Destroy any instance in the organization, including one an admin created. Destroying deletes the disk permanently — see Stop vs destroy.
- Edit or delete any template the organization owns, which changes what teammates launch next.
Invite people as members when you are comfortable with all three.
What only admins can do
Admins hold the two things members cannot touch: the money and the roster.
- Adding credits, that is, paying by QR code with 支付宝 or 微信支付. A member who tries to deploy with an empty balance sees a prompt to ask an admin instead of a payment button. See Adding credits.
- Creating, listing, and revoking invites.
- Promoting, demoting, and removing members, and renaming the organization.
Everything else on the matrix is open to both roles.
Changing someone's role
On the Team page, use the role selector next to a member's row. The change applies to their next request; an open console picks it up on its next refresh.
You cannot change your own row — your role shows as a badge instead of a selector. Ask another admin if you need to be demoted.
Removing a member
The remove control sits at the end of each member's row. The person loses access to the organization's instances, templates, keys, and usage log at once, and the organization disappears from their workspace switcher. Their own SSH keys and their personal workspace are untouched.
Removal also revokes the personal keys they created in this organization, at once. As a backstop, a personal key re-checks on every request that its creator is still a member, so any of them answers 401 TOKEN_INVALID after the removal. Team keys are not affected: they belong to the organization and keep working after their creator leaves.
A script or CI job wired to a colleague's personal key stops working the moment they are removed from the organization. Give shared automation a team key (only an admin can create one). A team key acts for the organization, not for the admin who created it. Deploys through it can attach the SSH key of anyone who is a member now and of no one who has left — the key's creator included — and an instance deployed with it names the key, not a person, in deployed_by. The key itself survives its creator's departure, but they were shown its secret once and may still have a copy: the API Keys page marks such a key creator left (创建者已离开). Have a current admin create a replacement, switch to it, and revoke the old one.
The last admin
An organization always keeps at least one admin. Removing the final admin, or demoting them to member, fails with LAST_ADMIN and the error "An organization needs at least one admin". Promote someone else first.
API keys always act as members
An API key carries member-level access to the organization that created it, no matter who created it. Admin actions — billing, invites, member management, minting or revoking other keys — are rejected on an shk_ token with ADMIN_REQUIRED. Those calls need a signed-in session.
Team keys and personal keys carry the same privilege, never more than a member's. They differ in who manages them and how long they last: a team key is admin-managed and outlives its creator's membership; a personal key belongs to its creator and is revoked when they are removed from the organization. See API keys.
Personal workspaces
Your personal workspace has exactly one member — you, as admin. It cannot be invited into and cannot hold a team. Attempting to create an invite there returns PERSONAL_ORG. Create a real organization when you need a second person.