diff --git a/accounts-billing/manage-accounts.mdx b/accounts-billing/manage-accounts.mdx
index 49b326997..f448d6433 100644
--- a/accounts-billing/manage-accounts.mdx
+++ b/accounts-billing/manage-accounts.mdx
@@ -29,19 +29,11 @@ You can revert your account back to a personal account at any time. To revert, s
## Invite team members
-Team accounts can invite new members to collaborate. Each invitation includes a specific role that determines the member's permissions.
+Team accounts can invite new members to collaborate, and each invitation includes a specific role that determines the member's permissions.
-To invite a new member:
-
-1. Navigate to the [Team page](https://www.console.runpod.io/team) in the Runpod console.
-2. In the **Members** section, select **Invite New Member**.
-3. Choose [the appropriate role](#roles-and-permissions) for the new member.
-4. Enter the email address of the person you want to invite and click **Create Invite**.
-5. Copy the generated invitation link from the **Pending Invites** section and share it with the person you want to invite.
-
-Invitation links remain active until used or manually revoked. You can view all pending invitations in the team management interface.
+For step-by-step instructions on inviting a member and choosing their role, see [Assign a role to a team member](/accounts-billing/organizations/roles-and-permissions#assign-a-role-to-a-team-member).
## Join a team
@@ -50,52 +42,17 @@ When invited to join a team, you'll receive an invitation link from a team membe
1. Click the invitation link provided by the team member.
2. Select **Join Team** to accept the invitation.
-Your account will gain access to the team's resources based on the role assigned to you.
+Your account will gain access to the team's resources based on the role assigned to you. To see what your assigned role allows, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions).
## Roles and permissions
-Runpod provides four distinct roles to control access within team accounts. Each role includes specific permissions designed for different responsibilities.
-
-| Permission | Basic | Billing | Dev | Admin |
-|------------|-------|---------|-----|-------|
-| Access team account | ✅ | ✅ | ✅ | ✅ |
-| Connect to existing Pods | ✅ | ❌ | ✅ | ✅ |
-| Create/delete/start/stop Pods | ❌ | ❌ | ✅ | ✅ |
-| Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ |
-| Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ |
-| Connect to existing Instant Clusters | ✅ | ❌ | ✅ | ✅ |
-| Create/delete/start/stop Instant Clusters | ❌ | ❌ | ❌ | ✅ |
-| Create/update/delete network volumes | ❌ | ❌ | ✅ | ✅ |
-| View billing information | ❌ | ✅ | ❌ | ✅ |
-| Manage payment methods | ❌ | ✅ | ❌ | ✅ |
-| Invite team members | ❌ | ❌ | ❌ | ✅ |
-| Manage team permissions | ❌ | ❌ | ❌ | ✅ |
-| Modify team account settings | ❌ | ❌ | ❌ | ✅ |
-| Access audit logs | ❌ | ❌ | ❌ | ✅ |
-
-### Basic role
-
-The basic role provides essential access for users who need to work with existing resources without management capabilities.
-
-This role allows users to access the team account and connect to already-deployed computing resources (e.g., Pods and Serverless endpoints) for development work. Users with this role cannot view billing information, start or stop Pods, or create new resources.
-
-### Billing role
+Runpod team accounts provide four built-in roles (Basic, Billing, Dev, and Admin) that control access to Pods, Serverless endpoints, network volumes, and billing. Each role grants a different set of permissions.
-The billing role focuses exclusively on financial management aspects of the account.
+For the full permissions matrix and guidance on assigning and revoking roles, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions).
-Users with this role can access all billing information, manage payment methods, and view invoices. They cannot access computing resources, making this role ideal for finance team members who need billing access without operational permissions.
-
-### Dev role
-
-The dev role extends basic permissions with additional capabilities for active development work.
-
-This role includes all basic permissions plus the ability to start, stop, and create Pods. Developers can fully manage computing resources for their work while remaining restricted from billing information and account settings.
-
-### Admin role
-
-The admin role provides complete control over all account features and settings.
-
-Administrators have unrestricted access to manage team members, configure account settings, handle billing, and control all team computing resources. This role should be reserved for team leaders and trusted members who need full account access.
+
+Apply the principle of least privilege by assigning each member the minimum role necessary for their work.
+
## Account spend limits
@@ -113,9 +70,7 @@ Regular review of audit logs helps identify unusual activity and ensures team me
## Best practices
-When managing team accounts, establish clear role assignments based on each member's responsibilities. Regularly review team membership and remove access for members who no longer need it.
-
-For enhanced security, use the principle of least privilege by assigning the minimum role necessary for each team member's work. Consider creating separate accounts for billing management to isolate financial access from technical operations.
+When managing team accounts, regularly review team membership and remove access for members who no longer need it.
Monitor audit logs periodically to ensure compliance with your organization's policies and identify any unauthorized activities early.
@@ -126,4 +81,4 @@ After setting up your account and team you can:
* [Create API keys](/get-started/credentials) to enable programmatic access to Runpod services.
* [Deploy your first Pod](/get-started) to start using GPU resources.
* Configure [Serverless endpoints](/serverless/overview) for scalable AI inference.
-* Set up [billing and payment methods](https://console.runpod.io/user/billing) for your team.
\ No newline at end of file
+* Set up [billing and payment methods](https://console.runpod.io/user/billing) for your team.
diff --git a/accounts-billing/organizations/overview.mdx b/accounts-billing/organizations/overview.mdx
new file mode 100644
index 000000000..e5f857a00
--- /dev/null
+++ b/accounts-billing/organizations/overview.mdx
@@ -0,0 +1,20 @@
+---
+title: "Organizations"
+sidebarTitle: "Overview"
+description: "Manage your Runpod organization: assign roles and permissions, share SSH keys across members, and tag resources by team, project, or environment."
+tag: "Beta"
+---
+
+Organizations let you collaborate with your team on Runpod. Members share access to resources, and admins control who can do what through roles and permissions.
+
+## What you can manage
+
+**Roles and permissions**: assign roles to organization members to control access to Pods, endpoints, billing, and organization settings. See [Roles and permissions](/accounts-billing/organizations/roles-and-permissions).
+
+**SSH key management**: each member adds their own SSH public key in their Runpod account settings. When your organization deploys a Pod, Runpod injects the public keys of all current members into that Pod so any member can connect with their matching private key. See [SSH key management](/accounts-billing/organizations/ssh-key-management).
+
+**Resource tagging**: create and apply key/value tags to Pods, endpoints, network volumes, and Instant Clusters to organize resources by team, project, or environment. See [Resource tagging](/accounts-billing/organizations/resource-tagging).
+
+## Managing your organization
+
+To manage your organization's members and settings, navigate to **Settings → Organization** in the [Runpod console](https://console.runpod.io).
diff --git a/accounts-billing/organizations/resource-tagging.mdx b/accounts-billing/organizations/resource-tagging.mdx
new file mode 100644
index 000000000..9023a7c73
--- /dev/null
+++ b/accounts-billing/organizations/resource-tagging.mdx
@@ -0,0 +1,77 @@
+---
+title: "Resource tags"
+description: "Organize, filter, and track usage of your Runpod Pods, endpoints, network volumes, and Instant Clusters across your organization with shared key-value tags."
+tag: "Beta"
+---
+
+Resource tags are key-value labels you create and apply to your Runpod resources to organize, filter, and track usage across your organization. By tagging resources, you can group them in ways that reflect how your teams, projects, and environments are structured.
+
+A tag key can be any string except one that begins with the reserved `runpod:` prefix. The tag value is optional and can be left blank.
+
+Tags are shared across your organization rather than defined per user. Once a tag exists, anyone working in your organization can apply it to supported resources, so the same set of labels stays consistent no matter who created a given resource.
+
+## Supported resources
+
+You can apply resource tags to the following resource types:
+
+| Resource type | Description |
+|--------------|-------------|
+| Pods | Tag individual Pods to organize compute resources. |
+| Serverless endpoints | Tag endpoints to group related Serverless workloads. |
+| Network volumes | Tag network volumes to track persistent storage. |
+| Instant Clusters | Tag Instant Clusters to organize cluster workloads. |
+
+
+Resource tags and cost centers serve different purposes. Tags help you organize and filter resources, while [cost centers](/accounts-billing/cost-centers) track and attribute billing across your organization. You can use both together.
+
+
+## Why use resource tags
+
+Tags give you a flexible way to categorize resources so you can find and understand them later. Common uses include:
+
+- Tracking usage for a specific team, project, or initiative.
+- Separating environments, such as production versus staging.
+- Organizing resources by team or project.
+- Quickly filtering resources to find what you need.
+
+## Create a tag
+
+To create a tag, open the resource tags management area in the Runpod console, give it a name, and save it. The new tag then becomes available across your organization for anyone to apply.
+
+
+Because tags are shared across your organization, a tag you create is immediately available for anyone in your organization to apply. Consider agreeing on your tags as a team so everyone uses the same set.
+
+
+## Attach a tag to a resource
+
+You can apply a tag when you create a supported resource, or add one later from the resource's management view. Attaching an existing tag associates that resource with the tag without changing any other resources.
+
+## Filter resources by tag
+
+You can filter or search a resource list by tag to see every resource that shares that tag across your organization. This makes it easy to review all the resources associated with a given team, project, or environment in one place.
+
+## Update a tag
+
+You can update a tag to change its name (key) and any associated value. Because tags are shared across your organization, updating a tag changes it for every resource that carries it.
+
+## Detach a tag from a resource
+
+You can remove a tag from a single resource without deleting the tag itself. Detaching a tag affects only that resource; the tag remains available and stays applied to any other resources that use it.
+
+## Delete a tag
+
+
+Deleting a tag removes it entirely from your organization, including from every resource it is applied to. This affects all resources carrying the tag, not just one.
+
+
+## Best practices
+
+A few habits help keep your tags useful and consistent as your organization grows.
+
+**Establish consistent naming conventions.** Agree on a naming scheme that reflects your teams, projects, and environments before you create tags. Predictable names make tags easier to apply correctly and to filter on later.
+
+**Tag resources at creation time.** Apply the appropriate tags when you create a resource rather than after the fact. This keeps your resources organized from the start and reduces cleanup work later.
+
+**Use tags to separate environments.** Apply distinct tags to production, staging, and other environments so you can quickly distinguish them and avoid acting on the wrong resources.
+
+**Periodically review and prune unused tags.** Revisit your tags from time to time and remove any that are no longer in use. Keeping the tag list current makes it easier for everyone in your organization to find and apply the right tags.
diff --git a/accounts-billing/organizations/roles-and-permissions.mdx b/accounts-billing/organizations/roles-and-permissions.mdx
new file mode 100644
index 000000000..e88b12fd7
--- /dev/null
+++ b/accounts-billing/organizations/roles-and-permissions.mdx
@@ -0,0 +1,108 @@
+---
+title: "Roles and permissions"
+sidebarTitle: "Roles and permissions"
+description: "Understand Runpod's built-in team roles and use them to control what team members can do with Pods, Serverless endpoints, network volumes, and billing."
+tag: "Beta"
+---
+
+Runpod team accounts use built-in roles to control what each member can access and do. Assigning roles lets an admin delegate work without granting full account control. This page is for admins who manage a team account. To create or convert a team and invite members, see [Manage accounts](/accounts-billing/manage-accounts). If you received an invitation and want to join, see [Join a team](/accounts-billing/manage-accounts#join-a-team).
+
+## Why use roles
+
+Roles let you apply least privilege by granting each member the minimum role they need for their work. Use the Billing role to separate billing access from technical operations, so finance staff can manage payment methods and invoices without touching compute resources. Use the Dev role to let developers create and manage compute without exposing billing or account settings. Reserve the Admin role for trusted leads who need full control over members, settings, billing, and all compute.
+
+## Available roles
+
+### Basic role
+
+The Basic role provides essential access for users who need to work with existing resources without management capabilities. It allows users to access the team account and connect to already-deployed resources such as [Pods](/pods/overview), [Serverless endpoints](/serverless/overview), and [Instant Clusters](/instant-clusters). Users with this role cannot view billing information, start or stop Pods, or create new resources.
+
+### Billing role
+
+The Billing role focuses exclusively on financial management. Users with this role can access billing information, manage payment methods, and view invoices, but they cannot access compute resources. This makes the role ideal for finance staff who need billing access without operational permissions.
+
+### Dev role
+
+The Dev role extends the Basic permissions with additional capabilities for active development work. It includes all Basic permissions plus the ability to create, start, and stop Pods and manage [network volumes](/storage/network-volumes). Instant Cluster management (creating, deleting, starting, and stopping Instant Clusters) is reserved for the Admin role. Users with this role remain restricted from billing information and account settings.
+
+### Admin role
+
+The Admin role provides full control over the account. Administrators can manage team members, configure account settings, handle billing, and control all compute resources. Reserve this role for trusted leads who need full account access.
+
+## Permissions matrix
+
+The following matrix shows which permissions each role grants:
+
+| Permission | Basic | Billing | Dev | Admin |
+|------------|-------|---------|-----|-------|
+| Access team account | ✅ | ✅ | ✅ | ✅ |
+| Connect to existing Pods | ✅ | ❌ | ✅ | ✅ |
+| Create/delete/start/stop Pods | ❌ | ❌ | ✅ | ✅ |
+| Create/delete Serverless endpoints | ❌ | ❌ | ✅ | ✅ |
+| Send requests to Serverless endpoints | ✅ | ❌ | ✅ | ✅ |
+| Connect to existing Instant Clusters | ✅ | ❌ | ✅ | ✅ |
+| Create/delete/start/stop Instant Clusters | ❌ | ❌ | ❌ | ✅ |
+| Create/update/delete network volumes | ❌ | ❌ | ✅ | ✅ |
+| View billing information | ❌ | ✅ | ❌ | ✅ |
+| Manage payment methods | ❌ | ✅ | ❌ | ✅ |
+| Invite team members | ❌ | ❌ | ❌ | ✅ |
+| Manage team permissions | ❌ | ❌ | ❌ | ✅ |
+| Modify team account settings | ❌ | ❌ | ❌ | ✅ |
+| Access audit logs | ❌ | ❌ | ❌ | ✅ |
+
+If your assigned role does not grant access you need, contact your team's Admin to request a different role.
+
+## Assign a role to a team member
+
+You assign a role when you invite a member to your team. The role you choose at invite time determines the member's permissions.
+
+
+
+ Navigate to the [Team page](https://www.console.runpod.io/team) in the Runpod console.
+
+
+ In the **Members** section, select **Invite New Member**.
+
+
+ Choose the appropriate role for the new member. This role determines what the member can access and do.
+
+
+ Enter the email address of the person you want to invite and select **Create Invite**.
+
+
+ Copy the generated invitation link from the **Pending Invites** section and share it with the person you want to invite.
+
+
+
+
+Invitation links remain active until used or manually revoked.
+
+
+## Remove access
+
+You can revoke a pending invitation from the **Pending Invites** section before it is used. As part of general offboarding, review team membership regularly and revoke access that is no longer needed.
+
+To dissolve an entire team and revert to a personal account, see [Manage accounts](/accounts-billing/manage-accounts#convert-to-a-team-account).
+
+## Best practices
+
+Assign roles based on each member's responsibilities, and apply the principle of least privilege by granting the minimum role necessary for each person's work. Isolate billing access from technical operations by using the Billing role for finance staff.
+
+Review team membership regularly and remove access for members who no longer need it. Review audit logs periodically to ensure compliance with your organization's policies and to identify unusual activity early.
+
+## Next steps
+
+
+
+ Create or convert a team and invite members.
+
+
+ Set up billing and payment methods.
+
+
+ Review audit logs to track actions across your team.
+
+
+ Attribute team spend by project or team.
+
+
diff --git a/accounts-billing/organizations/ssh-key-management.mdx b/accounts-billing/organizations/ssh-key-management.mdx
new file mode 100644
index 000000000..e52303ee9
--- /dev/null
+++ b/accounts-billing/organizations/ssh-key-management.mdx
@@ -0,0 +1,146 @@
+---
+title: "SSH key management"
+sidebarTitle: "SSH key management"
+description: "Add your SSH public key in your Runpod account settings, and Runpod keeps it in sync across the Pods your organization deploys."
+tag: "Beta"
+---
+
+Each member of your organization adds their own SSH public key in their Runpod account settings. Runpod injects those keys into the organization's Pods and keeps them in sync. Running Pods pick up key changes and membership changes without a redeploy.
+
+Members add keys on the same account settings page whether they belong to a team or an organization. There is no separate organization keys page. Runpod combines members' keys for each Pod, which gives your team consistent access across the organization's Pods without per-Pod key setup.
+
+## How key injection works
+
+Runpod writes the public keys of everyone with access to a Pod into that Pod's `/root/.ssh/authorized_keys` file. The host machine checks the key set continuously, so a key change usually reaches running Pods in under a minute. Runpod also rewrites the file when the Pod restarts and every 15 minutes, even when no key has changed.
+
+Runpod manages the entire `authorized_keys` file. Any key you add to the file manually from inside the Pod is removed at the next sync. To give someone SSH access, add their key to their account settings or add them to the organization instead.
+
+The key set comes from account settings only. The `PUBLIC_KEY` and `RUNPOD_SSH_PUBLIC_KEY` environment variables no longer change which keys can connect over SSH via public IP. If a Pod sets either variable, Runpod replaces that key with the account keys at the next sync.
+
+Key injection applies to Pods, including the nodes of [Instant Clusters](/instant-clusters). It does not apply to Serverless workers, which use only the endpoint owner's keys.
+
+### Connection methods
+
+The two SSH connection methods apply key changes at different times.
+
+With proxied SSH through `ssh.runpod.io`, Runpod checks your key against your current account settings each time you log in. A key you add or delete takes effect at your next login.
+
+With SSH via public IP, you connect directly to the SSH daemon inside the Pod, which reads `authorized_keys`. Key changes take effect after the next sync, usually within a minute.
+
+For both methods, SSH sessions that are already open stay open after a key is deleted or a member is removed.
+
+## Who receives keys
+
+A Pod receives the keys of the same people who can see it in the console.
+
+A personal Pod receives its owner's keys. By default, an organization Pod receives the keys of the member who created the Pod, members who share a [group](/organizations/orgs-groups) with them, and organization admins. If your organization lets every member see all resources, every member's keys are injected.
+
+When a member joins the organization, their keys reach the Pods they can see at the next sync. When a member leaves, their keys are removed from those Pods at the next sync.
+
+## Roles and permissions
+
+Members with any of these roles can add and delete their own SSH keys. Runpod injects each member's keys into the organization's Pods that member can see:
+
+- Admin.
+- Dev.
+- Basic.
+
+The Billing role does not manage SSH keys through the console. However, Runpod still injects a Billing member's public key into the organization's Pods they can see. To remove someone's SSH access, remove them from the organization.
+
+For the full role matrix, see [Roles and permissions](/accounts-billing/organizations/roles-and-permissions).
+
+## Add an SSH key
+
+
+
+ If you don't already have an SSH key pair, generate one on your local machine. Runpod stores only the **public key**. Never paste your private key anywhere.
+
+
+
+ ```bash
+ ssh-keygen -t ed25519 -C "your-name@yourorg.com"
+ ```
+
+ When prompted, accept the default file location (`~/.ssh/id_ed25519`) or specify a custom path. To view your public key:
+
+ ```bash
+ cat ~/.ssh/id_ed25519.pub
+ ```
+
+
+ ```powershell
+ ssh-keygen -t ed25519 -C "your-name@yourorg.com"
+ ```
+
+ When prompted, accept the default file location. To view your public key:
+
+ ```powershell
+ Get-Content "$env:USERPROFILE\.ssh\id_ed25519.pub"
+ ```
+
+ If `ssh-keygen` is not available, install [OpenSSH for Windows](https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse) or use [PuTTYgen](https://www.puttygen.com/).
+
+
+
+ Your public key looks like:
+
+ ```text
+ ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI... your-name@yourorg.com
+ ```
+
+
+ Paste your public key into the **SSH Public Keys** field in your [Runpod account settings](https://www.console.runpod.io/user/settings). This is the same field for team and organization members. There is no organization-specific keys page. For the full procedure, including the CLI method, see [Generate an SSH key and add it to your Runpod account](/pods/configuration/use-ssh#generate-an-ssh-key-and-add-it-to-your-runpod-account).
+
+ To confirm the key was saved, run `runpodctl ssh list-keys`.
+
+ Runpod injects your new key into the Pods you can see at the next sync, usually within a minute. You don't need to redeploy running Pods.
+
+
+
+## Manage your keys
+
+You add and delete your own keys from the **SSH Public Keys** field in your [Runpod account settings](https://www.console.runpod.io/user/settings). Paste each key on its own line to add it, and delete its line to remove it. Renaming a key is not supported.
+
+When you delete a key, Runpod removes it from running Pods at the next sync. Proxied SSH stops accepting the key at your next login.
+
+## Connect to a Pod
+
+Connecting to an organization's Pod works the same as connecting to any other Pod: you connect with the private key that matches one of the public keys injected into the Pod. For the connection methods, including basic proxied SSH, full SSH over public IP, and password-based access, see [Connect to a Pod with SSH](/pods/configuration/use-ssh).
+
+## Troubleshooting
+
+**Permission denied (publickey)**
+
+Confirm that the matching public key is in your account settings. Then check that you pass the right private key to SSH with `-i`. If you added the key in the last minute, wait for the next sync and try again. If the error continues, check the key's format. For common format issues, see [Connect to a Pod with SSH](/pods/configuration/use-ssh#troubleshooting-ssh-key-authentication).
+
+**Connected to the wrong Pod**
+
+Copy the IP and port fresh from the **Connect** tab. They may change when you stop and resume the Pod.
+
+**A key added inside the Pod stopped working**
+
+Runpod manages the Pod's `authorized_keys` file and removes keys added from inside the Pod at the next sync. Add the key to your account settings instead.
+
+**SSH via public IP doesn't work on a Pod deployed without keys**
+
+If no SSH keys were available when the Pod was deployed, the Pod might not start its SSH daemon. Add your key to your account settings, then redeploy the Pod (terminate it and deploy a new one).
+
+
+Terminating a Pod permanently deletes any data that is not stored on a [network volume](/storage/network-volumes). Back up your data or attach a network volume before you terminate a Pod.
+
+
+**Member can't connect to a Pod**
+
+Confirm that the member can see the Pod in the console. A Pod receives only the keys of members who can see it (see [Who receives keys](#who-receives-keys)).
+
+## Security notes
+
+**Store only public keys.** Never paste a private key into Runpod. Your private key stays only on the machine you connect from.
+
+**Use a strong key type.** An ed25519 key (`-t ed25519`) is recommended.
+
+**Rotate keys regularly.** If a key may be compromised, delete it from your account settings and generate a new key pair. Runpod removes the deleted key from running Pods at the next sync. After a Pod restarts, the deleted key can still connect for up to about 30 seconds, until the first sync completes.
+
+**Offboarding members.** When you remove a member from the organization, Runpod removes their keys from the organization's Pods at the next sync. Proxied SSH rejects their keys at their next login. Key removal doesn't close SSH sessions that are already open. To end them, restart the affected Pods.
+
+**Know what key sync controls.** Key sync manages only the `authorized_keys` file. It doesn't undo other access that a former member set up inside a Pod. For example, they might have created another user account, changed `sshd_config`, or added a scheduled job. If a former member had SSH access to a Pod that holds sensitive data, review the Pod or redeploy it.
diff --git a/docs.json b/docs.json
index 1ffd6560b..6110180da 100644
--- a/docs.json
+++ b/docs.json
@@ -321,6 +321,15 @@
"accounts-billing/cost-centers",
"accounts-billing/referrals",
"accounts-billing/manage-payment-cards",
+ {
+ "group": "Organizations",
+ "pages": [
+ "accounts-billing/organizations/overview",
+ "accounts-billing/organizations/roles-and-permissions",
+ "accounts-billing/organizations/ssh-key-management",
+ "accounts-billing/organizations/resource-tagging"
+ ]
+ },
"accounts-billing/post-paid-billing",
"accounts-billing/sales-tax",
"accounts-billing/add-tax-id"
diff --git a/pods/configuration/connect-to-ide.mdx b/pods/configuration/connect-to-ide.mdx
index cb096667c..5a92f0225 100644
--- a/pods/configuration/connect-to-ide.mdx
+++ b/pods/configuration/connect-to-ide.mdx
@@ -47,16 +47,9 @@ Before you can connect to a Pod, you'll need an SSH key that is paired with your
3. Copy and paste the output into the **SSH Public Keys** field in your [Runpod user account settings](https://console.runpod.io/user/settings).
-
-To enable SSH access, your public key must be present in the `~/.ssh/authorized_keys` file on your Pod. If you upload your public key to the settings page before your Pod starts, the system will automatically inject it into that file at startup.
-
-If your Pod is already running when you upload the key, the system will not perform this injection. To enable SSH access, you'll need to either terminate/redeploy the Pod, or open a [web terminal](/pods/connect-to-a-pod#web-terminal-connection) on the running Pod and run the following commands:
-
-```sh
-export PUBLIC_KEY=""
-echo "$PUBLIC_KEY" >> ~/.ssh/authorized_keys
-```
-
+
+Runpod injects the keys from your account settings into your Pods' `~/.ssh/authorized_keys` file and keeps them in sync. If your Pod is already running, the new key usually reaches it within a minute. You don't need to redeploy. Don't add keys to `authorized_keys` manually from inside the Pod, because Runpod overwrites the file at the next sync.
+
## Step 3: Deploy a Pod
diff --git a/pods/configuration/use-ssh.mdx b/pods/configuration/use-ssh.mdx
index b0298ae8c..508178d37 100644
--- a/pods/configuration/use-ssh.mdx
+++ b/pods/configuration/use-ssh.mdx
@@ -20,9 +20,9 @@ SSH key authentication is recommended for security and convenience.
Before connecting, [add your SSH public key to the Credentials page](/get-started/credentials#ssh-public-keys).
-### Override your public key for a specific Pod
+### How Runpod injects your keys
-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 injects the public keys from your account settings into your Pods' `/root/.ssh/authorized_keys` file and keeps them in sync. When you add or delete a key, running Pods usually pick up the change within a minute, without a redeploy. Runpod manages the whole file and removes keys added manually from inside the Pod at the next sync. Environment variables such as `PUBLIC_KEY` don't override your account keys. For details, including how keys are shared across an organization's Pods, see [SSH key management](/accounts-billing/organizations/ssh-key-management).
## Basic SSH with key authentication