Skip to main content
Before registering a , make sure your cluster, network, and workstation meet the requirements below.

​
Kubernetes cluster

  • A conforming Kubernetes cluster, version 1.29 or later. Any distribution works — managed (EKS, GKE, AKS, OKE) or self-managed. The reference architectures for AWS EKS and Oracle OKE are proven layouts.
  • cgroup v2 on the nodes that run agents. Per-session CPU and memory metrics are sampled from the node’s cgroup filesystem, which must be the unified (v2) hierarchy — the default on recent distributions (Amazon Linux 2023, Ubuntu 22.04+, RHEL 9+). On cgroup v1 nodes, sessions run normally but resource metrics are unavailable and the dashboard says so; see Session metrics.
  • Nodes for the architectures you intend to run. Agents are scheduled on amd64 or arm64 nodes according to the architecture each deployment declares. Provide nodes for one or both, and declare what the region supports when you register it.
  • A namespace for agents that permits privileged pods. The package creates a workloads namespace (pipecat-agents by default) labeled pod-security.kubernetes.io/enforce: privileged, because agent pods currently mount a host path to read cgroup metrics. If you create the namespace yourself (for example, from a GitOps pipeline), apply that label; the install refuses to proceed without a usable namespace.

​
Platform prerequisites

Two cluster-scoped components must be installed before the region package, because the package’s own resources depend on their APIs being present:
  • cert-manager (tested with v1.18) — issues and renews the region’s certificates.
  • trust-manager (tested with v0.24) — distributes the Pipecat Cloud trust anchor into the region.
Install both with their CRDs (crds.enabled=true for cert-manager) and wait for them to be ready before installing the region package. The package checks for their CRDs at install time and fails with a clear message if either is missing.

​
Network

A needs outbound access only. Nothing connects inbound to your cluster unless you choose to expose a WebSocket endpoint. Egress through NAT is fine; no static IP addresses are required. Agent pods also need to reach the broker and, if enabled, the log store you configure.

​
Sizing the platform components

The platform components run in a system namespace (pipecat-system by default) with these defaults: Plan roughly 6 vCPU and 8 GiB for the platform at default replica counts, on nodes with at least 4 allocatable vCPU. Several components request a full vCPU each, so nodes with 2 vCPU fit at most one of them and a helm install --wait will time out with pods left pending. Capacity for the agents themselves comes on top of this. Size it from your expected concurrency and the resources you assign per agent — a voice agent typically needs 0.5 vCPU and 1 GiB. A dedicated, autoscaled node pool for agent pods, as in the EKS reference architecture, keeps platform and agent capacity independent.

​
Supporting services

The package bundles a single-replica broker and, optionally, a single-node log store. Both are intended for evaluation only. A production region provides:
  • A Valkey- or Redis-compatible broker with TLS and password authentication, reachable from the cluster. The platform uses it for session activation and autoscaling signals.
  • An OpenSearch cluster for agent logs — only if you enable the log store.

​
Your workstation

  • The Pipecat CLI with the pipecatcloud plugin, version or later, logged in to an organization that has self-hosted regions enabled.
  • helm 3.8 or later (for OCI registry support) and kubectl, configured for the target cluster.