TRaX Docs
guides

Cloud recording to your bucket

TRaX records your studio's program output — the composited feed your viewers see — straight into your own S3-compatible bucket. The recording is yours from the first second: it lands under your keys, in your bucket, and TRaX never deletes it. Retention is whatever your bucket's lifecycle rules say.

Prerequisites

  1. A connected, Verified storage config with write access — see BYO storage: setup. A read-only (Forbidden) config can't record.
  2. An active subscription (recording writes to customer storage and rides the same entitlement as connecting a bucket).
  3. The studio must be producing — recording captures the live program. Arming recording while off-air records nothing.

Recording currently writes to your first Verified storage config; a per-studio storage picker is planned. Starting and stopping is owner/admin-gated; the Record button lives in the studio control bar and shows an elapsed timer while recording.

Recording is deliberately best-effort in one direction only: a slow or broken bucket can degrade the recording, but can never touch the live stream.

What gets written to your bucket

While recording, TRaX writes the program as 8-second fragmented-MP4 segments, uploaded continuously (each segment lands within seconds of being captured), plus a running manifest.json. After the recording ends, processing assembles the segments into flat MP4 file(s):

<your-prefix>/trax-recordings/<studio-id>/<start-unix>-<recording-id>/pp/
├── 2026-07-10_18-30-05-000000.mp4     ← 8s fMP4 segments, timestamp-named
├── 2026-07-10_18-30-13-000000.mp4
├── …
├── manifest.json                      ← ordered segment list + loss counter
├── final.mp4                          ← the assembled recording
└── final-2.mp4                        ← only if the stream had a discontinuity
  • <your-prefix> is the prefix on your storage config (empty = bucket root); everything stays inside it.
  • Each segment is a self-contained fragmented MP4 — individually playable, so the recording is durable and usable even before processing runs.
  • manifest.json lists every uploaded segment in order (key, size, upload time) and carries a segmentsLost counter.
  • final.mp4 is the assembled, seekable recording with the index at the front (starts playing immediately when streamed). If the recording contains a discontinuity — the stream restarted, or the video format changed mid-recording — each continuous span becomes its own part: final.mp4, final-2.mp4, final-3.mp4, …
  • Processing runs asynchronously after the recording ends and can take a while. Re-processing is safe: output names are deterministic and simply overwrite.

When you stop recording (or end the stream), the last segments drain to your bucket over the following minute or so before the session is marked complete.

segmentsLost and gaps

segmentsLost in manifest.json counts segments that were captured but could not be delivered to your bucket. TRaX buffers segments locally while uploading, but the buffer is bounded — if your bucket is unreachable or too slow for too long, the oldest unuploaded segments are dropped rather than endangering the live stream, and each drop increments segmentsLost.

A non-zero segmentsLost means your recording has gaps: processing skips the missing time, so final.mp4 is continuous but shorter than the stream. If you see it regularly, check the bucket's write throughput and the storage config's status pill for decay events.

Retention: your bucket, your rules

TRaX never deletes recording objects from your bucket — not segments, not finals, not manifests. If you want automatic cleanup, use your provider's lifecycle rules. Example (AWS S3 / S3-compatible), expiring recordings after 90 days:

{
  "Rules": [
    {
      "ID": "expire-trax-recordings",
      "Status": "Enabled",
      "Filter": { "Prefix": "trax-recordings/" },
      "Expiration": { "Days": 90 }
    }
  ]
}

If your storage config has a prefix, include it: "Prefix": "<your-prefix>/trax-recordings/". A tighter variant: expire only the segment spans you no longer need, and keep final*.mp4 by moving finals to a different prefix with your own tooling.

Current limitations (stated plainly)

  • No in-app recordings list yet. Recordings don't show up for playback or download inside TRaX yet — that surface is being built. Today you access recordings directly in your bucket with your own tools (provider console, aws s3 / mc / rclone).
  • Processing timing. final.mp4 appears after asynchronous processing, not instantly at stream end. Until it does, the segments plus manifest.json are the durable recording.
  • Gaps are not yet surfaced in-app. Check manifest.json → segmentsLost for delivery drops.
  • No direct upload into your bucket through TRaX. To place other files there: upload with your own tools and import, or upload to the TRaX library and Move it across — see importing and moving files.
  • Storage choice is implicit (first Verified config); a per-studio picker is planned.

Next