Organizations & Service Accounts

Organizations let multiple people share billing context, ownership, and automation credentials while using the same public GPU CLI workflow.

Organization features depend on account enablement. If gpu org create is rejected for your account, contact support.

Concepts

• Organization — A named account container with members, roles, billing ownership, and audit history.
• Active org context — The CLI targets one org at a time. Switch context with gpu org switch <SLUG>. Clear the slug to go back to your personal context.
• Sub-account — A child organization created with --parent. This is useful when one parent account manages multiple teams or clients.
• Service account — A non-human identity for CI/CD and other headless workflows.

Roles

• OWNER — Full control over the org, including ownership transfer.
• ADMIN — Can manage members and service accounts.
• MEMBER — Can run workloads inside the org context.

Getting Started

Create an organization

gpu org create "My Team"

This generates a slug, such as my-team, for future commands.

Switch to the org context

gpu org switch my-team

Once active, normal commands such as gpu run, gpu llm run, and gpu serverless run in that org context.

Invite members

gpu org invite [email protected] --role admin
gpu org invite [email protected]

Transfer ownership

gpu org transfer my-team --to [email protected]

The recipient must already be a member.

Sub-Accounts

Sub-accounts are child organizations created under a parent org.

gpu org create "Client Project" --parent my-team

Use sub-accounts when one parent account needs separate org boundaries for multiple teams, projects, or clients.

Service Accounts for CI/CD

Service accounts let automation run GPU CLI non-interactively.

Create a token

gpu org service-account create --name "github-actions"

The CLI prints a token with the prefix gpt_sat_*. It is shown once, so store it in your secret manager immediately.

Use it in automation

export GPU_SERVICE_TOKEN=gpt_sat_xxxxxxxxxxxx
export GPU_RUNPOD_API_KEY=rpa_xxxxxxxxxxxx
export GPU_SSH_PRIVATE_KEY=...
export GPU_SSH_PUBLIC_KEY=...
export USER=railway-image-generator

gpu run python train.py

When GPU_SERVICE_TOKEN is set, the CLI authenticates as the service account instead of opening a browser.

Why USER matters

In CI, containers, and other headless environments, USER is often unset. GPU CLI uses it for project identity and workspace naming in automation flows.

Use a stable non-human value:

• service account name
• service name
• infrastructure workload name

Example:

export USER=railway-image-generator

Manage Service Accounts

gpu org service-account list
gpu org service-account revoke sa_abc123

Security Notes

• Tokens are shown once at creation.
• Revoked tokens stop working immediately.
• Each service account has its own identity in audit logs.
• Use separate service accounts per pipeline so you can revoke access cleanly.

Example: GitHub Actions

name: Train on GPU
on:
  push:
    branches: [main]

jobs:
  train:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Install GPU CLI
        run: curl -fsSL https://gpu-cli.sh/install.sh | sh

      - name: Run training
        env:
          GPU_SERVICE_TOKEN: ${{ secrets.GPU_SERVICE_TOKEN }}
          GPU_RUNPOD_API_KEY: ${{ secrets.GPU_RUNPOD_API_KEY }}
          GPU_SSH_PRIVATE_KEY: ${{ secrets.GPU_SSH_PRIVATE_KEY }}
          GPU_SSH_PUBLIC_KEY: ${{ secrets.GPU_SSH_PUBLIC_KEY }}
          USER: railway-image-generator
        run: gpu run python train.py