docs: Add Roles and permissions page for team accounts (DOCS-481) - #739
promptless[bot] wants to merge 2 commits into
Conversation
Add a dedicated accounts-billing/roles-and-permissions page documenting Runpod's four built-in team roles (Basic, Billing, Dev, Admin), a permissions matrix, how to assign a role when inviting a member, and offboarding guidance. Trim the duplicated roles/invite content from manage-accounts to a summary plus cross-links, and add the new page to the Accounts and billing nav.
![promptless[bot]](https://avatars.githubusercontent.com/in/979718?s=60&v=4){kind=small}
|
|
||
| The following matrix shows which permissions each role grants: | ||
|
|
||
| | Permission | Basic | Billing | Dev | Admin | |
There was a problem hiding this comment.
Permissions matrix on new page is moved verbatim from the pre-existing base-branch manage-accounts.mdx matrix; verified cell-for-cell identical across all 14 permission rows and 4 roles.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 59 to 74 in 7fc37cc
|
|
||
| ### Basic role | ||
|
|
||
| The Basic role provides essential access for users who need to work with existing resources without management capabilities. It allows users to access the team account and connect to already-deployed resources such as [Pods](/pods/overview), [Serverless endpoints](/serverless/overview), and [Instant Clusters](/instant-clusters). Users with this role cannot view billing information, start or stop Pods, or create new resources. |
There was a problem hiding this comment.
Basic role paragraph (can connect to existing Pods/Serverless/Instant Clusters; cannot view billing, start/stop Pods, or create resources) matches the Basic column of the base-branch permissions matrix.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 61 to 68 in 7fc37cc
|
|
||
| ### Billing role | ||
|
|
||
| The Billing role focuses exclusively on financial management. Users with this role can access billing information, manage payment methods, and view invoices, but they cannot access compute resources. This makes the role ideal for finance staff who need billing access without operational permissions. |
There was a problem hiding this comment.
Billing role paragraph (billing info, payment methods, invoices only, no compute access) matches the Billing column of the base-branch permissions matrix.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 69 to 70 in 7fc37cc
|
|
||
| ### Dev role | ||
|
|
||
| The Dev role extends the Basic permissions with additional capabilities for active development work. It includes all Basic permissions plus the ability to create, start, and stop Pods and manage [network volumes](/storage/network-volumes). Instant Cluster management (creating, deleting, starting, and stopping Instant Clusters) is reserved for the Admin role. Users with this role remain restricted from billing information and account settings. |
There was a problem hiding this comment.
Dev role paragraph (Basic + create/start/stop Pods + manage network volumes, Instant Cluster create/delete/start/stop reserved for Admin, no billing/settings) matches the Dev column of the base-branch matrix, including the Admin-only Instant Cluster row.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 63 to 67 in 7fc37cc
|
|
||
| ### Admin role | ||
|
|
||
| The Admin role provides full control over the account. Administrators can manage team members, configure account settings, handle billing, and control all compute resources. Reserve this role for trusted leads who need full account access. |
There was a problem hiding this comment.
Admin role paragraph (full control incl. members, settings, billing, all compute) matches the Admin column, which is checked for every row of the base-branch matrix.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 61 to 74 in 7fc37cc
|
|
||
| ## Assign a role to a team member | ||
|
|
||
| You assign a role when you invite a member to your team. The role you choose at invite time determines the member's permissions. |
There was a problem hiding this comment.
Invite/assign-role Steps block (Team page > Members > Invite New Member > choose role > enter email > Create Invite > copy link from Pending Invites) matches the pre-existing documented invite flow verbatim.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 38 to 42 in 7fc37cc
| Copy the generated invitation link from the **Pending Invites** section and share it with the person you want to invite. | ||
| </Step> | ||
| </Steps> | ||
|
|
There was a problem hiding this comment.
"Invitation links remain active until used or manually revoked" is carried over verbatim from the pre-existing manage-accounts.mdx text.
Source:
docs/accounts-billing/manage-accounts.mdx
Line 44 in 7fc37cc
|
|
||
| ## Remove access | ||
|
|
||
| You can revoke a pending invitation from the **Pending Invites** section before it is used. As part of general offboarding, review team membership regularly and revoke access that is no longer needed. |
There was a problem hiding this comment.
"Dissolve an entire team and revert to a personal account" links to #convert-to-a-team-account, which documents the Delete Team button described in the pre-existing base Note.
Source:
docs/accounts-billing/manage-accounts.mdx
Lines 24 to 28 in 7fc37cc
| This role allows users to access the team account and connect to already-deployed computing resources (e.g., Pods and Serverless endpoints) for development work. Users with this role cannot view billing information, start or stop Pods, or create new resources. | ||
|
|
||
| ### Billing role | ||
| Runpod team accounts provide four built-in roles (Basic, Billing, Dev, and Admin) that control access to Pods, Serverless endpoints, network volumes, and billing. Each role grants a different set of permissions. |
There was a problem hiding this comment.
Trimmed "four built-in roles (Basic, Billing, Dev, Admin)" summary matches the pre-existing "four distinct roles" claim; no new role model introduced.
Source:
docs/accounts-billing/manage-accounts.mdx
Line 57 in 7fc37cc
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Automations to automatically generate PRs for you. |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
jjmchew
left a comment
jjmchew
left a comment
There was a problem hiding this comment.
Thanks for pulling this together into a proper RBAC reference! 🙌 I checked the matrix against the enforced team-role grid in the backend and found two rows/statements that don't match what the code actually allows. Both predate this PR (carried over from manage-accounts.mdx), but since this page is becoming the source of truth, it's the ideal place to fix them. Details inline 👇
|
|
||
| ### Dev role | ||
|
|
||
| The Dev role extends the Basic permissions with additional capabilities for active development work. It includes all Basic permissions plus the ability to create, start, and stop Pods and manage [network volumes](/storage/network-volumes). Instant Cluster management (creating, deleting, starting, and stopping Instant Clusters) is reserved for the Admin role. Users with this role remain restricted from billing information and account settings. |
There was a problem hiding this comment.
Small correction here: Instant Cluster management isn't Admin-only — the Dev role has it too. In the backend, Dev has the same full create/delete/start/stop permissions for Instant Clusters as Admin.
Could we reword this sentence so it doesn't say the capability is "reserved for the Admin role"? Something like:
It includes all Basic permissions plus the ability to create, start, and stop Pods, manage network volumes, and create, start, stop, and delete Instant Clusters. Users with this role remain restricted from billing information and account settings.
(Pairs with the matrix row fix below.)
| | Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ | | ||
| | Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ | | ||
| | Connect to existing Instant Clusters | ✅ | ❌ | ✅ | ✅ | | ||
| | Create/delete/start/stop Instant Clusters | ❌ | ❌ | ❌ | ✅ | |
There was a problem hiding this comment.
To match the fix above — Dev should be ✅ for this row, not ❌. Dev and Admin have identical Instant Cluster permissions in the backend, so:
| Create/delete/start/stop Instant Clusters | ❌ | ❌ | ✅ | ✅ |
| | Connect to existing Pods | ✅ | ❌ | ✅ | ✅ | | ||
| | Create/delete/start/stop Pods | ❌ | ❌ | ✅ | ✅ | | ||
| | Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ | | ||
| | Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ | |
There was a problem hiding this comment.
One thing worth flagging on this row: sending requests to a Serverless endpoint is controlled by API key, not by a member's team role. Whether someone can call an endpoint depends on the API key they use, not on whether they're Basic/Dev/Admin — so a per-role ✅/❌ here can be a bit misleading (the answer is really "same for everyone").
My suggestion would be to drop this row, or add a short note that endpoint requests are governed by API-key access rather than console roles. Happy to help with the wording if useful! 🙂
2 participants
Open this suggestion in Promptless to view citations and reasoning process
Adds a dedicated "Roles and permissions" page under Accounts and billing so team admins have one authoritative reference for controlling member access, addressing Linear DOCS-481.
The new page covers why to use roles (least-privilege access, separating billing from technical operations), the four built-in roles (Basic, Billing, Dev, Admin) and what each can and can't do, the full permissions matrix, how to assign a role when inviting a member, and offboarding guidance. To avoid fragmenting RBAC coverage, the duplicated roles content and invite steps were trimmed from the existing Manage accounts page down to a short summary with cross-links, and the new page was added to the Accounts and billing navigation.
The draft is grounded in the role model Runpod already documents. Because DOCS-481 is marked "still in flux" with no confirmed spec, several requested topics were intentionally left out pending confirmation (see the suggestion's notes for the customer): the final launch role set, custom/granular roles, a roles-management API, changing an already-joined member's role in the console, and per-member removal of active members.
Files: accounts-billing/roles-and-permissions.mdx (new), accounts-billing/manage-accounts.mdx (trimmed), docs.json (nav).
Trigger Events
Tip: Enable auto-create PR in your Configuration to review suggestions directly in GitHub 🤖