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> in your bucket - .mp3 for a carrier recording, .wav when Nixflex or a web call recorded it (see Call recording). 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. Read the extension from recording_url rather than assuming one.

​
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 or me-south-1). Create an IAM user with PutObject on the bucket and use its access key pair.

Cloudflare R2

Endpoint: https://<account_id>.r2.cloudflarestorage.com, region auto. In the R2 dashboard, create an API token with Object Read & Write scoped to your bucket - it gives you the access key pair and shows your endpoint.

Google Cloud Storage

Endpoint: https://storage.googleapis.com, region e.g. europe-west2. In Settings > Interoperability, create an HMAC key for a service account with write access - the HMAC key ID and secret are your key pair.

Backblaze B2

Endpoint: https://s3.<region>.backblazeb2.com (shown on your bucket page, e.g. s3.eu-central-003.backblazeb2.com). Create an application key scoped to the bucket - the keyID and applicationKey are your pair.

Wasabi

Endpoint: https://s3.<region>.wasabisys.com with the matching region (e.g. eu-west-1). Create an access key pair in 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 or air-gapped requirements.
Quick reference
Azure Blob Storage does not speak the S3 API natively - put an S3-compatible gateway (such as MinIO Gateway) in front of it, then connect the gateway here.

​
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.