pipecat cloud regions

pipecat cloud regions lists the regions available for deploying agents and manages the lifecycle of self-hosted regions.

The regions command shows which regions are available for deploying agents and storing secrets, and — for organizations with self-hosted regions — registers and manages regions you host yourself.

list

List all regions available to your organization, with their codes, display names, and supported CPU architectures.

Usage:

pipecat cloud regions list

Use the region codes shown here with the --region flag in other commands. The Architectures and Default columns show what each region can run: deploys may declare one of the supported architectures with --architecture, and use the default when they do not.

Example output:

Code          Name                      Architectures   Default
us-west       US West (Oregon)          arm64           arm64
us-east       US East (Virginia)        arm64           arm64
eu-central    Europe (Frankfurt)        arm64           arm64
ap-south      Asia Pacific (Mumbai)     arm64           arm64
acme-us-east  Acme US East              amd64, arm64    amd64

register

Register a new self-hosted region, or update an existing one. Registration is an upsert: options you leave out keep their stored values, so the same command updates a single field later.

Usage:

pipecat cloud regions register [REGION_KEY] [OPTIONS]

Arguments:

region_key · string · required

The region’s key, e.g. acme-us-east. Region keys are unique across all of Pipecat Cloud and must be DNS-safe. Use the same key for the life of the region, including across cluster rebuilds.

Options:

--display-name · string

Human-readable name shown in region pickers. Without one, pickers show the uppercased key. When run interactively without this option, the command asks for a name (press Enter to skip).

--workloads-namespace · string

The namespace in your cluster where agents run. Must match the global.workloadsNamespace value of the region package install (default pipecat-agents).

--architectures · string

Comma-separated CPU architectures the cluster can schedule, e.g. amd64,arm64. Only declare what your nodes can actually run; deploys are validated against this list.

--default-architecture · string

The architecture a deploy gets when it does not declare one. Must be one of --architectures.

--ws-public-endpoint · string

Public wss:// endpoint for WebSocket and telephony transports, as described in WebSockets in Self-Hosted Regions. Omit for regions without a WebSocket front door; add or change it later by re-running register with just this option.

--organization / -o · string

Organization to register the region in. If not provided, uses the current organization from your configuration.

Examples:

# Register a new region
pipecat cloud regions register acme-us-east \
  --display-name "Acme US East" \
  --workloads-namespace pipecat-agents \
  --architectures amd64,arm64 \
  --default-architecture amd64

# Later: add a WebSocket endpoint, leaving everything else unchanged
pipecat cloud regions register acme-us-east --ws-public-endpoint wss://ws.acme-us-east.example.com

show

Show a self-hosted region’s full record: display name, enrollment status, certificate expiry, architectures, workloads namespace, and WebSocket endpoint.

Usage:

pipecat cloud regions show [REGION_KEY] [OPTIONS]

Arguments:

region_key · string · required

The region’s key.

Options:

--organization / -o · string

Organization the region belongs to. If not provided, uses the current organization from your configuration.

enroll-token

Mint a one-time enrollment token for a self-hosted region and print the kubectl command that stages it in your cluster. The token is single-use, expires after one hour, and is shown exactly once. See Set Up a Self-Hosted Region.

Usage:

pipecat cloud regions enroll-token [REGION_KEY] [OPTIONS]

Arguments:

region_key · string · required

The region’s key.

Options:

--organization / -o · string

Organization the region belongs to. If not provided, uses the current organization from your configuration.

With --output json, the token and the staging command are emitted on stdout as token and kubectlCommand, so a script can stage the token without parsing human-readable output.

delete

Delete (revoke) a self-hosted region. The region’s connection to Pipecat Cloud is cut off and it disappears from region pickers. The request is refused while the region still has deployed agents or active sessions — delete or move the agents first. See Retiring a region.

Usage:

pipecat cloud regions delete [REGION_KEY] [OPTIONS]

Arguments:

region_key · string · required

The region’s key.

Options:

--yes / -y · boolean · default: "false"

Skip the confirmation prompt. This does not bypass the guard on deployed agents or active sessions.

--organization / -o · string

Organization the region belongs to. If not provided, uses the current organization from your configuration.

Without --yes the command asks for confirmation; when stdin is not a terminal, it exits with code 2 instead of prompting.

Using regions

Use region codes with other commands:

Deploy an agent to a specific region:

pipecat cloud deploy my-agent my-image:latest --region eu-central

Create secrets in a specific region:

pipecat cloud secrets set my-secrets API_KEY=abc123 --region eu-central

List agents in a specific region:

pipecat cloud agent list --region us-east

Secrets and image pull secrets must be in the same region as the agents that use them. When deploying multi-region applications, create separate secret sets for each region. In self-hosted regions, secrets are referenced rather than created.

Choose a region close to your users for optimal latency and performance.