Storages

Storages

Use Storages to define where finished media should go after it leaves local disk. This is the module for external buckets and archive targets used by recordings, copied files, and exported assets.

In production, a storage object gives your team a reusable destination with a stable id. Downstream jobs can reference that object instead of repeating bucket URLs and credentials in every workflow.

What this module solves

• Moves archive and delivery planning out of individual media jobs.
• Provides a single, reusable destination for recordings and file copy workflows.
• Supports separate storage policies for archive, exchange, and customer delivery.
• Keeps secrets out of read APIs after initial configuration.

Key operations

• create and update register or change a storage target.
• getAll and getCount support inventory and audits.
• getById returns one configured destination.
• remove detaches a target that is no longer needed.

Operational notes

• Treat access_key and secret_key as write-only inputs. They are supplied on create or update and are not returned later.
• Use one storage object per operational destination. Do not mix archive, handoff, and delivery policies into a single bucket unless that is intentional.
• Validate a new or updated destination with a low-risk workflow before routing production media to it.

Example targets

The examples below cover the two most common object storage setups used in production.

AWS S3 archive

Typical choice for long-term retention and shared media libraries.

{
  "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": {}
}

Backblaze B2 archive

Typical choice for cost-sensitive archive and off-instance retention.

{
  "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": {}
}

Production workflows

Register archive storage before recording depends on it

Create the storage object before enabling recording or export workflows for an event. That way, operators are not entering bucket details during a live production window and every job can point to a known-good destination.

Separate archive, editorial handoff, and customer delivery

Different buckets usually exist for different reasons: long-term archive, short-term editorial exchange, or final customer delivery. Model those as separate storage objects so permissions, lifecycle rules, and operational ownership stay clear.

Rotate credentials without changing downstream references

When keys or endpoint details change, update the storage object and run a small validation transfer before the next show. Read APIs will confirm the destination exists, but they will not return stored secrets for review.

Operator guidance

• Name storage objects by purpose, not just by vendor.
• Keep metadata minimal and meaningful so inventory stays easy to audit.
• Remove unused targets when projects end or retention policies change.