Skip to main content
By default, Nixflex stores call recordings in EU (Ireland) storage. With your own storage, recordings go straight to a bucket you own instead - any S3-compatible provider, in any region you choose - and Nixflex keeps no copy. This is built for data residency. If your customers’ rules require call audio to stay in a particular country - the Gulf, Switzerland, Australia, anywhere - point Nixflex at a bucket in that region and the audio never lives anywhere else.
The connection is tested before it is saved: Nixflex writes and deletes a tiny probe object in your bucket when you save the settings, so a saved configuration is a working configuration. Every recording upload is then verified - Nixflex reads the object back and checks its size before treating the recording as stored.

​
How it works

1

You connect a bucket

In Settings → Recording storage, or via the API below. You provide the bucket name, an endpoint URL, and credentials that allow writing objects.
2

Recordings go to your bucket

After each call, the audio is uploaded to recordings/<call_id>.mp3 in your bucket (.wav for web calls). Nixflex stores only the object path, never the audio.
3

The call record points at your bucket

recording_url becomes a path like byo:your-bucket/recordings/<call_id>.mp3. The dashboard shows where the file lives instead of a player - the audio is in your custody, so Nixflex has nothing to stream.

​
If your bucket rejects an upload

A recording is never lost to a storage problem. If your bucket cannot take the file - deleted bucket, rotated credentials, an outage - the recording falls back to Nixflex’s standard EU storage for that call, and the call’s Events tab records a STORAGE_FAILED event with the reason, so you can fix the bucket and know exactly which calls were affected.

​
Supported providers

Any storage that speaks the S3 API works. That includes:

Amazon S3

Leave the endpoint empty and set your bucket’s region (for example eu-west-2). Use an IAM key pair with PutObject on the bucket.

Cloudflare R2

Endpoint: https://<account_id>.r2.cloudflarestorage.com, region auto. Create an R2 API token with Object Read & Write scoped to the bucket.

Wasabi

Endpoint: https://s3.<region>.wasabisys.com with the matching region. Use an access key pair from the Wasabi console.

MinIO / self-hosted

Your own https:// endpoint. Any S3-compatible self-hosted store works the same way - useful for fully on-premise requirements.
Google Cloud Storage also works through its S3 interoperability mode with HMAC keys. Azure Blob Storage does not speak the S3 API natively and needs an S3-compatible gateway in front of it.

​
Setting it up via the API

Storage is configured per API key - every call under the key uses it, across all your numbers and carriers.
The request returns verified: true only after the probe write succeeds. Broken credentials are rejected, never saved. Read the current configuration (the secret is never included):
Switch it off and clear the configuration:
After disconnecting, recordings return to Nixflex’s standard EU storage from the next call onwards. Files already in your bucket stay exactly where they are - they are yours.

​
What changes for you

  • recording_url on the call record and in the call.completed webhook carries the byo: path instead of a playable URL. If your code downloads recordings from that field, read the file from your own bucket instead.
  • The dashboard shows “Stored in your bucket” with the object path in place of the audio player.
  • Deleting calls (GDPR deletion) removes the call record from Nixflex. Files in your bucket are in your custody - Nixflex never deletes from your storage, so apply your own retention rules there.
  • Retention limits do not apply to your bucket. Nixflex’s 90-day cleanup covers Nixflex storage; your files are yours for as long as you keep them.
Where the file lives does not change the recording rules - announcement and consent requirements still apply. See Call recording.