From 806dbb99f9d72ce56a08ae5145a3c48ce1b3f635 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:46:22 -0400 Subject: [PATCH 01/44] Create overview.mdx --- organizations/overview.mdx | 64 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 organizations/overview.mdx diff --git a/organizations/overview.mdx b/organizations/overview.mdx new file mode 100644 index 000000000..7356430fa --- /dev/null +++ b/organizations/overview.mdx @@ -0,0 +1,64 @@ +--- +title: "Organizations" +sidebarTitle: "Overview" +description: "Manage enterprise GPU workloads with centralized billing, access control, and resource ownership." +--- + +Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an Organization is a first-class entity that owns all resources — compute, storage, secrets, and templates — independent of any individual user. + + + Organizations are currently in internal alpha and are available to enterprise customers via Runpod sales. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). + + +## How Organizations differ from Teams + +| | Teams | Organizations | +|---|---|---| +| **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the Organization — survive if any member leaves | +| **Billing** | Prepaid credit balance | Post-paid invoice only | +| **Membership** | A user can own one team and belong to others | A user belongs to at most one Organization | +| **Social unit** | Team (has an owner) | Group (leaderless, additive) | +| **Mutual exclusivity** | Compatible with personal accounts | Joining an Org permanently removes Team access — irreversible | + + + Teams and Organizations are mutually exclusive — permanently. Once a user joins an Organization, there is no path back to Team membership. This is enforced at the data layer and cannot be undone. + + +## Key concepts + +**Ownership** — All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is suspended or removed, their resources keep running and remain accessible to other members. + +**Membership** — A user may belong to at most one Organization. Joining an Organization folds your existing personal resources (Pods, templates, secrets, and more) into the Organization permanently. These resources cannot be reclaimed if you leave. + +**Roles** — Four roles control what members can do: admin, billing, dev, and basic. There is no owner role — admin is the top level. See [Roles](/organizations/roles). + +**Groups** — Groups are the intra-org social unit, replacing Teams within an Organization. Groups are leaderless and additive — a user can belong to zero or many groups. See [Groups](/organizations/groups). + +**Billing** — Organizations use post-paid invoicing only. There is no credit balance, no credit top-up, and no payment method management in the console. See [Billing](/organizations/billing). + +**Access** — Org admins control how users authenticate: SSO, ad-hoc email invitations, or both. Admins can restrict access by email domain or IP range. See [Access and SSO](/organizations/access). + +**Resource tagging** — Tags are key-value pairs attached to resources for cost attribution and filtering. See [Resource tagging](/organizations/resource-tagging). + +## Get started + + + + Understand what each role can do + + + Organize members within your Organization + + + How post-paid invoicing works + + + Configure SSO, invitations, and IP allowlists + + + Tag resources for cost attribution + + + Move your Team account to an Organization + + From 067ffa0d9517e06f96b2d2c54d26ee108245ff0f Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:48:46 -0400 Subject: [PATCH 02/44] Create roles --- organizations/roles | 39 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 organizations/roles diff --git a/organizations/roles b/organizations/roles new file mode 100644 index 000000000..d41e604a5 --- /dev/null +++ b/organizations/roles @@ -0,0 +1,39 @@ +--- +title: "Roles" +sidebarTitle: "Roles" +description: "Control what Organization members can do with four role levels." +--- + +Every member of an Organization is assigned one of four roles. Roles control access to org management actions — there is no owner role. Admin is the highest level. + +## Role overview + +| Role | Manage members & groups | Manage billing & cost centers | Create & manage resources | Use existing resources | +|---|---|---|---|---| +| **Admin** | ✓ | ✓ | ✓ | ✓ | +| **Billing** | — | ✓ | — | ✓ | +| **Dev** | — | — | ✓ | ✓ | +| **Basic** | — | — | — | ✓ | + +## Role descriptions + +**Admin** — Full organization management plus all dev permissions. Admins can invite and remove members, create and manage groups, configure SSO and access settings, manage the IP allowlist, and create or manage any computing resource. + +**Billing** — Can create, update, and delete cost center labels for resource attribution. Cannot create or manage computing resources, and cannot manage members or groups. + +**Dev** — Can create and manage computing resources: Pods, serverless endpoints, network volumes, clusters, and templates. Cannot manage members, groups, or billing configuration. + +**Basic** — Can access and use existing org resources. Cannot create new resources. + +## Resource access in MVP + +In the current release, roles gate org-management actions only. All org members — regardless of role — can list, use, modify, and stop any org-owned resource. Resource-level access control (RBAC) is planned for H2 2026. + +## Assigning roles + +Only org admins can assign or change member roles. To update a member's role: + +1. Go to **Settings → Members** in the console. +2. Find the member and click the role dropdown next to their name. +3. Select the new role and confirm. +Role changes take effect immediately. From 865d3ddfa4201e4cb208fb472369c1d9728e5e84 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:49:15 -0400 Subject: [PATCH 03/44] Create groups --- organizations/groups | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) create mode 100644 organizations/groups diff --git a/organizations/groups b/organizations/groups new file mode 100644 index 000000000..7eaafa233 --- /dev/null +++ b/organizations/groups @@ -0,0 +1,43 @@ +--- +title: "Groups" +sidebarTitle: "Groups" +description: "Organize members within your Organization using leaderless, additive groups." +--- + +Groups are the intra-org social unit, replacing Teams within an Organization. Use groups to organize members by team, project, function, or any other structure that fits your org. + +## How groups work + +- Groups have **no leader, owner, or group-level admin**. Only org admins can manage group membership. +- A member can belong to **zero or many groups simultaneously**. Groups are additive — joining one group has no effect on membership in others. +- Groups are currently for organizational purposes only. Using groups to control resource visibility or access is planned for H2 2026. + +## Create a group + +Only org admins can create groups. + +1. Go to **Settings → Groups** in the console. +2. Click **Create Group**. +3. Enter a group name and optional description. +4. Click **Create**. + +## Add members to a group + +1. Go to **Settings → Groups** and select the group. +2. Click **Add Members**. +3. Search for members by name or email and select them. +4. Click **Add**. + +## Remove members from a group + +1. Go to **Settings → Groups** and select the group. +2. Find the member and click **Remove**. + +Removing a member from a group does not remove them from the Organization. + +## Delete a group + +1. Go to **Settings → Groups** and select the group. +2. Click **Delete Group** and confirm. + +Deleting a group does not affect the members in it — they remain in the Organization. From 45307720f603adafef8c44a25017449afb80d874 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:49:38 -0400 Subject: [PATCH 04/44] Create billing --- organizations/billing | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) create mode 100644 organizations/billing diff --git a/organizations/billing b/organizations/billing new file mode 100644 index 000000000..b829b5ed6 --- /dev/null +++ b/organizations/billing @@ -0,0 +1,33 @@ +--- +title: "Billing" +sidebarTitle: "Billing" +description: "Understand how post-paid invoicing works for Organization accounts." +--- + +Organizations use post-paid invoicing. All compute usage across all members is billed to the Organization at the end of each billing period. There is no credit balance, no credit top-up, and no payment method management in the console. + +## How billing works + +All billing events from all org members are attributed to the Organization. Invoices are handled by Runpod's finance team and delivered externally — not inside the console. + +Unlike personal and Team accounts, Organizations cannot: + +- Hold a prepaid credit balance +- Redeem credit codes +- Add or remove payment methods in the console + +## Viewing usage + +**All org members** can access Billing Explorer to view their own resource usage. + +**Org admins** can view any individual member's usage in Billing Explorer — useful for auditing spend per user or per team. + +To open Billing Explorer, go to **Billing → Billing Explorer** in the console. + +## Cost centers + +The **billing role** can create, update, and delete cost center labels to attribute spend across projects, teams, or departments. See [Cost centers](/accounts-billing/cost-centers) for setup instructions. + +## Billing questions + +For invoice questions, payment terms, or billing disputes, contact Runpod's finance team directly. Include your Organization name and the relevant billing period in your request. From 17e5e51d0a64fdd2a31e8b7cb5f7fd56c53cb603 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:50:22 -0400 Subject: [PATCH 05/44] Create access --- organizations/access | 86 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 86 insertions(+) create mode 100644 organizations/access diff --git a/organizations/access b/organizations/access new file mode 100644 index 000000000..499f5e5bc --- /dev/null +++ b/organizations/access @@ -0,0 +1,86 @@ +--- +title: "Access and SSO" +sidebarTitle: "Access and SSO" +description: "Configure how members authenticate and access your Organization." +--- + +Org admins control how users get into the Organization. Three access modes are available, and they can be combined. + +## Access modes + +**SSO only** — Users must authenticate through a configured identity provider. Ad-hoc email invitations are disabled. Supported providers: Okta, Auth0, Azure Active Directory, Google Workspace, Duo. + +**Ad-hoc invitations only** — Users are invited by email. No SSO required. + +**SSO + ad-hoc** — Both methods work simultaneously. Users can join via SSO or by accepting an email invitation. + +## Configure SSO + +Only org admins can configure SSO. To set up an identity provider: + +1. Go to **Settings → Access** in the console. +2. Under **SSO**, select your identity provider. +3. Follow the provider-specific setup steps below. +4. Click **Save**. + +### Okta + +1. In Okta, create a new SAML 2.0 application. +2. Set the SSO URL and Audience URI to the values shown in the Runpod console. +3. Copy the Identity Provider metadata URL from Okta and paste it into the Runpod console. + +### Auth0 + +1. In Auth0, create a new SAML application. +2. Set the callback URL to the value shown in the Runpod console. +3. Copy the Auth0 domain and client ID into the Runpod console. + +### Azure Active Directory + +1. In Azure AD, register a new enterprise application. +2. Set the reply URL (Assertion Consumer Service URL) to the value shown in the Runpod console. +3. Copy the Azure AD tenant ID and application ID into the Runpod console. + +### Google Workspace + +1. In Google Workspace Admin, create a new SAML app. +2. Set the ACS URL and Entity ID to the values shown in the Runpod console. +3. Download the Google IdP metadata and upload it in the Runpod console. + +### Duo + +1. In Duo, create a new SAML application. +2. Configure the entity ID and ACS URL using the values shown in the Runpod console. +3. Copy the Duo metadata URL into the Runpod console. + +## Email domain allowlist + +When ad-hoc invitations are enabled, you can restrict membership to users with approved email domains (e.g. `acme.com`). + + + Public email providers (gmail.com, yahoo.com, outlook.com, hey.com) cannot be added as approved domains. The console will show a warning if you attempt this. + + +To configure the domain allowlist: + +1. Go to **Settings → Access**. +2. Under **Approved domains**, enter one or more domains. +3. Click **Save**. + +Only users with email addresses matching an approved domain can accept invitations. + +## IP allowlist + +Org admins can restrict console and API access to specific IP ranges using CIDR notation. When the allowlist is non-empty, any request from an IP not on the list is blocked with HTTP 403. + + + Before saving an IP allowlist, ensure your own IP address is included. The console warns you if your current IP is not covered to prevent locking yourself out. Changes take effect within 60 seconds. + + +To configure the IP allowlist: + +1. Go to **Settings → Access**. +2. Under **IP Allowlist**, add one or more CIDR ranges (e.g. `203.0.113.0/24`). +3. Click **Save**. + +To remove the IP restriction entirely, delete all entries and save. From e9fd51f2a48de720a29dc08d5f217531f732d4f9 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:50:59 -0400 Subject: [PATCH 06/44] Create resource-tagging --- organizations/resource-tagging | 37 ++++++++++++++++++++++++++++++++++ 1 file changed, 37 insertions(+) create mode 100644 organizations/resource-tagging diff --git a/organizations/resource-tagging b/organizations/resource-tagging new file mode 100644 index 000000000..548c4afb2 --- /dev/null +++ b/organizations/resource-tagging @@ -0,0 +1,37 @@ +--- +title: "Resource tagging" +sidebarTitle: "Resource tagging" +description: "Attach key-value tags to resources for cost attribution and filtering." +--- + +Tags are key-value pairs you attach to org resources (Pods, endpoints, volumes, etc.) to track spend, filter usage, and attribute costs across teams or projects. + +## Tag format + +- Tags are key-value pairs, both in UTF-8, max 64 characters each. +- All org members can view all tags regardless of who created them. +- **Dev and admin roles** can create tags. Basic users can view but not create tags. + +## System tags + +Runpod automatically applies system tags using the `runpod:` namespace prefix (e.g. `runpod:region`, `runpod:data-center`). You cannot create tags with the `runpod:` prefix. + +On launch, all existing org resources are backfilled with `runpod:region` and `runpod:data-center` tags automatically. + +## Add a tag to a resource + +1. Navigate to the resource (Pod, endpoint, volume, etc.) in the console. +2. Open the resource details and click **Tags**. +3. Click **Add Tag**. +4. Enter a key and value. +5. Click **Save**. + +## Remove a tag + +1. Navigate to the resource in the console. +2. Open **Tags**. +3. Click the delete icon next to the tag you want to remove. + +## Filter by tag + +Use tags to filter resources in the console or query usage by tag in Billing Explorer. This helps attribute spend to specific teams, projects, or cost centers. From 697496e808162c2ad17807f3fbb1ea4c78b61b56 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:52:10 -0400 Subject: [PATCH 07/44] Create migrate-from-tennis --- organizations/migrate-from-tennis | 63 +++++++++++++++++++++++++++++++ 1 file changed, 63 insertions(+) create mode 100644 organizations/migrate-from-tennis diff --git a/organizations/migrate-from-tennis b/organizations/migrate-from-tennis new file mode 100644 index 000000000..655d4b2b0 --- /dev/null +++ b/organizations/migrate-from-tennis @@ -0,0 +1,63 @@ +--- +title: "Migrate from Teams" +sidebarTitle: "Migrate from Teams" +description: "What to expect when your Team account is migrated to an Organization." +--- + +Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. + + + Migration is permanent and irreversible. Once your Team is migrated to an Organization, there is no path back to the Team model. + + +## What happens during migration + +1. A Runpod staff member runs a migration script for your Team. +2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. +3. All resources previously owned by the Team — Pods, endpoints, volumes, clusters, templates, secrets, registry auth — transfer to the Organization automatically. +4. Former team members are **not** automatically added to the Organization. As the new org admin, you must re-invite them manually. +5. You receive an email notification when migration is complete. +6. When invited former members accept, their personal resources (Pods, templates, secrets, etc.) fold into the Organization permanently and cannot be reclaimed. + +## What to do before migration + +### Resolve cross-team memberships + +If any team member belongs to multiple teams owned by different customers, that cross-team membership must be resolved before migration. The affected user must leave one of the teams before migration can proceed. + +### Rotate SharedApiKey credentials + +If your team uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials before removing any member post-migration. When a member is removed from an org, their storage credentials are revoked immediately. + +Do this in order: +1. Create replacement credentials attributed to a remaining admin. +2. Update all external service configurations to use the new credentials. +3. Then remove the member. + +### Understand SSH key behavior + +SSH key behavior does not change at migration. Each Pod's `PUBLIC_KEY` remains the deploying user's key only — not a shared org key. + +Workarounds if you need shared SSH access: +- Set a `RUNPOD_SSH_PUBLIC_KEY` environment variable per Pod to override the default key. +- Use the web terminal in the console. +- Share a private key across team members (not recommended for security reasons). + +Org-level SSH key management is a planned feature for a future release. + +## After migration + +Once migration is complete: + +- The `console.runpod.io/team` page is no longer accessible. +- Your Organization dashboard is available at `console.runpod.io`. +- Invite your former team members from **Settings → Members**. +- Set up SSO, domain allowlists, and groups as needed. See [Access and SSO](/organizations/access) and [Groups](/organizations/groups). + +## Membership warning for invited members + +When a former team member accepts your invitation, they will see a warning before accepting: + +> Joining this Organization will transfer your personal resources to the Organization permanently. These resources cannot be reclaimed if you leave or are removed. + +Members must acknowledge this before their invitation is accepted. From a8245540e10c43f424dfb454e4ed02225c517a18 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:55:05 -0400 Subject: [PATCH 08/44] Create migrate-from-teams --- organizations/migrate-from-teams | 64 ++++++++++++++++++++++++++++++++ 1 file changed, 64 insertions(+) create mode 100644 organizations/migrate-from-teams diff --git a/organizations/migrate-from-teams b/organizations/migrate-from-teams new file mode 100644 index 000000000..091cd3b60 --- /dev/null +++ b/organizations/migrate-from-teams @@ -0,0 +1,64 @@ +--- +title: "Migrate from Teams" +sidebarTitle: "Migrate from Teams" +description: "What to expect when your Team account is migrated to an Organization." +--- + +Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. + + + Migration is permanent and irreversible. Once your Team is migrated to an Organization, there is no path back to the Team model. + + +## What happens during migration + +1. A Runpod staff member runs a migration script for your Team. +2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. +3. All resources previously owned by the Team — Pods, endpoints, volumes, clusters, templates, secrets, registry auth — transfer to the Organization automatically. +4. Former team members are **not** automatically added to the Organization. As the new org admin, you must re-invite them manually. +5. You receive an email notification when migration is complete. +6. When invited former members accept, their personal resources (Pods, templates, secrets, etc.) fold into the Organization permanently and cannot be reclaimed. + +## Before migration + +### Resolve cross-team memberships + +If any team member belongs to multiple teams owned by different customers, that cross-team membership must be resolved before migration can proceed. The affected user must leave one of the teams first. + +## After migration + +Once migration is complete, invite your former team members from **Settings → Members** and set up SSO, domain allowlists, and groups as needed. + +### Rotate SharedApiKey credentials before removing members + +If your org uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials **before** removing any member. When a member is removed from an org, their storage credentials are revoked immediately. + +Do this in order: +1. Create replacement credentials attributed to a remaining admin. +2. Update all external service configurations to use the new credentials. +3. Then remove the member. + +### SSH key behavior + +SSH key behavior does not change at migration. Each Pod's `PUBLIC_KEY` remains the deploying user's key only — not a shared org key. + +Workarounds if you need shared SSH access: +- Set a `RUNPOD_SSH_PUBLIC_KEY` environment variable per Pod to override the default key. +- Use the web terminal in the console. +- Share a private key across team members (not recommended for security reasons). + +Org-level SSH key management is a planned feature for a future release. + +Once migration is complete: + +- The `console.runpod.io/team` page is no longer accessible. +- Your Organization dashboard is available at `console.runpod.io`. +- See [Access and SSO](/organizations/access) and [Groups](/organizations/groups) for next steps. + +## Membership warning for invited members + +When a former team member accepts your invitation, they will see a warning before accepting: + +> Joining this Organization will transfer your personal resources to the Organization permanently. These resources cannot be reclaimed if you leave or are removed. + +Members must acknowledge this before their invitation is accepted. From 14ff80c3b3d59698f6df7d202f4508b242ed4a7e Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:56:08 -0400 Subject: [PATCH 09/44] Delete organizations/migrate-from-teams --- organizations/migrate-from-teams | 64 -------------------------------- 1 file changed, 64 deletions(-) delete mode 100644 organizations/migrate-from-teams diff --git a/organizations/migrate-from-teams b/organizations/migrate-from-teams deleted file mode 100644 index 091cd3b60..000000000 --- a/organizations/migrate-from-teams +++ /dev/null @@ -1,64 +0,0 @@ ---- -title: "Migrate from Teams" -sidebarTitle: "Migrate from Teams" -description: "What to expect when your Team account is migrated to an Organization." ---- - -Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. - - - Migration is permanent and irreversible. Once your Team is migrated to an Organization, there is no path back to the Team model. - - -## What happens during migration - -1. A Runpod staff member runs a migration script for your Team. -2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. -3. All resources previously owned by the Team — Pods, endpoints, volumes, clusters, templates, secrets, registry auth — transfer to the Organization automatically. -4. Former team members are **not** automatically added to the Organization. As the new org admin, you must re-invite them manually. -5. You receive an email notification when migration is complete. -6. When invited former members accept, their personal resources (Pods, templates, secrets, etc.) fold into the Organization permanently and cannot be reclaimed. - -## Before migration - -### Resolve cross-team memberships - -If any team member belongs to multiple teams owned by different customers, that cross-team membership must be resolved before migration can proceed. The affected user must leave one of the teams first. - -## After migration - -Once migration is complete, invite your former team members from **Settings → Members** and set up SSO, domain allowlists, and groups as needed. - -### Rotate SharedApiKey credentials before removing members - -If your org uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials **before** removing any member. When a member is removed from an org, their storage credentials are revoked immediately. - -Do this in order: -1. Create replacement credentials attributed to a remaining admin. -2. Update all external service configurations to use the new credentials. -3. Then remove the member. - -### SSH key behavior - -SSH key behavior does not change at migration. Each Pod's `PUBLIC_KEY` remains the deploying user's key only — not a shared org key. - -Workarounds if you need shared SSH access: -- Set a `RUNPOD_SSH_PUBLIC_KEY` environment variable per Pod to override the default key. -- Use the web terminal in the console. -- Share a private key across team members (not recommended for security reasons). - -Org-level SSH key management is a planned feature for a future release. - -Once migration is complete: - -- The `console.runpod.io/team` page is no longer accessible. -- Your Organization dashboard is available at `console.runpod.io`. -- See [Access and SSO](/organizations/access) and [Groups](/organizations/groups) for next steps. - -## Membership warning for invited members - -When a former team member accepts your invitation, they will see a warning before accepting: - -> Joining this Organization will transfer your personal resources to the Organization permanently. These resources cannot be reclaimed if you leave or are removed. - -Members must acknowledge this before their invitation is accepted. From ed551582eda00769e789dc199392e6820ffbee56 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 09:58:14 -0400 Subject: [PATCH 10/44] Update docs.json --- docs.json | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/docs.json b/docs.json index a70e93685..04f5b8250 100644 --- a/docs.json +++ b/docs.json @@ -262,6 +262,18 @@ "accounts-billing/manage-payment-cards" ] }, + { + "group": "Organizations", + "pages": [ + "organizations/overview", + "organizations/roles", + "organizations/groups", + "organizations/billing", + "organizations/access", + "organizations/resource-tagging", + "organizations/migrate-from-teams" + ] + }, { "group": "Integrations", "pages": [ From 0150192ef1b257a031f537353fff228ab1c61153 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:12:05 -0400 Subject: [PATCH 11/44] Rename migrate-from-tennis to migrate-from-teams --- organizations/{migrate-from-tennis => migrate-from-teams} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{migrate-from-tennis => migrate-from-teams} (100%) diff --git a/organizations/migrate-from-tennis b/organizations/migrate-from-teams similarity index 100% rename from organizations/migrate-from-tennis rename to organizations/migrate-from-teams From 4a44ae14eabfb448d1ad62cbb11b0b7a60c4dcda Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:17:01 -0400 Subject: [PATCH 12/44] Rename access to access.mdx --- organizations/{access => access.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{access => access.mdx} (100%) diff --git a/organizations/access b/organizations/access.mdx similarity index 100% rename from organizations/access rename to organizations/access.mdx From 209fe35d487ab9e69eaecedef900fc624b2ca7b4 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:17:24 -0400 Subject: [PATCH 13/44] Rename billing to billing.mdx --- organizations/{billing => billing.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{billing => billing.mdx} (100%) diff --git a/organizations/billing b/organizations/billing.mdx similarity index 100% rename from organizations/billing rename to organizations/billing.mdx From 1e042339e54a2a6d6cbcdc06e6849ffe6555430c Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:17:41 -0400 Subject: [PATCH 14/44] Rename groups to groups.mdx --- organizations/{groups => groups.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{groups => groups.mdx} (100%) diff --git a/organizations/groups b/organizations/groups.mdx similarity index 100% rename from organizations/groups rename to organizations/groups.mdx From 32ab4c04c5b06b9fb92f4cf606255457a6688b21 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:17:57 -0400 Subject: [PATCH 15/44] Rename migrate-from-teams to migrate-from-teams.mdx --- organizations/{migrate-from-teams => migrate-from-teams.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{migrate-from-teams => migrate-from-teams.mdx} (100%) diff --git a/organizations/migrate-from-teams b/organizations/migrate-from-teams.mdx similarity index 100% rename from organizations/migrate-from-teams rename to organizations/migrate-from-teams.mdx From 16daf487c6454066ae6c96034aeaa483a358ce1a Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:18:15 -0400 Subject: [PATCH 16/44] Rename resource-tagging to resource-tagging.mdx --- organizations/{resource-tagging => resource-tagging.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{resource-tagging => resource-tagging.mdx} (100%) diff --git a/organizations/resource-tagging b/organizations/resource-tagging.mdx similarity index 100% rename from organizations/resource-tagging rename to organizations/resource-tagging.mdx From 8f7bf0dbccaf88b590a4ec68de576d6a9a65b771 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 1 Jul 2026 10:18:32 -0400 Subject: [PATCH 17/44] Rename roles to roles.mdx --- organizations/{roles => roles.mdx} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename organizations/{roles => roles.mdx} (100%) diff --git a/organizations/roles b/organizations/roles.mdx similarity index 100% rename from organizations/roles rename to organizations/roles.mdx From 534f696629055e746bbd951a44214fa39c691abb Mon Sep 17 00:00:00 2001 From: "promptless[bot]" Date: Wed, 16 Sep 2026 15:49:22 +0000 Subject: [PATCH 18/44] Correct Organizations docs per PR #682 engineering review - overview: fix mutual-exclusivity claim (app-level, not data-layer; folded resources never returned) across the table row, warning, and Membership concept - migrate-from-teams: rewrite migration steps to the automatic staff-merge model (auto-join, role mapping, team-to-group, resource fold-in); fix SSH key behavior to the member-key union frozen at Pod creation and correct the override variable to SSH_PUBLIC_KEY; move member-prep guidance into the pre-migration section - groups: replace the false 'organizational purposes only' claim with open vs closed sharing-mode resource visibility - resource-tagging: correct system tags to the single reserved runpod:cost-center tag and drop the nonexistent region/data-center backfill --- organizations/groups.mdx | 5 ++++- organizations/migrate-from-teams.mdx | 29 +++++++++++----------------- organizations/overview.mdx | 6 +++--- organizations/resource-tagging.mdx | 4 +--- 4 files changed, 19 insertions(+), 25 deletions(-) diff --git a/organizations/groups.mdx b/organizations/groups.mdx index 7eaafa233..e9dd31904 100644 --- a/organizations/groups.mdx +++ b/organizations/groups.mdx @@ -10,7 +10,10 @@ Groups are the intra-org social unit, replacing Teams within an Organization. Us - Groups have **no leader, owner, or group-level admin**. Only org admins can manage group membership. - A member can belong to **zero or many groups simultaneously**. Groups are additive — joining one group has no effect on membership in others. -- Groups are currently for organizational purposes only. Using groups to control resource visibility or access is planned for H2 2026. + +### Sharing modes + +Your Organization can operate in one of two sharing modes: open or closed. In open sharing mode, all org members can see each other's Pods and endpoints regardless of group membership. In closed sharing mode, which is the default, group membership controls visibility: a non-admin member can only see resources belonging to users who share at least one group with them, and a member who belongs to no groups sees no other member's resources. Org admins can see all resources in the Organization regardless of sharing mode. ## Create a group diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx index 655d4b2b0..055d7065a 100644 --- a/organizations/migrate-from-teams.mdx +++ b/organizations/migrate-from-teams.mdx @@ -15,12 +15,16 @@ Migration from Teams to Organizations is performed by Runpod staff. You cannot s 1. A Runpod staff member runs a migration script for your Team. 2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. 3. All resources previously owned by the Team — Pods, endpoints, volumes, clusters, templates, secrets, registry auth — transfer to the Organization automatically. -4. Former team members are **not** automatically added to the Organization. As the new org admin, you must re-invite them manually. -5. You receive an email notification when migration is complete. -6. When invited former members accept, their personal resources (Pods, templates, secrets, etc.) fold into the Organization permanently and cannot be reclaimed. +4. All former team members join the Organization automatically. Each member's team role maps to a corresponding org role, and each team becomes a group in the new Organization. +5. Every participant's personal resources (Pods, templates, secrets, and more) fold into the Organization during the merge. These resources cannot be reclaimed. +6. You receive an email notification when migration is complete. ## What to do before migration +### Prepare members for resource transfer + +During the merge, each participant's personal resources fold into the Organization and cannot be reclaimed. Before migration, make sure your team members understand that the resources they contribute are not returned if they later leave or are removed. + ### Resolve cross-team memberships If any team member belongs to multiple teams owned by different customers, that cross-team membership must be resolved before migration. The affected user must leave one of the teams before migration can proceed. @@ -36,14 +40,11 @@ Do this in order: ### Understand SSH key behavior -SSH key behavior does not change at migration. Each Pod's `PUBLIC_KEY` remains the deploying user's key only — not a shared org key. +For Pods deployed by the Organization, Runpod sets `PUBLIC_KEY` to the union of all current org members' SSH public keys (see [Connect to a Pod via SSH](/pods/configuration/use-ssh) for how key injection works). Shared SSH access works automatically: every member whose key is on file when the Pod is created can connect. -Workarounds if you need shared SSH access: -- Set a `RUNPOD_SSH_PUBLIC_KEY` environment variable per Pod to override the default key. -- Use the web terminal in the console. -- Share a private key across team members (not recommended for security reasons). +Because the key set is frozen at creation, adding or removing a member's key affects only Pods deployed after that change. Existing Pods keep the keys they were created with until they are redeployed. -Org-level SSH key management is a planned feature for a future release. +To override the injected keys on a specific Pod, set the `SSH_PUBLIC_KEY` environment variable on that Pod. ## After migration @@ -51,13 +52,5 @@ Once migration is complete: - The `console.runpod.io/team` page is no longer accessible. - Your Organization dashboard is available at `console.runpod.io`. -- Invite your former team members from **Settings → Members**. +- Review your migrated members and their mapped roles in **Settings → Members**. - Set up SSO, domain allowlists, and groups as needed. See [Access and SSO](/organizations/access) and [Groups](/organizations/groups). - -## Membership warning for invited members - -When a former team member accepts your invitation, they will see a warning before accepting: - -> Joining this Organization will transfer your personal resources to the Organization permanently. These resources cannot be reclaimed if you leave or are removed. - -Members must acknowledge this before their invitation is accepted. diff --git a/organizations/overview.mdx b/organizations/overview.mdx index 7356430fa..67ac44d77 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -18,17 +18,17 @@ Organizations are Runpod's enterprise account model, designed for teams that nee | **Billing** | Prepaid credit balance | Post-paid invoice only | | **Membership** | A user can own one team and belong to others | A user belongs to at most one Organization | | **Social unit** | Team (has an owner) | Group (leaderless, additive) | -| **Mutual exclusivity** | Compatible with personal accounts | Joining an Org permanently removes Team access — irreversible | +| **Mutual exclusivity** | Compatible with personal accounts | One Organization or team at a time; joining removes you from any team, and personal resources you contribute are never returned. | - Teams and Organizations are mutually exclusive — permanently. Once a user joins an Organization, there is no path back to Team membership. This is enforced at the data layer and cannot be undone. + Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. Joining an Organization removes you from any team you're in, and the personal resources you fold in are never returned, even if you later leave the Organization. ## Key concepts **Ownership** — All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is suspended or removed, their resources keep running and remain accessible to other members. -**Membership** — A user may belong to at most one Organization. Joining an Organization folds your existing personal resources (Pods, templates, secrets, and more) into the Organization permanently. These resources cannot be reclaimed if you leave. +**Membership**: You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. **Roles** — Four roles control what members can do: admin, billing, dev, and basic. There is no owner role — admin is the top level. See [Roles](/organizations/roles). diff --git a/organizations/resource-tagging.mdx b/organizations/resource-tagging.mdx index 548c4afb2..f937f072a 100644 --- a/organizations/resource-tagging.mdx +++ b/organizations/resource-tagging.mdx @@ -14,9 +14,7 @@ Tags are key-value pairs you attach to org resources (Pods, endpoints, volumes, ## System tags -Runpod automatically applies system tags using the `runpod:` namespace prefix (e.g. `runpod:region`, `runpod:data-center`). You cannot create tags with the `runpod:` prefix. - -On launch, all existing org resources are backfilled with `runpod:region` and `runpod:data-center` tags automatically. +Runpod automatically manages one reserved tag, `runpod:cost-center`. The system applies this tag when you assign a resource to a cost center. You cannot create or modify tags that use the `runpod:` namespace prefix. ## Add a tag to a resource From 5c22dbe1e12108ce95d020a80399bde11799c153 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:21:57 -0400 Subject: [PATCH 19/44] Fix tag format rules and description in resource-tagging.mdx --- organizations/resource-tagging.mdx | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/organizations/resource-tagging.mdx b/organizations/resource-tagging.mdx index f937f072a..60e9d255c 100644 --- a/organizations/resource-tagging.mdx +++ b/organizations/resource-tagging.mdx @@ -1,20 +1,23 @@ --- title: "Resource tagging" sidebarTitle: "Resource tagging" -description: "Attach key-value tags to resources for cost attribution and filtering." +description: "Attach key-value tags to Organization resources to track spend, filter usage, and attribute costs across teams, projects, and cost centers." --- Tags are key-value pairs you attach to org resources (Pods, endpoints, volumes, etc.) to track spend, filter usage, and attribute costs across teams or projects. ## Tag format -- Tags are key-value pairs, both in UTF-8, max 64 characters each. +- Tag keys must be non-empty. Tag values may be left blank. +- Each resource supports a maximum of 25 tags. +- The combination of key and value must be unique on a resource. You cannot add the same key and value pair more than once. +- Keys using the `runpod:` prefix are reserved for system use and cannot be created. - All org members can view all tags regardless of who created them. - **Dev and admin roles** can create tags. Basic users can view but not create tags. ## System tags -Runpod automatically manages one reserved tag, `runpod:cost-center`. The system applies this tag when you assign a resource to a cost center. You cannot create or modify tags that use the `runpod:` namespace prefix. +Runpod automatically manages one reserved tag: `runpod:cost-center`. This tag is applied by the system when you assign a resource to a cost center. You cannot create or modify tags that use the `runpod:` namespace prefix. ## Add a tag to a resource From 31fcc6e628c7f66bd148054de4e24d167669d708 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:23:40 -0400 Subject: [PATCH 20/44] Fix description and remove em dashes in groups.mdx --- organizations/groups.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/organizations/groups.mdx b/organizations/groups.mdx index e9dd31904..ca70fd00f 100644 --- a/organizations/groups.mdx +++ b/organizations/groups.mdx @@ -1,7 +1,7 @@ --- title: "Groups" sidebarTitle: "Groups" -description: "Organize members within your Organization using leaderless, additive groups." +description: "Organize Organization members into leaderless, additive groups and learn how sharing modes control resource visibility across members." --- Groups are the intra-org social unit, replacing Teams within an Organization. Use groups to organize members by team, project, function, or any other structure that fits your org. @@ -9,7 +9,7 @@ Groups are the intra-org social unit, replacing Teams within an Organization. Us ## How groups work - Groups have **no leader, owner, or group-level admin**. Only org admins can manage group membership. -- A member can belong to **zero or many groups simultaneously**. Groups are additive — joining one group has no effect on membership in others. +- A member can belong to **zero or many groups simultaneously**. Groups are additive: joining one group has no effect on membership in others. ### Sharing modes @@ -43,4 +43,4 @@ Removing a member from a group does not remove them from the Organization. 1. Go to **Settings → Groups** and select the group. 2. Click **Delete Group** and confirm. -Deleting a group does not affect the members in it — they remain in the Organization. +Deleting a group does not affect the members in it. They remain in the Organization. From 4a0fe8013ad0b51521610bb7cad61168629d8b0e Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:25:48 -0400 Subject: [PATCH 21/44] Fix description and remove em dashes in access.mdx --- organizations/access.mdx | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/organizations/access.mdx b/organizations/access.mdx index 499f5e5bc..6c0cc2a42 100644 --- a/organizations/access.mdx +++ b/organizations/access.mdx @@ -1,18 +1,18 @@ --- title: "Access and SSO" sidebarTitle: "Access and SSO" -description: "Configure how members authenticate and access your Organization." +description: "Configure how members authenticate and access your Organization, including SSO setup, email domain allowlists, and IP range restrictions." --- Org admins control how users get into the Organization. Three access modes are available, and they can be combined. ## Access modes -**SSO only** — Users must authenticate through a configured identity provider. Ad-hoc email invitations are disabled. Supported providers: Okta, Auth0, Azure Active Directory, Google Workspace, Duo. +**SSO only:** Users must authenticate through a configured identity provider. Ad-hoc email invitations are disabled. Supported providers: Okta, Auth0, Azure Active Directory, Google Workspace, Duo. -**Ad-hoc invitations only** — Users are invited by email. No SSO required. +**Ad-hoc invitations only:** Users are invited by email. No SSO required. -**SSO + ad-hoc** — Both methods work simultaneously. Users can join via SSO or by accepting an email invitation. +**SSO + ad-hoc:** Both methods work simultaneously. Users can join via SSO or by accepting an email invitation. ## Configure SSO From 0c622d3d45eb01b9256d9bdd471a94518a29d30a Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:26:45 -0400 Subject: [PATCH 22/44] Fix description and remove em dash in billing.mdx --- organizations/billing.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/organizations/billing.mdx b/organizations/billing.mdx index b829b5ed6..d2ce5b36a 100644 --- a/organizations/billing.mdx +++ b/organizations/billing.mdx @@ -1,14 +1,14 @@ --- title: "Billing" sidebarTitle: "Billing" -description: "Understand how post-paid invoicing works for Organization accounts." +description: "Learn how post-paid invoicing works for Organization accounts, including how to view usage and set up cost centers for spend attribution." --- Organizations use post-paid invoicing. All compute usage across all members is billed to the Organization at the end of each billing period. There is no credit balance, no credit top-up, and no payment method management in the console. ## How billing works -All billing events from all org members are attributed to the Organization. Invoices are handled by Runpod's finance team and delivered externally — not inside the console. +All billing events from all org members are attributed to the Organization. Invoices are handled by Runpod's finance team and delivered externally, not inside the console. Unlike personal and Team accounts, Organizations cannot: @@ -20,7 +20,7 @@ Unlike personal and Team accounts, Organizations cannot: **All org members** can access Billing Explorer to view their own resource usage. -**Org admins** can view any individual member's usage in Billing Explorer — useful for auditing spend per user or per team. +**Org admins** can view any individual member's usage in Billing Explorer, useful for auditing spend per user or per team. To open Billing Explorer, go to **Billing → Billing Explorer** in the console. From 8392df0a9d13c617b0bbc83ed2f481eecac6b171 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:29:24 -0400 Subject: [PATCH 23/44] Fix description and em dashes in roles.mdx --- organizations/roles.mdx | 40 ++++++++++++++++++++-------------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/organizations/roles.mdx b/organizations/roles.mdx index d41e604a5..b489c12c3 100644 --- a/organizations/roles.mdx +++ b/organizations/roles.mdx @@ -1,38 +1,38 @@ --- title: "Roles" sidebarTitle: "Roles" -description: "Control what Organization members can do with four role levels." +description: "Control what Organization members can do with four role levels: admin, billing, dev, and basic. Learn which actions each role can perform." --- - -Every member of an Organization is assigned one of four roles. Roles control access to org management actions — there is no owner role. Admin is the highest level. - + +Every member of an Organization is assigned one of four roles. Roles control access to org management actions; there is no owner role. Admin is the highest level. + ## Role overview - + | Role | Manage members & groups | Manage billing & cost centers | Create & manage resources | Use existing resources | |---|---|---|---|---| | **Admin** | ✓ | ✓ | ✓ | ✓ | | **Billing** | — | ✓ | — | ✓ | | **Dev** | — | — | ✓ | ✓ | | **Basic** | — | — | — | ✓ | - + ## Role descriptions - -**Admin** — Full organization management plus all dev permissions. Admins can invite and remove members, create and manage groups, configure SSO and access settings, manage the IP allowlist, and create or manage any computing resource. - -**Billing** — Can create, update, and delete cost center labels for resource attribution. Cannot create or manage computing resources, and cannot manage members or groups. - -**Dev** — Can create and manage computing resources: Pods, serverless endpoints, network volumes, clusters, and templates. Cannot manage members, groups, or billing configuration. - -**Basic** — Can access and use existing org resources. Cannot create new resources. - + +**Admin:** Full organization management plus all dev permissions. Admins can invite and remove members, create and manage groups, configure SSO and access settings, manage the IP allowlist, and create or manage any computing resource. + +**Billing:** Can create, update, and delete cost center labels for resource attribution. Cannot create or manage computing resources, and cannot manage members or groups. + +**Dev:** Can create and manage computing resources: Pods, serverless endpoints, network volumes, clusters, and templates. Cannot manage members, groups, or billing configuration. + +**Basic:** Can access and use existing org resources. Cannot create new resources. + ## Resource access in MVP - -In the current release, roles gate org-management actions only. All org members — regardless of role — can list, use, modify, and stop any org-owned resource. Resource-level access control (RBAC) is planned for H2 2026. - + +In the current release, roles gate org-management actions only. All org members, regardless of role, can list, use, modify, and stop any org-owned resource. Resource-level access control (RBAC) is planned for H2 2026. + ## Assigning roles - + Only org admins can assign or change member roles. To update a member's role: - + 1. Go to **Settings → Members** in the console. 2. Find the member and click the role dropdown next to their name. 3. Select the new role and confirm. From c30386518fe0a9c8ab5d7acd20a4c03e1fc4b65b Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:30:48 -0400 Subject: [PATCH 24/44] Fix description in migrate-from-teams.mdx --- organizations/migrate-from-teams.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx index 055d7065a..1019bc536 100644 --- a/organizations/migrate-from-teams.mdx +++ b/organizations/migrate-from-teams.mdx @@ -1,7 +1,7 @@ --- title: "Migrate from Teams" sidebarTitle: "Migrate from Teams" -description: "What to expect when your Team account is migrated to an Organization." +description: "Learn what happens when your Team account is migrated to an Organization, including resource transfer, role mapping, and preparation steps." --- Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. @@ -14,7 +14,7 @@ Migration from Teams to Organizations is performed by Runpod staff. You cannot s 1. A Runpod staff member runs a migration script for your Team. 2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. -3. All resources previously owned by the Team — Pods, endpoints, volumes, clusters, templates, secrets, registry auth — transfer to the Organization automatically. +3. All resources previously owned by the Team, including Pods, endpoints, volumes, clusters, templates, secrets, and registry auth, transfer to the Organization automatically. 4. All former team members join the Organization automatically. Each member's team role maps to a corresponding org role, and each team becomes a group in the new Organization. 5. Every participant's personal resources (Pods, templates, secrets, and more) fold into the Organization during the merge. These resources cannot be reclaimed. 6. You receive an email notification when migration is complete. From 8696e10efb558a86417d9f73088de63ac0c03aca Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:31:50 -0400 Subject: [PATCH 25/44] Update overview.mdx --- organizations/overview.mdx | 22 +++++++++++----------- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index 67ac44d77..561724d14 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -1,10 +1,10 @@ --- title: "Organizations" sidebarTitle: "Overview" -description: "Manage enterprise GPU workloads with centralized billing, access control, and resource ownership." +description: "Manage enterprise GPU workloads with centralized resource ownership, billing, and access control. Organizations replace Teams for enterprise accounts." --- -Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an Organization is a first-class entity that owns all resources — compute, storage, secrets, and templates — independent of any individual user. +Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an Organization is a first-class entity that owns all resources (compute, storage, secrets, and templates) independent of any individual user. Organizations are currently in internal alpha and are available to enterprise customers via Runpod sales. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). @@ -12,9 +12,9 @@ Organizations are Runpod's enterprise account model, designed for teams that nee ## How Organizations differ from Teams -| | Teams | Organizations | +| | Teams | Organizations | |---|---|---| -| **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the Organization — survive if any member leaves | +| **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the Organization, surviving if any member leaves | | **Billing** | Prepaid credit balance | Post-paid invoice only | | **Membership** | A user can own one team and belong to others | A user belongs to at most one Organization | | **Social unit** | Team (has an owner) | Group (leaderless, additive) | @@ -26,19 +26,19 @@ Organizations are Runpod's enterprise account model, designed for teams that nee ## Key concepts -**Ownership** — All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is suspended or removed, their resources keep running and remain accessible to other members. +**Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is suspended or removed, their resources keep running and remain accessible to other members. -**Membership**: You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. +**Membership:** You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. -**Roles** — Four roles control what members can do: admin, billing, dev, and basic. There is no owner role — admin is the top level. See [Roles](/organizations/roles). +**Roles:** Four roles control what members can do: admin, billing, dev, and basic. There is no owner role; admin is the top level. See [Roles](/organizations/roles). -**Groups** — Groups are the intra-org social unit, replacing Teams within an Organization. Groups are leaderless and additive — a user can belong to zero or many groups. See [Groups](/organizations/groups). +**Groups:** Groups are the intra-org social unit, replacing Teams within an Organization. Groups are leaderless and additive: a user can belong to zero or many groups. See [Groups](/organizations/groups). -**Billing** — Organizations use post-paid invoicing only. There is no credit balance, no credit top-up, and no payment method management in the console. See [Billing](/organizations/billing). +**Billing:** Organizations use post-paid invoicing only. There is no credit balance, no credit top-up, and no payment method management in the console. See [Billing](/organizations/billing). -**Access** — Org admins control how users authenticate: SSO, ad-hoc email invitations, or both. Admins can restrict access by email domain or IP range. See [Access and SSO](/organizations/access). +**Access:** Org admins control how users authenticate: SSO, ad-hoc email invitations, or both. Admins can restrict access by email domain or IP range. See [Access and SSO](/organizations/access). -**Resource tagging** — Tags are key-value pairs attached to resources for cost attribution and filtering. See [Resource tagging](/organizations/resource-tagging). +**Resource tagging:** Tags are key-value pairs attached to resources for cost attribution and filtering. See [Resource tagging](/organizations/resource-tagging). ## Get started From c9933e8e02a1a931eb155d9d01f5dba56600c4d3 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:49:25 -0400 Subject: [PATCH 26/44] Rewrite access.mdx: replace fake SSO/allowlist features with real invite flow --- organizations/access.mdx | 93 +++++++++++----------------------------- 1 file changed, 24 insertions(+), 69 deletions(-) diff --git a/organizations/access.mdx b/organizations/access.mdx index 6c0cc2a42..32692cdfe 100644 --- a/organizations/access.mdx +++ b/organizations/access.mdx @@ -1,86 +1,41 @@ --- -title: "Access and SSO" -sidebarTitle: "Access and SSO" -description: "Configure how members authenticate and access your Organization, including SSO setup, email domain allowlists, and IP range restrictions." +title: "Access" +sidebarTitle: "Access" +description: "Control who can join your Organization with email invitations. Admins invite members by exact email address, with 14-day expiry and a 150-invite cap." --- -Org admins control how users get into the Organization. Three access modes are available, and they can be combined. +Runpod provisions Organization accounts. Once your org is provisioned, org admins invite members by sending invitations to their exact email addresses. -## Access modes +## Invite members -**SSO only:** Users must authenticate through a configured identity provider. Ad-hoc email invitations are disabled. Supported providers: Okta, Auth0, Azure Active Directory, Google Workspace, Duo. +Only org admins can invite members. -**Ad-hoc invitations only:** Users are invited by email. No SSO required. +1. Go to **Settings → Members** in the console. +2. Click **Invite Member**. +3. Enter the member's exact email address and select their role. +4. Click **Send Invite**. -**SSO + ad-hoc:** Both methods work simultaneously. Users can join via SSO or by accepting an email invitation. +The invited user receives an email with a link to accept. They must have a verified Runpod account to accept. Invitations expire after 14 days, and each Organization can have up to 150 pending invitations at a time. -## Configure SSO +## Accept an invitation -Only org admins can configure SSO. To set up an identity provider: +To accept an org invitation: -1. Go to **Settings → Access** in the console. -2. Under **SSO**, select your identity provider. -3. Follow the provider-specific setup steps below. -4. Click **Save**. +1. Open the invitation email and click the link. +2. Sign in to Runpod with the account associated with the invited email address. +3. Accept the invitation in the console. -### Okta +Accepting an invitation while you are a member of a team removes you from the team. Your personal resources are folded into the Organization and are not returned if you later leave. -1. In Okta, create a new SAML 2.0 application. -2. Set the SSO URL and Audience URI to the values shown in the Runpod console. -3. Copy the Identity Provider metadata URL from Okta and paste it into the Runpod console. +## Remove members -### Auth0 +Only org admins can remove members. When a member is removed: -1. In Auth0, create a new SAML application. -2. Set the callback URL to the value shown in the Runpod console. -3. Copy the Auth0 domain and client ID into the Runpod console. +- Their org S3 credentials are revoked immediately. +- Their Pods, endpoints, and other resources remain in the Organization. -### Azure Active Directory +To remove a member, go to **Settings → Members**, find the member, and click **Remove**. -1. In Azure AD, register a new enterprise application. -2. Set the reply URL (Assertion Consumer Service URL) to the value shown in the Runpod console. -3. Copy the Azure AD tenant ID and application ID into the Runpod console. +## Planned features -### Google Workspace - -1. In Google Workspace Admin, create a new SAML app. -2. Set the ACS URL and Entity ID to the values shown in the Runpod console. -3. Download the Google IdP metadata and upload it in the Runpod console. - -### Duo - -1. In Duo, create a new SAML application. -2. Configure the entity ID and ACS URL using the values shown in the Runpod console. -3. Copy the Duo metadata URL into the Runpod console. - -## Email domain allowlist - -When ad-hoc invitations are enabled, you can restrict membership to users with approved email domains (e.g. `acme.com`). - - - Public email providers (gmail.com, yahoo.com, outlook.com, hey.com) cannot be added as approved domains. The console will show a warning if you attempt this. - - -To configure the domain allowlist: - -1. Go to **Settings → Access**. -2. Under **Approved domains**, enter one or more domains. -3. Click **Save**. - -Only users with email addresses matching an approved domain can accept invitations. - -## IP allowlist - -Org admins can restrict console and API access to specific IP ranges using CIDR notation. When the allowlist is non-empty, any request from an IP not on the list is blocked with HTTP 403. - - - Before saving an IP allowlist, ensure your own IP address is included. The console warns you if your current IP is not covered to prevent locking yourself out. Changes take effect within 60 seconds. - - -To configure the IP allowlist: - -1. Go to **Settings → Access**. -2. Under **IP Allowlist**, add one or more CIDR ranges (e.g. `203.0.113.0/24`). -3. Click **Save**. - -To remove the IP restriction entirely, delete all entries and save. +SSO (SAML/OIDC), email domain allowlists, and IP allowlists are not yet available. They are planned for a future release. From afd00648741ee547059292924ce28eb8ceffcbda Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:50:05 -0400 Subject: [PATCH 27/44] Rewrite roles.mdx: fix admin/billing/basic descriptions, remove MVP RBAC section, add custom roles --- organizations/roles.mdx | 36 +++++++++++++++++++++++++++--------- 1 file changed, 27 insertions(+), 9 deletions(-) diff --git a/organizations/roles.mdx b/organizations/roles.mdx index b489c12c3..3ae3af2a9 100644 --- a/organizations/roles.mdx +++ b/organizations/roles.mdx @@ -1,33 +1,50 @@ --- title: "Roles" sidebarTitle: "Roles" -description: "Control what Organization members can do with four role levels: admin, billing, dev, and basic. Learn which actions each role can perform." +description: "Control what Organization members can do with four built-in roles plus custom roles. Learn which actions each role can perform." --- -Every member of an Organization is assigned one of four roles. Roles control access to org management actions; there is no owner role. Admin is the highest level. +Every member of an Organization is assigned a role. Four built-in roles ship with every Organization: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization composed from individual capabilities. There is no owner role; admin is the highest built-in level. ## Role overview | Role | Manage members & groups | Manage billing & cost centers | Create & manage resources | Use existing resources | |---|---|---|---|---| | **Admin** | ✓ | ✓ | ✓ | ✓ | -| **Billing** | — | ✓ | — | ✓ | +| **Billing** | — | ✓ | — | List only | | **Dev** | — | — | ✓ | ✓ | | **Basic** | — | — | — | ✓ | ## Role descriptions -**Admin:** Full organization management plus all dev permissions. Admins can invite and remove members, create and manage groups, configure SSO and access settings, manage the IP allowlist, and create or manage any computing resource. +**Admin:** Full Organization management. Admins can invite and remove members, manage groups and roles, manage billing and payment methods, and create, update, or delete any org compute resource. -**Billing:** Can create, update, and delete cost center labels for resource attribution. Cannot create or manage computing resources, and cannot manage members or groups. +**Billing:** View invoices and Billing Explorer, manage payment methods and billing settings, manage cost centers, and read-only listing of all org compute resources. Cannot create or modify computing resources, and cannot manage members or groups. -**Dev:** Can create and manage computing resources: Pods, serverless endpoints, network volumes, clusters, and templates. Cannot manage members, groups, or billing configuration. +**Dev:** Can create and manage computing resources: Pods, Serverless endpoints, network volumes, Instant Clusters, and templates. Cannot manage members, groups, billing configuration, or cost centers. -**Basic:** Can access and use existing org resources. Cannot create new resources. +**Basic:** Can access and use existing Organization resources visible to them based on the sharing mode. Cannot create new resources. -## Resource access in MVP +## Resource visibility -In the current release, roles gate org-management actions only. All org members, regardless of role, can list, use, modify, and stop any org-owned resource. Resource-level access control (RBAC) is planned for H2 2026. +Which resources a member can see depends on their role and the Organization's sharing mode. + +- **Admin:** Can see and manage all Organization resources regardless of sharing mode. +- **Dev:** Can create, update, and delete resources they own or that belong to members who share at least one group with them (in closed sharing mode). +- **Basic:** Can use Organization resources visible to them based on the sharing mode. + +See [Groups](/organizations/groups) for how open and closed sharing modes determine which resources members can see. + +## Custom roles + +Org admins can define up to 25 custom roles per Organization. Custom roles are composed from individual capabilities, letting you grant exactly the permissions your team needs. + +To create a custom role: + +1. Go to **Settings → Roles** in the console. +2. Click **Create Role**. +3. Enter a name and select the capabilities to include. +4. Click **Save**. ## Assigning roles @@ -36,4 +53,5 @@ Only org admins can assign or change member roles. To update a member's role: 1. Go to **Settings → Members** in the console. 2. Find the member and click the role dropdown next to their name. 3. Select the new role and confirm. + Role changes take effect immediately. From 106b4621a51d8dfae5060446bcc2bee4fef40d88 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:50:33 -0400 Subject: [PATCH 28/44] Fix billing.mdx: correct billing model (prepaid default), fix Billing Explorer access (admin+billing only) --- organizations/billing.mdx | 18 ++++++++---------- 1 file changed, 8 insertions(+), 10 deletions(-) diff --git a/organizations/billing.mdx b/organizations/billing.mdx index d2ce5b36a..c7461a788 100644 --- a/organizations/billing.mdx +++ b/organizations/billing.mdx @@ -1,26 +1,24 @@ --- title: "Billing" sidebarTitle: "Billing" -description: "Learn how post-paid invoicing works for Organization accounts, including how to view usage and set up cost centers for spend attribution." +description: "Learn how Organization billing works, including credit balances, payment methods, Billing Explorer access, and cost centers for spend attribution." --- -Organizations use post-paid invoicing. All compute usage across all members is billed to the Organization at the end of each billing period. There is no credit balance, no credit top-up, and no payment method management in the console. +Organization billing uses a prepaid credit balance by default. Each Organization has its own billing account with its own credit balance and payment methods, separate from any member's personal account. Postpaid invoicing is an enterprise option that Runpod enables on request. ## How billing works -All billing events from all org members are attributed to the Organization. Invoices are handled by Runpod's finance team and delivered externally, not inside the console. +All billing events from all org members are attributed to the Organization's billing account. Org admins and billing roles manage the org credit balance and payment methods in the console. -Unlike personal and Team accounts, Organizations cannot: +The Organization billing account: -- Hold a prepaid credit balance -- Redeem credit codes -- Add or remove payment methods in the console +- Maintains its own prepaid credit balance, separate from any member's personal credits. +- Has its own payment methods configured in the console. +- Supports auto-pay and auto-reload settings. ## Viewing usage -**All org members** can access Billing Explorer to view their own resource usage. - -**Org admins** can view any individual member's usage in Billing Explorer, useful for auditing spend per user or per team. +Only **admin and billing roles** can open Billing Explorer. They see usage for all org members; there is no self-usage view scoped to individual members below the admin or billing level. To open Billing Explorer, go to **Billing → Billing Explorer** in the console. From 8ecf30178256a5f5b876232390febe281c83ad19 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:51:01 -0400 Subject: [PATCH 29/44] Fix resource-tagging.mdx: list 4 taggable types, fix tag permission roles --- organizations/resource-tagging.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/organizations/resource-tagging.mdx b/organizations/resource-tagging.mdx index 60e9d255c..2ddd02eea 100644 --- a/organizations/resource-tagging.mdx +++ b/organizations/resource-tagging.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Resource tagging" description: "Attach key-value tags to Organization resources to track spend, filter usage, and attribute costs across teams, projects, and cost centers." --- -Tags are key-value pairs you attach to org resources (Pods, endpoints, volumes, etc.) to track spend, filter usage, and attribute costs across teams or projects. +Tags are key-value pairs you attach to Organization resources to track spend, filter usage, and attribute costs across teams or projects. Tagging is supported on Pods, Serverless endpoints, network volumes, and Instant Clusters. ## Tag format @@ -13,7 +13,7 @@ Tags are key-value pairs you attach to org resources (Pods, endpoints, volumes, - The combination of key and value must be unique on a resource. You cannot add the same key and value pair more than once. - Keys using the `runpod:` prefix are reserved for system use and cannot be created. - All org members can view all tags regardless of who created them. -- **Dev and admin roles** can create tags. Basic users can view but not create tags. +- **Admin and dev roles** can create, edit, and delete tags. Basic members can apply existing tags to resources. Billing members can only view tags. ## System tags @@ -21,7 +21,7 @@ Runpod automatically manages one reserved tag: `runpod:cost-center`. This tag is ## Add a tag to a resource -1. Navigate to the resource (Pod, endpoint, volume, etc.) in the console. +1. Navigate to the resource (Pod, endpoint, volume, or cluster) in the console. 2. Open the resource details and click **Tags**. 3. Click **Add Tag**. 4. Enter a key and value. From a04cc7251487856c5dc419e36ead0c5773fd57b6 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:51:44 -0400 Subject: [PATCH 30/44] Fix migrate-from-teams.mdx: SSH env var, cross-team gate, role mapping, warning, checklist --- organizations/migrate-from-teams.mdx | 34 +++++++++++++++++----------- 1 file changed, 21 insertions(+), 13 deletions(-) diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx index 1019bc536..982ae85ef 100644 --- a/organizations/migrate-from-teams.mdx +++ b/organizations/migrate-from-teams.mdx @@ -7,31 +7,39 @@ description: "Learn what happens when your Team account is migrated to an Organi Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. - Migration is permanent and irreversible. Once your Team is migrated to an Organization, there is no path back to the Team model. +Your Team is deleted during migration and cannot be restored. Personal resources contributed by members during the merge are folded into the Organization permanently and are never returned, even if a member later leaves. ## What happens during migration -1. A Runpod staff member runs a migration script for your Team. -2. The Team is disbanded. Your team owner email account becomes an **admin** of a new Organization. -3. All resources previously owned by the Team, including Pods, endpoints, volumes, clusters, templates, secrets, and registry auth, transfer to the Organization automatically. -4. All former team members join the Organization automatically. Each member's team role maps to a corresponding org role, and each team becomes a group in the new Organization. -5. Every participant's personal resources (Pods, templates, secrets, and more) fold into the Organization during the merge. These resources cannot be reclaimed. -6. You receive an email notification when migration is complete. +1. A Runpod staff member runs the migration for your Team. A single migration can merge multiple teams into one Organization or extend an existing one. +2. The Team is disbanded. Your team owner account becomes an **admin** of the new Organization. +3. All org-aware resources previously owned by the Team transfer to the Organization automatically, including Pods, endpoints, network volumes, Instant Clusters, templates, secrets, registry auth, Flash apps, reservations, and S3 credentials. +4. All team members join the Organization automatically. Team roles map to org roles using these rules: team owners become admin; members with an unknown or unmapped role default to basic; a member who belongs to multiple teams keeps the highest role across all teams. +5. Every participant's personal resources fold into the Organization during the merge and cannot be reclaimed. +6. Each team in the merge becomes a group in the Organization. ## What to do before migration -### Prepare members for resource transfer +### Tell members about resource transfer -During the merge, each participant's personal resources fold into the Organization and cannot be reclaimed. Before migration, make sure your team members understand that the resources they contribute are not returned if they later leave or are removed. +Every participant's personal resources (Pods, templates, secrets, and more) fold into the Organization during the merge and cannot be reclaimed. Make sure your team members understand this before the staff run. + +### Check for migration blockers + +The following conditions block migration and must be resolved before Runpod can run it: + +- Any participant with an active savings plan blocks the merge. +- Paying accounts require a billing cutover acknowledgement. +- Secret-name or derived group-name collisions hard-fail. ### Resolve cross-team memberships -If any team member belongs to multiple teams owned by different customers, that cross-team membership must be resolved before migration. The affected user must leave one of the teams before migration can proceed. +Every team that any participant belongs to must be included in the same merge. If a participant is in or owns a team outside the merge set, migration is blocked. That participant must leave that team first, or the other team must be added to the merge. ### Rotate SharedApiKey credentials -If your team uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials before removing any member post-migration. When a member is removed from an org, their storage credentials are revoked immediately. +If your team uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials before removing any member post-migration. When a member is removed from an Organization, their storage credentials are revoked immediately. Do this in order: 1. Create replacement credentials attributed to a remaining admin. @@ -44,7 +52,7 @@ For Pods deployed by the Organization, Runpod sets `PUBLIC_KEY` to the union of Because the key set is frozen at creation, adding or removing a member's key affects only Pods deployed after that change. Existing Pods keep the keys they were created with until they are redeployed. -To override the injected keys on a specific Pod, set the `SSH_PUBLIC_KEY` environment variable on that Pod. +To override the injected keys on a specific Pod, set the `PUBLIC_KEY` environment variable on that Pod. When `PUBLIC_KEY` is already set on a Pod, Runpod skips the member-key injection. ## After migration @@ -53,4 +61,4 @@ Once migration is complete: - The `console.runpod.io/team` page is no longer accessible. - Your Organization dashboard is available at `console.runpod.io`. - Review your migrated members and their mapped roles in **Settings → Members**. -- Set up SSO, domain allowlists, and groups as needed. See [Access and SSO](/organizations/access) and [Groups](/organizations/groups). +- Set up groups to organize your migrated members. See [Groups](/organizations/groups). From 26da3486e910800ca558574054404dcc375c0836 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:52:28 -0400 Subject: [PATCH 31/44] Fix overview.mdx: correct billing/access concepts, fix Membership em dash, table cell, Note, add horizontal cards --- organizations/overview.mdx | 56 +++++++++++++++++++------------------- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index 561724d14..05e787294 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -7,7 +7,7 @@ description: "Manage enterprise GPU workloads with centralized resource ownershi Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an Organization is a first-class entity that owns all resources (compute, storage, secrets, and templates) independent of any individual user. - Organizations are currently in internal alpha and are available to enterprise customers via Runpod sales. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). +Organizations are currently in beta. Runpod provisions Organization accounts and enables them for your account. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). ## How Organizations differ from Teams @@ -15,50 +15,50 @@ Organizations are Runpod's enterprise account model, designed for teams that nee | | Teams | Organizations | |---|---|---| | **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the Organization, surviving if any member leaves | -| **Billing** | Prepaid credit balance | Post-paid invoice only | +| **Billing** | Prepaid credit balance | Prepaid credit balance with org-level account and payment methods; postpaid invoicing available on request | | **Membership** | A user can own one team and belong to others | A user belongs to at most one Organization | | **Social unit** | Team (has an owner) | Group (leaderless, additive) | -| **Mutual exclusivity** | Compatible with personal accounts | One Organization or team at a time; joining removes you from any team, and personal resources you contribute are never returned. | +| **Mutual exclusivity** | Compatible with personal accounts | One Organization or team at a time | - Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. Joining an Organization removes you from any team you're in, and the personal resources you fold in are never returned, even if you later leave the Organization. +Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. Joining an Organization removes you from any team you're in, and the personal resources you fold in are never returned, even if you later leave the Organization. ## Key concepts -**Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is suspended or removed, their resources keep running and remain accessible to other members. +**Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership:** You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. +**Membership** — You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. -**Roles:** Four roles control what members can do: admin, billing, dev, and basic. There is no owner role; admin is the top level. See [Roles](/organizations/roles). +**Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). -**Groups:** Groups are the intra-org social unit, replacing Teams within an Organization. Groups are leaderless and additive: a user can belong to zero or many groups. See [Groups](/organizations/groups). +**Groups:** Groups are the intra-Organization social unit, replacing Teams within an Organization. Groups are leaderless and additive: a user can belong to zero or many groups. See [Groups](/organizations/groups). -**Billing:** Organizations use post-paid invoicing only. There is no credit balance, no credit top-up, and no payment method management in the console. See [Billing](/organizations/billing). +**Billing:** Organizations have a prepaid credit balance by default, with their own billing account and payment methods separate from any member's personal account. Postpaid invoicing is available on request. See [Billing](/organizations/billing). -**Access:** Org admins control how users authenticate: SSO, ad-hoc email invitations, or both. Admins can restrict access by email domain or IP range. See [Access and SSO](/organizations/access). +**Access:** Runpod provisions the Organization for your account. Org admins then invite members by exact email address; acceptance requires a verified email. See [Access](/organizations/access). **Resource tagging:** Tags are key-value pairs attached to resources for cost attribution and filtering. See [Resource tagging](/organizations/resource-tagging). ## Get started - - Understand what each role can do - - - Organize members within your Organization - - - How post-paid invoicing works - - - Configure SSO, invitations, and IP allowlists - - - Tag resources for cost attribution - - - Move your Team account to an Organization - + +Understand what each role can do + + +Organize members within your Organization + + +How Organization billing works + + +Invite members and manage access + + +Tag resources for cost attribution + + +Move your Team account to an Organization + From 9b21aeafebb739066fd1646c6ec06300fec4baf7 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:52:58 -0400 Subject: [PATCH 32/44] Fix groups.mdx: split sharing-modes into bullets, fix scope to all org-owned resources --- organizations/groups.mdx | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/organizations/groups.mdx b/organizations/groups.mdx index ca70fd00f..f540cac17 100644 --- a/organizations/groups.mdx +++ b/organizations/groups.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Groups" description: "Organize Organization members into leaderless, additive groups and learn how sharing modes control resource visibility across members." --- -Groups are the intra-org social unit, replacing Teams within an Organization. Use groups to organize members by team, project, function, or any other structure that fits your org. +Groups are the intra-Organization social unit, replacing Teams within an Organization. Use groups to organize members by team, project, function, or any other structure that fits your org. ## How groups work @@ -13,7 +13,11 @@ Groups are the intra-org social unit, replacing Teams within an Organization. Us ### Sharing modes -Your Organization can operate in one of two sharing modes: open or closed. In open sharing mode, all org members can see each other's Pods and endpoints regardless of group membership. In closed sharing mode, which is the default, group membership controls visibility: a non-admin member can only see resources belonging to users who share at least one group with them, and a member who belongs to no groups sees no other member's resources. Org admins can see all resources in the Organization regardless of sharing mode. +Your Organization can operate in one of two sharing modes: + +- **Open mode:** All org members can see each other's org-owned resources (Pods, Serverless endpoints, network volumes, Instant Clusters, templates, secrets, and more) regardless of group membership. +- **Closed mode (default):** Group membership controls resource visibility. A non-admin member can only see org-owned resources belonging to members who share at least one group with them. A member who belongs to no groups sees no other member's resources. +- **Org admins** can see all Organization resources regardless of sharing mode. ## Create a group From a619bc0491ee3b8ca21e7083518bc2b17dd0af65 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 13:58:45 -0400 Subject: [PATCH 33/44] Update overview.mdx --- organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index 05e787294..d0945e080 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -28,7 +28,7 @@ Organizations and teams are mutually exclusive: you belong to one or the other a **Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership** — You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. +**Membership:** You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. **Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). From 8e817a6f8bf5445dae00f266fa8bbda13bfb6192 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:02:42 -0400 Subject: [PATCH 34/44] Fix access.mdx: warn team owners that accepting deletes their team and removes all members --- organizations/access.mdx | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/organizations/access.mdx b/organizations/access.mdx index 32692cdfe..4967bf9a1 100644 --- a/organizations/access.mdx +++ b/organizations/access.mdx @@ -25,7 +25,11 @@ To accept an org invitation: 2. Sign in to Runpod with the account associated with the invited email address. 3. Accept the invitation in the console. -Accepting an invitation while you are a member of a team removes you from the team. Your personal resources are folded into the Organization and are not returned if you later leave. + +If you own a team, accepting an org invitation deletes your team and removes all of its members. The team's resources (Pods, endpoints, network volumes, secrets, and more) fold into the Organization permanently and are never returned. This cannot be undone. + +If you are a member (not an owner) of a team, accepting removes only you from that team. + ## Remove members From f24387815d8acd3128f4c72e3845cd882c593b78 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:03:23 -0400 Subject: [PATCH 35/44] Fix overview.mdx: add team-owner deletion warning to Warning block and Membership concept --- organizations/overview.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index d0945e080..b3b5f81f1 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -21,14 +21,14 @@ Organizations are currently in beta. Runpod provisions Organization accounts and | **Mutual exclusivity** | Compatible with personal accounts | One Organization or team at a time | -Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. Joining an Organization removes you from any team you're in, and the personal resources you fold in are never returned, even if you later leave the Organization. +Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. If you own a team, accepting an org invitation deletes your team and removes all of its members — the team's resources fold into the Organization permanently and are never returned. If you are only a member of a team (not the owner), accepting removes only you from that team. ## Key concepts **Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership:** You belong to one Organization or team at a time. Joining an Organization removes you from any team you're in and folds your existing personal resources (Pods, templates, secrets, and more) into the Organization. Those resources are never returned, even if you later leave. +**Membership** — You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. **Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). From 67f432d510868f8720daa1fe6572e31720c174fe Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:11:40 -0400 Subject: [PATCH 36/44] Fix docs.json: correct Organizations pages indentation to match sibling groups --- docs.json | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/docs.json b/docs.json index 56d6e65cb..4e424a41c 100644 --- a/docs.json +++ b/docs.json @@ -290,14 +290,14 @@ { "group": "Organizations", "pages": [ - "organizations/overview", - "organizations/roles", - "organizations/groups", - "organizations/billing", - "organizations/access", - "organizations/resource-tagging", - "organizations/migrate-from-teams" - ] + "organizations/overview", + "organizations/roles", + "organizations/groups", + "organizations/billing", + "organizations/access", + "organizations/resource-tagging", + "organizations/migrate-from-teams" + ] }, { "group": "Integrations", From 2cd0c54601abf337a8f9d4119ce552562067b7bc Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:12:11 -0400 Subject: [PATCH 37/44] Fix migrate-from-teams.mdx: remove duplicate resource-reclaim, rename SharedApiKey to org S3 credentials --- organizations/migrate-from-teams.mdx | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx index 982ae85ef..e2c656e2c 100644 --- a/organizations/migrate-from-teams.mdx +++ b/organizations/migrate-from-teams.mdx @@ -23,7 +23,7 @@ Your Team is deleted during migration and cannot be restored. Personal resources ### Tell members about resource transfer -Every participant's personal resources (Pods, templates, secrets, and more) fold into the Organization during the merge and cannot be reclaimed. Make sure your team members understand this before the staff run. +Make sure your team members understand that any personal resources they contribute during migration are folded into the Organization permanently before the staff run. ### Check for migration blockers @@ -37,9 +37,9 @@ The following conditions block migration and must be resolved before Runpod can Every team that any participant belongs to must be included in the same merge. If a participant is in or owns a team outside the merge set, migration is blocked. That participant must leave that team first, or the other team must be added to the merge. -### Rotate SharedApiKey credentials +### Rotate org S3 credentials -If your team uses SharedApiKey (Runpod's S3-compatible storage credentials), rotate credentials before removing any member post-migration. When a member is removed from an Organization, their storage credentials are revoked immediately. +If your team uses Runpod's S3-compatible storage credentials, rotate them before removing any member post-migration. When a member is removed from an organization, their org S3 credentials are revoked immediately. Do this in order: 1. Create replacement credentials attributed to a remaining admin. From baed16cfad1dffb0c9577a210f97017bac027bb4 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:12:51 -0400 Subject: [PATCH 38/44] Fix roles.mdx: rephrase admin-only claims, add custom role limits (name cap, reserved names, grant ceiling) --- organizations/roles.mdx | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/organizations/roles.mdx b/organizations/roles.mdx index 3ae3af2a9..9dd3f8460 100644 --- a/organizations/roles.mdx +++ b/organizations/roles.mdx @@ -37,7 +37,12 @@ See [Groups](/organizations/groups) for how open and closed sharing modes determ ## Custom roles -Org admins can define up to 25 custom roles per Organization. Custom roles are composed from individual capabilities, letting you grant exactly the permissions your team needs. +Members with the member-management capability can define up to 25 custom roles per organization. The admin role includes this capability by default. Custom roles are composed from individual capabilities, letting you grant exactly the permissions your team needs. + +Keep these limits in mind when creating custom roles: + +- Role names can be up to 191 characters. Built-in role names (admin, billing, dev, basic) are reserved and cannot be used. +- You can only grant capabilities you already hold. You cannot create a custom role with more permissions than your own role. To create a custom role: @@ -48,7 +53,7 @@ To create a custom role: ## Assigning roles -Only org admins can assign or change member roles. To update a member's role: +Members with the member-management capability can assign or change member roles. The admin role includes this capability by default. To update a member's role: 1. Go to **Settings → Members** in the console. 2. Find the member and click the role dropdown next to their name. From 6796726f31d33b8f3ed41876e9aaa21d02f50adc Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:13:22 -0400 Subject: [PATCH 39/44] Fix access.mdx: rephrase admin-only invite/remove to member-management capability --- organizations/access.mdx | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/organizations/access.mdx b/organizations/access.mdx index 4967bf9a1..4d8914ad0 100644 --- a/organizations/access.mdx +++ b/organizations/access.mdx @@ -8,7 +8,7 @@ Runpod provisions Organization accounts. Once your org is provisioned, org admin ## Invite members -Only org admins can invite members. +Members with the member-management capability can invite members. The admin role includes this capability by default. 1. Go to **Settings → Members** in the console. 2. Click **Invite Member**. @@ -33,7 +33,7 @@ If you are a member (not an owner) of a team, accepting removes only you from th ## Remove members -Only org admins can remove members. When a member is removed: +Members with the member-management capability can remove members. The admin role includes this capability by default. When a member is removed: - Their org S3 credentials are revoked immediately. - Their Pods, endpoints, and other resources remain in the Organization. From c052adbcc3a30fdd21c03e324bcce94a153be938 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:13:50 -0400 Subject: [PATCH 40/44] Fix pods/use-ssh.mdx: correct SSH key override variable from SSH_PUBLIC_KEY to PUBLIC_KEY --- pods/configuration/use-ssh.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/pods/configuration/use-ssh.mdx b/pods/configuration/use-ssh.mdx index 6a06cdba8..da1768671 100644 --- a/pods/configuration/use-ssh.mdx +++ b/pods/configuration/use-ssh.mdx @@ -70,7 +70,7 @@ SSH key authentication is recommended for security and convenience. ### Override your public key for a specific Pod -Runpod will attempt to automatically inject the public SSH keys added in your account settings for authentication when connecting using the [basic terminal method](#basic-ssh-with-key-authentication). If you prefer to use a different public key for a specific Pod, you can override the default by setting the `SSH_PUBLIC_KEY` [environment variable](/pods/templates/environment-variables) for that Pod. +Runpod will attempt to automatically inject the public SSH keys added in your account settings for authentication when connecting using the [basic terminal method](#basic-ssh-with-key-authentication). If you prefer to use a different public key for a specific Pod, you can override the default by setting the `PUBLIC_KEY` [environment variable](/pods/templates/environment-variables) for that Pod. When `PUBLIC_KEY` is already set, Runpod skips injecting the account-level keys. ## Basic SSH with key authentication From 3c1b682d5a14494144a675886a686c919b179c54 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:23:04 -0400 Subject: [PATCH 41/44] Update overview.mdx --- organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index b3b5f81f1..bd895ccda 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -28,7 +28,7 @@ Organizations and teams are mutually exclusive: you belong to one or the other a **Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership** — You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. +**Membership** You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. **Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). From 43d155086d63bc1e641e4939aa1fd529f12e6104 Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 14:26:53 -0400 Subject: [PATCH 42/44] Update overview.mdx --- organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index bd895ccda..b7f64caca 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -28,7 +28,7 @@ Organizations and teams are mutually exclusive: you belong to one or the other a **Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership** You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. +**Membership:** You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. **Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). From 81a38345cba72a36b33965415298b1fffd72aa84 Mon Sep 17 00:00:00 2001 From: "promptless[bot]" Date: Wed, 16 Sep 2026 18:34:54 +0000 Subject: [PATCH 43/44] Lowercase common-noun organization/team in prose under organizations/ Applies @lavanya-gunreddi's PR #682 review request: lowercase organization and team when used as common nouns in prose, keeping them capitalized as product/model names (Organizations, Teams), at sentence start, and in headings, frontmatter, link text, and table product-name headers. --- organizations/access.mdx | 8 ++++---- organizations/billing.mdx | 8 ++++---- organizations/groups.mdx | 10 +++++----- organizations/migrate-from-teams.mdx | 20 ++++++++++---------- organizations/overview.mdx | 28 ++++++++++++++-------------- organizations/resource-tagging.mdx | 2 +- organizations/roles.mdx | 12 ++++++------ 7 files changed, 44 insertions(+), 44 deletions(-) diff --git a/organizations/access.mdx b/organizations/access.mdx index 4d8914ad0..32960be89 100644 --- a/organizations/access.mdx +++ b/organizations/access.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Access" description: "Control who can join your Organization with email invitations. Admins invite members by exact email address, with 14-day expiry and a 150-invite cap." --- -Runpod provisions Organization accounts. Once your org is provisioned, org admins invite members by sending invitations to their exact email addresses. +Runpod provisions organization accounts. Once your org is provisioned, org admins invite members by sending invitations to their exact email addresses. ## Invite members @@ -15,7 +15,7 @@ Members with the member-management capability can invite members. The admin role 3. Enter the member's exact email address and select their role. 4. Click **Send Invite**. -The invited user receives an email with a link to accept. They must have a verified Runpod account to accept. Invitations expire after 14 days, and each Organization can have up to 150 pending invitations at a time. +The invited user receives an email with a link to accept. They must have a verified Runpod account to accept. Invitations expire after 14 days, and each organization can have up to 150 pending invitations at a time. ## Accept an invitation @@ -26,7 +26,7 @@ To accept an org invitation: 3. Accept the invitation in the console. -If you own a team, accepting an org invitation deletes your team and removes all of its members. The team's resources (Pods, endpoints, network volumes, secrets, and more) fold into the Organization permanently and are never returned. This cannot be undone. +If you own a team, accepting an org invitation deletes your team and removes all of its members. The team's resources (Pods, endpoints, network volumes, secrets, and more) fold into the organization permanently and are never returned. This cannot be undone. If you are a member (not an owner) of a team, accepting removes only you from that team. @@ -36,7 +36,7 @@ If you are a member (not an owner) of a team, accepting removes only you from th Members with the member-management capability can remove members. The admin role includes this capability by default. When a member is removed: - Their org S3 credentials are revoked immediately. -- Their Pods, endpoints, and other resources remain in the Organization. +- Their Pods, endpoints, and other resources remain in the organization. To remove a member, go to **Settings → Members**, find the member, and click **Remove**. diff --git a/organizations/billing.mdx b/organizations/billing.mdx index c7461a788..16c04126b 100644 --- a/organizations/billing.mdx +++ b/organizations/billing.mdx @@ -4,13 +4,13 @@ sidebarTitle: "Billing" description: "Learn how Organization billing works, including credit balances, payment methods, Billing Explorer access, and cost centers for spend attribution." --- -Organization billing uses a prepaid credit balance by default. Each Organization has its own billing account with its own credit balance and payment methods, separate from any member's personal account. Postpaid invoicing is an enterprise option that Runpod enables on request. +Organization billing uses a prepaid credit balance by default. Each organization has its own billing account with its own credit balance and payment methods, separate from any member's personal account. Postpaid invoicing is an enterprise option that Runpod enables on request. ## How billing works -All billing events from all org members are attributed to the Organization's billing account. Org admins and billing roles manage the org credit balance and payment methods in the console. +All billing events from all org members are attributed to the organization's billing account. Org admins and billing roles manage the org credit balance and payment methods in the console. -The Organization billing account: +The organization billing account: - Maintains its own prepaid credit balance, separate from any member's personal credits. - Has its own payment methods configured in the console. @@ -28,4 +28,4 @@ The **billing role** can create, update, and delete cost center labels to attrib ## Billing questions -For invoice questions, payment terms, or billing disputes, contact Runpod's finance team directly. Include your Organization name and the relevant billing period in your request. +For invoice questions, payment terms, or billing disputes, contact Runpod's finance team directly. Include your organization name and the relevant billing period in your request. diff --git a/organizations/groups.mdx b/organizations/groups.mdx index f540cac17..5b8452952 100644 --- a/organizations/groups.mdx +++ b/organizations/groups.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Groups" description: "Organize Organization members into leaderless, additive groups and learn how sharing modes control resource visibility across members." --- -Groups are the intra-Organization social unit, replacing Teams within an Organization. Use groups to organize members by team, project, function, or any other structure that fits your org. +Groups are the intra-organization social unit, replacing Teams within an organization. Use groups to organize members by team, project, function, or any other structure that fits your org. ## How groups work @@ -13,11 +13,11 @@ Groups are the intra-Organization social unit, replacing Teams within an Organiz ### Sharing modes -Your Organization can operate in one of two sharing modes: +Your organization can operate in one of two sharing modes: - **Open mode:** All org members can see each other's org-owned resources (Pods, Serverless endpoints, network volumes, Instant Clusters, templates, secrets, and more) regardless of group membership. - **Closed mode (default):** Group membership controls resource visibility. A non-admin member can only see org-owned resources belonging to members who share at least one group with them. A member who belongs to no groups sees no other member's resources. -- **Org admins** can see all Organization resources regardless of sharing mode. +- **Org admins** can see all organization resources regardless of sharing mode. ## Create a group @@ -40,11 +40,11 @@ Only org admins can create groups. 1. Go to **Settings → Groups** and select the group. 2. Find the member and click **Remove**. -Removing a member from a group does not remove them from the Organization. +Removing a member from a group does not remove them from the organization. ## Delete a group 1. Go to **Settings → Groups** and select the group. 2. Click **Delete Group** and confirm. -Deleting a group does not affect the members in it. They remain in the Organization. +Deleting a group does not affect the members in it. They remain in the organization. diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx index e2c656e2c..b8163dbf0 100644 --- a/organizations/migrate-from-teams.mdx +++ b/organizations/migrate-from-teams.mdx @@ -7,23 +7,23 @@ description: "Learn what happens when your Team account is migrated to an Organi Migration from Teams to Organizations is performed by Runpod staff. You cannot self-migrate. If you're an enterprise customer and want to migrate, contact your Runpod account representative. -Your Team is deleted during migration and cannot be restored. Personal resources contributed by members during the merge are folded into the Organization permanently and are never returned, even if a member later leaves. +Your team is deleted during migration and cannot be restored. Personal resources contributed by members during the merge are folded into the organization permanently and are never returned, even if a member later leaves. ## What happens during migration -1. A Runpod staff member runs the migration for your Team. A single migration can merge multiple teams into one Organization or extend an existing one. -2. The Team is disbanded. Your team owner account becomes an **admin** of the new Organization. -3. All org-aware resources previously owned by the Team transfer to the Organization automatically, including Pods, endpoints, network volumes, Instant Clusters, templates, secrets, registry auth, Flash apps, reservations, and S3 credentials. -4. All team members join the Organization automatically. Team roles map to org roles using these rules: team owners become admin; members with an unknown or unmapped role default to basic; a member who belongs to multiple teams keeps the highest role across all teams. -5. Every participant's personal resources fold into the Organization during the merge and cannot be reclaimed. -6. Each team in the merge becomes a group in the Organization. +1. A Runpod staff member runs the migration for your team. A single migration can merge multiple teams into one organization or extend an existing one. +2. The team is disbanded. Your team owner account becomes an **admin** of the new organization. +3. All org-aware resources previously owned by the team transfer to the organization automatically, including Pods, endpoints, network volumes, Instant Clusters, templates, secrets, registry auth, Flash apps, reservations, and S3 credentials. +4. All team members join the organization automatically. Team roles map to org roles using these rules: team owners become admin; members with an unknown or unmapped role default to basic; a member who belongs to multiple teams keeps the highest role across all teams. +5. Every participant's personal resources fold into the organization during the merge and cannot be reclaimed. +6. Each team in the merge becomes a group in the organization. ## What to do before migration ### Tell members about resource transfer -Make sure your team members understand that any personal resources they contribute during migration are folded into the Organization permanently before the staff run. +Make sure your team members understand that any personal resources they contribute during migration are folded into the organization permanently before the staff run. ### Check for migration blockers @@ -48,7 +48,7 @@ Do this in order: ### Understand SSH key behavior -For Pods deployed by the Organization, Runpod sets `PUBLIC_KEY` to the union of all current org members' SSH public keys (see [Connect to a Pod via SSH](/pods/configuration/use-ssh) for how key injection works). Shared SSH access works automatically: every member whose key is on file when the Pod is created can connect. +For Pods deployed by the organization, Runpod sets `PUBLIC_KEY` to the union of all current org members' SSH public keys (see [Connect to a Pod via SSH](/pods/configuration/use-ssh) for how key injection works). Shared SSH access works automatically: every member whose key is on file when the Pod is created can connect. Because the key set is frozen at creation, adding or removing a member's key affects only Pods deployed after that change. Existing Pods keep the keys they were created with until they are redeployed. @@ -59,6 +59,6 @@ To override the injected keys on a specific Pod, set the `PUBLIC_KEY` environmen Once migration is complete: - The `console.runpod.io/team` page is no longer accessible. -- Your Organization dashboard is available at `console.runpod.io`. +- Your organization dashboard is available at `console.runpod.io`. - Review your migrated members and their mapped roles in **Settings → Members**. - Set up groups to organize your migrated members. See [Groups](/organizations/groups). diff --git a/organizations/overview.mdx b/organizations/overview.mdx index b7f64caca..02a5c7573 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -4,39 +4,39 @@ sidebarTitle: "Overview" description: "Manage enterprise GPU workloads with centralized resource ownership, billing, and access control. Organizations replace Teams for enterprise accounts." --- -Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an Organization is a first-class entity that owns all resources (compute, storage, secrets, and templates) independent of any individual user. +Organizations are Runpod's enterprise account model, designed for teams that need centralized resource ownership, billing, and access control. Unlike Teams, an organization is a first-class entity that owns all resources (compute, storage, secrets, and templates) independent of any individual user. -Organizations are currently in beta. Runpod provisions Organization accounts and enables them for your account. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). +Organizations are currently in beta. Runpod provisions organization accounts and enables them for your account. If you're an existing Team account customer, see [Migrate from Teams](/organizations/migrate-from-teams). ## How Organizations differ from Teams | | Teams | Organizations | |---|---|---| -| **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the Organization, surviving if any member leaves | +| **Resource ownership** | Resources owned by the team owner's user account | Resources owned by the organization, surviving if any member leaves | | **Billing** | Prepaid credit balance | Prepaid credit balance with org-level account and payment methods; postpaid invoicing available on request | -| **Membership** | A user can own one team and belong to others | A user belongs to at most one Organization | +| **Membership** | A user can own one team and belong to others | A user belongs to at most one organization | | **Social unit** | Team (has an owner) | Group (leaderless, additive) | -| **Mutual exclusivity** | Compatible with personal accounts | One Organization or team at a time | +| **Mutual exclusivity** | Compatible with personal accounts | One organization or team at a time | -Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. If you own a team, accepting an org invitation deletes your team and removes all of its members — the team's resources fold into the Organization permanently and are never returned. If you are only a member of a team (not the owner), accepting removes only you from that team. +Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. If you own a team, accepting an org invitation deletes your team and removes all of its members — the team's resources fold into the organization permanently and are never returned. If you are only a member of a team (not the owner), accepting removes only you from that team. ## Key concepts -**Ownership:** All resources created inside an Organization are owned by the Organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. +**Ownership:** All resources created inside an organization are owned by the organization, not the member who created them. If a member is removed, their resources keep running and remain accessible to other members. -**Membership:** You belong to one Organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the Organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. +**Membership:** You belong to one organization or team at a time. If you own a team, accepting an org invitation deletes that team and removes all its members; the team's resources fold into the organization permanently. If you are a team member (not the owner), only you are removed from the team. In both cases, personal resources you fold in are never returned. -**Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). +**Roles:** Four built-in roles control what members can do: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per organization. There is no owner role; admin is the top level. See [Roles](/organizations/roles). -**Groups:** Groups are the intra-Organization social unit, replacing Teams within an Organization. Groups are leaderless and additive: a user can belong to zero or many groups. See [Groups](/organizations/groups). +**Groups:** Groups are the intra-organization social unit, replacing Teams within an organization. Groups are leaderless and additive: a user can belong to zero or many groups. See [Groups](/organizations/groups). **Billing:** Organizations have a prepaid credit balance by default, with their own billing account and payment methods separate from any member's personal account. Postpaid invoicing is available on request. See [Billing](/organizations/billing). -**Access:** Runpod provisions the Organization for your account. Org admins then invite members by exact email address; acceptance requires a verified email. See [Access](/organizations/access). +**Access:** Runpod provisions the organization for your account. Org admins then invite members by exact email address; acceptance requires a verified email. See [Access](/organizations/access). **Resource tagging:** Tags are key-value pairs attached to resources for cost attribution and filtering. See [Resource tagging](/organizations/resource-tagging). @@ -47,10 +47,10 @@ Organizations and teams are mutually exclusive: you belong to one or the other a Understand what each role can do -Organize members within your Organization +Organize members within your organization -How Organization billing works +How organization billing works Invite members and manage access @@ -59,6 +59,6 @@ Invite members and manage access Tag resources for cost attribution -Move your Team account to an Organization +Move your team account to an organization diff --git a/organizations/resource-tagging.mdx b/organizations/resource-tagging.mdx index 2ddd02eea..95186441b 100644 --- a/organizations/resource-tagging.mdx +++ b/organizations/resource-tagging.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Resource tagging" description: "Attach key-value tags to Organization resources to track spend, filter usage, and attribute costs across teams, projects, and cost centers." --- -Tags are key-value pairs you attach to Organization resources to track spend, filter usage, and attribute costs across teams or projects. Tagging is supported on Pods, Serverless endpoints, network volumes, and Instant Clusters. +Tags are key-value pairs you attach to organization resources to track spend, filter usage, and attribute costs across teams or projects. Tagging is supported on Pods, Serverless endpoints, network volumes, and Instant Clusters. ## Tag format diff --git a/organizations/roles.mdx b/organizations/roles.mdx index 9dd3f8460..d70d0994b 100644 --- a/organizations/roles.mdx +++ b/organizations/roles.mdx @@ -4,7 +4,7 @@ sidebarTitle: "Roles" description: "Control what Organization members can do with four built-in roles plus custom roles. Learn which actions each role can perform." --- -Every member of an Organization is assigned a role. Four built-in roles ship with every Organization: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per Organization composed from individual capabilities. There is no owner role; admin is the highest built-in level. +Every member of an organization is assigned a role. Four built-in roles ship with every organization: admin, billing, dev, and basic. Admins can also define up to 25 custom roles per organization composed from individual capabilities. There is no owner role; admin is the highest built-in level. ## Role overview @@ -17,21 +17,21 @@ Every member of an Organization is assigned a role. Four built-in roles ship wit ## Role descriptions -**Admin:** Full Organization management. Admins can invite and remove members, manage groups and roles, manage billing and payment methods, and create, update, or delete any org compute resource. +**Admin:** Full organization management. Admins can invite and remove members, manage groups and roles, manage billing and payment methods, and create, update, or delete any org compute resource. **Billing:** View invoices and Billing Explorer, manage payment methods and billing settings, manage cost centers, and read-only listing of all org compute resources. Cannot create or modify computing resources, and cannot manage members or groups. **Dev:** Can create and manage computing resources: Pods, Serverless endpoints, network volumes, Instant Clusters, and templates. Cannot manage members, groups, billing configuration, or cost centers. -**Basic:** Can access and use existing Organization resources visible to them based on the sharing mode. Cannot create new resources. +**Basic:** Can access and use existing organization resources visible to them based on the sharing mode. Cannot create new resources. ## Resource visibility -Which resources a member can see depends on their role and the Organization's sharing mode. +Which resources a member can see depends on their role and the organization's sharing mode. -- **Admin:** Can see and manage all Organization resources regardless of sharing mode. +- **Admin:** Can see and manage all organization resources regardless of sharing mode. - **Dev:** Can create, update, and delete resources they own or that belong to members who share at least one group with them (in closed sharing mode). -- **Basic:** Can use Organization resources visible to them based on the sharing mode. +- **Basic:** Can use organization resources visible to them based on the sharing mode. See [Groups](/organizations/groups) for how open and closed sharing modes determine which resources members can see. From 2703236ee454e3e2bcce501e547482be13127fda Mon Sep 17 00:00:00 2001 From: lgunreddi Date: Wed, 16 Sep 2026 15:04:21 -0400 Subject: [PATCH 44/44] Update overview.mdx --- organizations/overview.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/organizations/overview.mdx b/organizations/overview.mdx index 02a5c7573..613c889d1 100644 --- a/organizations/overview.mdx +++ b/organizations/overview.mdx @@ -21,7 +21,7 @@ Organizations are currently in beta. Runpod provisions organization accounts and | **Mutual exclusivity** | Compatible with personal accounts | One organization or team at a time | -Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. If you own a team, accepting an org invitation deletes your team and removes all of its members — the team's resources fold into the organization permanently and are never returned. If you are only a member of a team (not the owner), accepting removes only you from that team. +Organizations and teams are mutually exclusive: you belong to one or the other at any time, not both. If you own a team, accepting an org invitation deletes your team and removes all of its members. The team's resources fold into the organization permanently and are never returned. If you are only a member of a team (not the owner), accepting removes only you from that team. ## Key concepts