Lg org setup team mig

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": [

organizations/access.mdx

@@ -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`).
+
+<Warning>
+  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.
+</Warning>
+
+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.
+
+<Warning>
+  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.
+</Warning>
+
+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.

organizations/billing.mdx

@@ -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.

organizations/groups.mdx

@@ -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.

organizations/migrate-from-teams.mdx

@@ -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.
+
+<Warning>
+  Migration is permanent and irreversible. Once your Team is migrated to an Organization, there is no path back to the Team model.
+</Warning>
+
+## 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.

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.
+
+<Note>
+  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).
+</Note>
+
+## 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 |
+
+<Warning>
+  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.
+</Warning>
+
+## 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
+
+<CardGroup cols={2}>
+  <Card title="Roles" icon="user-shield" href="/organizations/roles">
+    Understand what each role can do
+  </Card>
+  <Card title="Groups" icon="users" href="/organizations/groups">
+    Organize members within your Organization
+  </Card>
+  <Card title="Billing" icon="receipt" href="/organizations/billing">
+    How post-paid invoicing works
+  </Card>
+  <Card title="Access and SSO" icon="lock" href="/organizations/access">
+    Configure SSO, invitations, and IP allowlists
+  </Card>
+  <Card title="Resource tagging" icon="tag" href="/organizations/resource-tagging">
+    Tag resources for cost attribution
+  </Card>
+  <Card title="Migrate from Teams" icon="arrow-right-arrow-left" href="/organizations/migrate-from-teams">
+    Move your Team account to an Organization
+  </Card>
+</CardGroup>

organizations/resource-tagging.mdx

@@ -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.

organizations/roles.mdx

@@ -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.