Storage
Recordings can stay in your own account.
For a lot of Romanian companies this is not a technical preference but the condition the conversation starts from: where, physically, do the recordings of calls with our customers sit.
A call's recordings, transcripts, messages and events can be written straight into a bucket of yours, on any of the 8 supported storage destinations. You configure the destination once, and the product verifies it with a real write and read before using it.
8 storage destinations.
The list is read from the application's driver enum, and a driver appears here only if its library is installed in this build. We do not list services we have no adapter for.
platform
CallAgent platform storage
The platform bucket. What is used if you configure nothing.
s3
Amazon S3
An S3 bucket in your own AWS account, with access keys.
s3_sts
Amazon S3 (STS role assumption)
S3 with no long-lived keys: you grant a role we assume temporarily. The option where you hand over no lasting credential at all.
r2
Cloudflare R2
Cloudflare R2, with no egress charges.
azure_blob
Azure Blob Storage
Azure Blob Storage, in your own subscription.
gcs
Google Cloud Storage
Google Cloud Storage. The adapter is installed but has not yet been probed against a real Google bucket.
supabase
Supabase Storage
Supabase Storage, if the rest of your stack is already there.
s3_compatible
S3-compatible (MinIO, Wasabi, Backblaze B2)
Any S3-compatible service: MinIO in your own rack, Wasabi, Backblaze B2.
What actually lands in your bucket
Not only the audio file. A call produces five kinds of artifact, and the destination can be chosen per kind — you can keep the recordings and leave the rest with us, or the other way round.
Every artifact records in the database where it ended up, so the custody of a file is a record rather than an assumption.
- The recording — two-channel audio, caller and assistant separately, plus the computed waveform
- The transcript — the text of the call, with personal data masked if you turned masking on
- The messages — the full exchange with the model, including the arguments and results of the tools it called
- The events — the call's 66 event types, with their millisecond offsets
- The debug bundle — everything needed to reconstruct a call that went wrong
A wrong destination fails at setup, not on the first call
A bucket with the wrong permissions discovered during a real call means a lost recording. So a destination is not accepted on the basis that all its fields are filled in.
A real round trip is made, and a destination whose last probe failed is skipped rather than used. Credentials are encrypted in the database.
- 1 Write a probe object with unique content and the current time.
- 2 Read it back from the same bucket.
- 3 Compare what came back with what went in.
- 4 Delete the probe object and record the result with its date.
Three things to know first
If you are choosing this product precisely because of where the data sits, the items below are exactly what you would find out for yourself later. We would rather you found out now.
The recording passes through us first
The gateway uploads the finished file to the platform bucket, and the control plane then moves it to your destination and rewrites the custody record. So there is a window, usually short, in which the recording is on our infrastructure. Transcripts, messages and events are written straight to you.
No real customer destination yet
The storage destinations table has zero rows. The code is written and tested, but nobody has pointed the product at a real company's bucket yet. "Supported" is true; "battle-tested" would not be.
Google Cloud Storage has not been probed
The adapter is installed and configurable but has not been verified against a real Google bucket. If that is your destination, tell us and we will probe it beforehand rather than afterwards.
What people ask about where the data sits
Can I keep recordings in my own account?
Yes. You configure a storage destination in the console and recordings, transcripts and events are written to your bucket, on S3, S3 with an assumed role, Cloudflare R2, Azure Blob, Google Cloud Storage, Supabase or any S3-compatible service.
Which storage services are supported?
Eight: platform storage, Amazon S3, Amazon S3 with role assumption, Cloudflare R2, Azure Blob Storage, Google Cloud Storage, Supabase Storage, and any S3-compatible service such as MinIO, Wasabi or Backblaze B2. All eight have their adapter installed in this build.
Do I have to give you my long-lived keys?
No, if you use the role-assumption option on Amazon S3: you grant a role we assume temporarily, so no lasting credential leaves you. For the other destinations, credentials are stored encrypted.
Does the file pass through you before it reaches me?
Yes, for the audio recording: the gateway uploads it to the platform bucket first, and it is then moved to your destination and the custody record is rewritten. Transcripts, messages and events are written straight to you. We say this plainly because anyone choosing the product for where the data sits would find it out anyway.
What happens to the files if we leave?
They stay where they are: in your bucket, in your account, under your control. We have no way to delete them and no need to export them to you, because they were never with us.
Notes
-
1
The drivers and the check on their availability:
app/Enums/Storage/StorageDriver.php. The connectivity probe:app/Services/Storage/StorageDestinationManager.php, thevalidate()method. -
2
Moving the recording off the platform bucket:
config/object_storage.php, keyrelocate_gateway_uploads, and theRelocateArtifactToStorageDestinationjob.
Before you point a bucket at this
No customer bucket has been pointed at a live installation yet, which makes yours the first. That is worth a conversation before you configure anything, not after.