Storages

The Storages section covers the API endpoints used to register and manage external storage targets in Callaba Engine. This is the layer you use when recorded files, copied media, or archived assets should live in an object storage backend rather than only on the local server.

Compared with file-oriented modules, a storage object is the place where your media should end up when local disk is not the final home. It tells the engine which bucket or storage target should receive completed assets and gives operations one durable destination to plan around.

The control methods complete that lifecycle. Use create and update to register the storage target, getAll and getCount for listings, getById when you need one storage object, and remove when the storage should be detached and cleaned up.

This module is operationally sensitive: secrets are provided on create and update, but are intentionally not returned later through listing and lookup methods. The point is to manage the destination safely, not to turn the API into a place where credentials are read back out later.

Examples by preset

The most useful presets here are storage target families rather than transport families. In practice, the common paths are an AWS S3-compatible target, a Backblaze target, and the metadata strategy that goes with them.

{
  "name": "AWS media archive",
  "type": "STORAGE_TYPE_S3",
  "bucket_url": "https://my-media-bucket.s3.us-east-1.amazonaws.com",
  "access_key": "AWS_ACCESS_KEY_ID",
  "secret_key": "AWS_SECRET_ACCESS_KEY",
  "redis_meta_data_url": "redis://localhost:6379/2",
  "meta_data": {}
}

{
  "name": "Backblaze media archive",
  "type": "STORAGE_TYPE_BACKBLAZE",
  "bucket_url": "https://s3.us-east-005.backblazeb2.com/my-media-bucket",
  "access_key": "B2_KEY_ID",
  "secret_key": "B2_APPLICATION_KEY",
  "redis_meta_data_url": "redis://localhost:6379/2",
  "meta_data": {}
}

Workflow examples

These scenarios frame why a storage object exists in production, not only how the request body is shaped.

Register a durable archive target before recording or file transfer workflows depend on it

Use a storage object when recordings, copied files, or exported assets should land in a managed external bucket rather than stay only on the local machine.

• Why it helps: one API object gives the team a reusable archive or delivery destination instead of forcing every recording or file-copy workflow to redefine it.
• Typical fit: long-term archive, shared media repository, and off-instance file retention.

Use one storage object per operational destination rather than mixing archive policies

Different buckets often serve different business goals: long-term archive, short-term exchange, or per-project delivery. Defining them as separate storage objects keeps downstream recording and transfer workflows easier to reason about.

• Typical fit: separate buckets for archive, editorial handoff, and customer delivery.

Treat secrets as write-only operational inputs

Access keys and secret keys are supplied when the storage is created or updated, but later lookup methods focus on the storage target itself rather than exposing those credentials again.