> ## Documentation Index
> Fetch the complete documentation index at: https://daily-ms-pcc-self-hosted.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Agent Sizing and Architecture

> Size agents in self-hosted regions with explicit CPU and memory or organization agent profiles, and target amd64 or arm64 nodes per deployment.

export const hostedName = "Daily-hosted regions";

export const productNameSingular = "self-hosted region";

export const productName = "self-hosted regions";

{hostedName} size agents with a fixed set of [agent profiles](/pipecat-cloud/fundamentals/deploy#agent-profiles). In {productName} you own the hardware, so you can size each deployment explicitly, define your own profiles, and choose the CPU architecture agents run on.

## Explicit resources

State the CPU and memory an agent gets directly on the deploy:

```bash theme={null}
pipecat cloud deploy --region acme-us-east --resources cpu=1,memory=2Gi
```

or in `pcc-deploy.toml`:

```toml theme={null}
region = "acme-us-east"

[resources]
cpu = "1"
memory = "2Gi"
```

Quantities use Kubernetes notation: CPU as whole cores or millicores (`2`, `500m`), memory with a binary suffix (`1Gi`, `512Mi`). Explicit resources and an agent profile are mutually exclusive — a deploy specifies one or the other, and passing one on the command line clears the other from `pcc-deploy.toml`. Explicit resources are accepted only for agents in {productName}.

<Note>
  Explicit resources are not yet available for agents deployed from a linked Git
  repository; use a profile for those.
</Note>

Sizing is captured when a deployment is created and stays with it: running agents keep the resources they started with, and a change applies on the next deploy. `pipecat cloud agent status` shows the resolved CPU and memory of the current deployment.

## Organization agent profiles

If you deploy many agents with the same shape, define a named profile once and select it by name, exactly like the platform profiles:

```bash theme={null}
pipecat cloud agent profiles create voice-large --cpu 2 --memory 4Gi --display-name "Voice (large)"
pipecat cloud deploy --region acme-us-east --profile voice-large
```

| Command                                             | What it does                                                                                |
| --------------------------------------------------- | ------------------------------------------------------------------------------------------- |
| `agent profiles list`                               | The platform catalog plus your organization's profiles, with CPU, memory, source, and state |
| `agent profiles create <name> --cpu … --memory …`   | Define a profile; `--display-name` sets the label shown in pickers                          |
| `agent profiles update <name> [--cpu … --memory …]` | Change sizing (both together) or the display name                                           |
| `agent profiles disable <name>` / `enable <name>`   | Retire a profile from new deploys, reversibly                                               |

In the dashboard, profiles are managed under **Settings → Agent profiles**, and the agent form offers your profiles next to the platform ones for agents in a {productNameSingular}.

A profile is a template applied at deploy time, not a live setting: editing a profile changes nothing that is running, and any later deploy of a service using it — even an image-only change — picks up the new sizing. Disabling a profile stops new deploys from selecting it; existing deployments are unaffected. Profiles cannot be deleted while deployments reference them, which is why disabling is the retirement path.

Organization profiles can be used only in {productName}. The platform profiles (`agent-1x` and so on) still work there and resolve to their CPU and memory, but carry no billing meaning in a region you host.

## Architecture

Agents run on `amd64` or `arm64` nodes according to the architecture their deployment declares. Two things determine what is valid:

1. **What the region supports.** You declare it at registration (`pipecat cloud regions register … --architectures amd64,arm64 --default-architecture amd64`) and can change it any time with the same command. Only declare architectures your cluster can actually schedule. `pipecat cloud regions list` shows every region's supported and default architectures.
2. **What the deployment declares.** Set it when your image is built for one architecture, so the agent schedules on matching nodes instead of failing at startup:

   ```bash theme={null}
   pipecat cloud deploy --region acme-us-east --architecture arm64
   ```

   or `architecture = "arm64"` in `pcc-deploy.toml`. Omitted, the region's default applies.

The CLI validates the choice against the region before anything is uploaded; the API rejects a deploy whose architecture the region does not support. `pipecat cloud agent status` shows the deployment's architecture, and the dashboard agent form offers a selector when the region supports more than one.

<Tip>
  If your cluster has both architectures, prefer building multi-architecture
  images and leaving the deployment on the region default — you can then move
  workloads between node pools by changing the region's default rather than
  every service.
</Tip>

## Scaling limits

The per-organization replica limit that applies to {hostedName} does not apply to a {productNameSingular}: `max_agents` is bounded only by your cluster's capacity. Plan agent-pool capacity from expected concurrency times the resources you assign per agent, and keep the autoscaler's spare capacity in mind — by default a service keeps roughly two pods per active or pending session so that the next session finds a warm agent. See [Configuration](/enterprise/configuration#agent-pod-settings) for the spare-capacity policy.