Document Pipecat Cloud session recordings (T-2978) - #1024
Conversation
The session detail view plays back a Daily cloud recording of the room the agent ran in. Nothing said so publicly, and nothing covered retention, so customers had no way to answer basic compliance questions about it. Adds a Session Recordings page covering: - the Daily transport requirement, and that Pipecat Cloud adds no recording defaults of its own - how to start a recording (token auto-start, transport calls, audio only) - that user audio is captured before any in-pipeline audio filter such as Krisp VIVA, because the recording is made from what participants publish - that cloud recording and AudioBufferProcessor are alternatives, not a pair - retention: recordings are kept until deleted, there is no automatic expiry - storing recordings in your own S3 bucket for lifecycle control Raised by support ticket T-2978.
|
🔍 Mintlify preview for this branch: https://daily-hush-pcc-session-recordings-docs.mintlify.site |
Drop the audio-only section and the cloud recording vs AudioBufferProcessor comparison table. Keep the page focused on where the session audio comes from, storage, and retention. Also drop the now-dangling anchor link to the removed comparison section.
There was a problem hiding this comment.
Pull request overview
Adds first-party documentation for how Pipecat Cloud’s session audio playback works by explaining that the dashboard player is backed by Daily cloud recording, including requirements, how to enable it, and how to manage storage/retention (including custom S3). Also wires the new page into existing “Logging and Observability” docs and navigation.
Changes:
- Add a new Session Recordings fundamentals page documenting behavior, enablement, and storage/retention options.
- Add a cross-link from Logging and Observability to the new recordings documentation.
- Register the new page in
docs.jsonnavigation under Pipecat Cloud → Fundamentals.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| pipecat-cloud/fundamentals/session-recordings.mdx | New page documenting Daily-backed session recordings, enablement options, and retention/storage (incl. custom S3). |
| pipecat-cloud/fundamentals/logging.mdx | Adds a section linking readers to the new Session Recordings page. |
| docs.json | Adds the new fundamentals page to site navigation. |
Comments suppressed due to low confidence (2)
pipecat-cloud/fundamentals/session-recordings.mdx:25
- This sentence implies
start_cloud_recordingalone is sufficient, but Daily also requires cloud recording to be enabled viaenable_recording(on the room or the meeting token). Calling that out explicitly will prevent configuration that silently produces no recording.
Set `start_cloud_recording` on the meeting token. Daily starts the recording as soon as that token holder joins the room:
pipecat-cloud/fundamentals/session-recordings.mdx:44
- Starting/stopping recording from the pipeline also requires cloud recording to be enabled (
enable_recordingon the room or token). Adding that prerequisite here will reduce confusion whenstart_recording()fails due to room configuration.
If you want control over when recording runs, call `start_recording()` and `stop_recording()` on the transport instead. See [DailyTransport recording](/api-reference/server/services/transport/daily#recording).
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
| @@ -0,0 +1,97 @@ | |||
| --- | |||
There was a problem hiding this comment.
Pipecat supports many types of recordings, not just Daily. I'm hesitant to include a docs section like this which is just Daily-centric as it excludes other types of recording. For example, if you're using a websocket connection to a telephony provider, this does not apply to you.
Maybe we need a generic section about recording, where one of the options is Daily recordings. We can specify what's needed there.
There was a problem hiding this comment.
Makes sense, basically I'm trying to explain in writing when/why the recording appears in Pipecat Cloud
Why
A customer asked three questions about the audio recording on the Pipecat Cloud session detail view: where in the chain the audio is captured, where it is stored and how to control its lifecycle for compliance, and what setup their agent needs. None of it was documented. The only page they could find was Logging and Observability, which does not mention recordings at all.
Answering the ticket needed a source read and a log trace. That is the gap this closes.
What this adds
A new Session Recordings page under Pipecat Cloud > Fundamentals, plus a pointer to it from the Logging and Observability page.
The core point the page leads with: the session detail view plays back a Daily cloud recording of the room the agent ran in. It is not a separate Pipecat Cloud feature, and Pipecat Cloud adds no recording defaults of its own. Once you know that, the rest follows.
It covers:
start_cloud_recordingon the meeting token, or imperativestart_recording()/stop_recording().recordings_bucketwith a full example, so lifecycle control sits with the customer's own S3 rules. This is the real answer for a compliance requirement.Notes for review
base_input.py, whereaudio_in_filteris applied to inbound frames inside the input transport, and against the media server, which builds the recording from participant streams.recordings_bucketfield names checked againstRecordingsBucketConfigand Daily's REST reference.Raised by support ticket T-2978.