diff --git a/docs.json b/docs.json index f01e4fd7a..6d0dea866 100644 --- a/docs.json +++ b/docs.json @@ -288,14 +288,15 @@ ] }, { - "group": "Organizations (Beta)", + "group": "Organizations", "pages": [ - "organizations/orgs-overview", - "organizations/orgs-access", - "organizations/org-roles", - "organizations/orgs-groups", - "organizations/orgs-resource-tagging", - "organizations/orgs-billing" + "organizations/overview", + "organizations/roles", + "organizations/groups", + "organizations/billing", + "organizations/access", + "organizations/resource-tagging", + "organizations/migrate-from-teams" ] }, { diff --git a/organizations/access.mdx b/organizations/access.mdx new file mode 100644 index 000000000..32960be89 --- /dev/null +++ b/organizations/access.mdx @@ -0,0 +1,45 @@ +--- +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." +--- + +Runpod provisions organization accounts. Once your org is provisioned, org admins invite members by sending invitations to their exact email addresses. + +## 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**. +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. + +## Accept an invitation + +To accept an org invitation: + +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. + + +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 + +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. + +To remove a member, go to **Settings → Members**, find the member, and click **Remove**. + +## Planned features + +SSO (SAML/OIDC), email domain allowlists, and IP allowlists are not yet available. They are planned for a future release. diff --git a/organizations/billing.mdx b/organizations/billing.mdx new file mode 100644 index 000000000..16c04126b --- /dev/null +++ b/organizations/billing.mdx @@ -0,0 +1,31 @@ +--- +title: "Billing" +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. + +## 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. + +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. +- Supports auto-pay and auto-reload settings. + +## Viewing usage + +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. + +## 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. diff --git a/organizations/groups.mdx b/organizations/groups.mdx new file mode 100644 index 000000000..5b8452952 --- /dev/null +++ b/organizations/groups.mdx @@ -0,0 +1,50 @@ +--- +title: "Groups" +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. + +## 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. + +### 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. + +## 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. diff --git a/organizations/migrate-from-teams.mdx b/organizations/migrate-from-teams.mdx new file mode 100644 index 000000000..b8163dbf0 --- /dev/null +++ b/organizations/migrate-from-teams.mdx @@ -0,0 +1,64 @@ +--- +title: "Migrate from Teams" +sidebarTitle: "Migrate from Teams" +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. + + +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. + +## 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. + +### 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 + +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 org S3 credentials + +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. +2. Update all external service configurations to use the new credentials. +3. Then remove the member. + +### 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. + +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 `PUBLIC_KEY` environment variable on that Pod. When `PUBLIC_KEY` is already set on a Pod, Runpod skips the member-key injection. + +## 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`. +- 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 new file mode 100644 index 000000000..613c889d1 --- /dev/null +++ b/organizations/overview.mdx @@ -0,0 +1,64 @@ +--- +title: "Organizations" +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 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 | +| **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 | + + +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. 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). + +**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). + +**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 organization billing works + + +Invite members and manage access + + +Tag resources for cost attribution + + +Move your team account to an organization + + diff --git a/organizations/resource-tagging.mdx b/organizations/resource-tagging.mdx new file mode 100644 index 000000000..95186441b --- /dev/null +++ b/organizations/resource-tagging.mdx @@ -0,0 +1,38 @@ +--- +title: "Resource tagging" +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. + +## Tag format + +- 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. +- **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 + +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 + +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. +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. diff --git a/organizations/roles.mdx b/organizations/roles.mdx new file mode 100644 index 000000000..d70d0994b --- /dev/null +++ b/organizations/roles.mdx @@ -0,0 +1,62 @@ +--- +title: "Roles" +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. + +## Role overview + +| Role | Manage members & groups | Manage billing & cost centers | Create & manage resources | Use existing resources | +|---|---|---|---|---| +| **Admin** | ✓ | ✓ | ✓ | ✓ | +| **Billing** | — | ✓ | — | List only | +| **Dev** | — | — | ✓ | ✓ | +| **Basic** | — | — | — | ✓ | + +## 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. + +**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. + +## Resource visibility + +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 + +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: + +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 + +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. +3. Select the new role and confirm. + +Role changes take effect immediately. 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