What Pipecat Cloud Can See

Exactly what data the Pipecat Cloud control plane reads from a self-hosted region, what it never reads, and how to turn each channel off.

Running a means Pipecat Cloud manages your region without holding your data. This page lists exactly what the control plane receives or can read, what it structurally cannot, and how to turn each channel off. The access described here is enforced by the region package’s own Kubernetes roles, which you can inspect with helm get manifest pipecat -n pipecat-system.

Always: session records and region health

Sent by the region as sessions run, and the basis of everything you see in the dashboard:

• Session records — session ID, agent and deployment, start and end times, outcome, and per-session CPU and memory samples. No session content.
• Deployment state — whether each deployment is ready, and failure verdicts (as category codes, not free text) when an agent cannot be deployed.
• Region health — connected region agents, the platform version and capabilities each one runs, and certificate expiry.

Turning session records off (region-agent.telemetry.enabled: false) makes sessions invisible to Pipecat Cloud — the sessions list, metrics, and billing records all stop — so it is not recommended.

By default, on request: platform diagnostics

The support bundle is a read-only snapshot Daily support can pull through the region’s connection when you ask for help. Its access is exactly two namespaced roles:

Namespace	May read
pipecat-system	Pod listings and status; recent log lines of the platform components (region agent, operator, activation service); cluster events; and the existence, type, and age of four platform Secrets (pipecat-region-ca, pipecat-region-enroll-token, pipecat-bot-starter-ws-auth, pipecat-pull)
Workloads namespace	Pod listings and status for agent pods; cluster events; autoscaler state; each deployment’s status and a fixed subset of its spec (image, resources, scaling)

It does not read agent pod logs, the contents of any Secret, environment variable values, or ConfigMap contents. Every pull is recorded on the region’s event feed.

Disable it with region-agent.supportBundle.enabled: false, which removes both the capability and the roles.

Only when you enable it: agent logs

With the log store enabled, agent log lines are stored in your region and read only when a member of your organization queries them through the CLI, dashboard, or API. Each query returns the lines that match its filters and nothing else; no log data is collected or stored by Pipecat Cloud, and Daily does not pull agent logs on its own. Log collection is off by default.

Never

Independent of any setting:

• Session audio, video, or messages. WebSocket and telephony sessions connect directly to your region; Daily WebRTC sessions connect to Daily’s media infrastructure as they do for every region. In neither case does session media pass through the Pipecat Cloud control plane.
• Secret values. Referenced secrets are checked for existence and type only, and the status response cannot carry keys or values.
• Environment variables or configuration contents of your agents or the platform components.
• Anything in namespaces other than the system and workloads namespaces. The platform’s roles are scoped to those two.

Inbound access

Nothing connects inbound to your cluster. The region agent opens an outbound, mutually authenticated connection to Pipecat Cloud, and every control-plane operation — deploying, starting sessions, querying logs, pulling a support bundle — travels over it and is limited to the operations above. Revoking the region cuts that connection off.