A file can arrive through upload or directly from Recorder. Its name, path, description and visibility stay together in one place, where you can preview the media, make a separate converted copy when another format is required, or pass the verified file to Restreaming or Web Player. Files use internal disk by default; connected Storage is optional.
The file's origin remains visible while you review its record and media, decide whether another format is needed and choose the next product workflow.
A local media file enters the managed file area, completes upload and processing, and is then available for preview.
Continue from UploadThe file is now part of the managed workflow. Its record and media remain available for review before format, visibility or destination changes.
This example follows the product boundary: metadata is explicit, Private is a deliberate example, and internal disk remains the default location.
A change to format or transcoding settings starts a background rewrite and produces a separate managed copy. The original is not replaced.
File Manager retains the media record while each downstream product owns its own runtime and access policy.
The completed media opens for picture, audio and duration checks.
The completed media opens for picture, audio and duration checks.
Files use encrypted internal disk by default. When the workflow needs another tier, Callaba registers object storage with metadata and mounts a POSIX-compatible namespace for managed copies.
The table separates default file behavior from optional Storage and downstream product choices. Selectable formats and settings remain authoritative in the installed Callaba interface.
| Capability | Supported behavior | How to verify |
|---|---|---|
| File origins | Uploaded files, finalized recordings and other managed processing results. | A valid result appears with the expected origin, name and managed path. |
| Default location | Encrypted internal disk is available without configuring external Storage. | A non-critical upload or short recording completes, can be previewed and remains manageable before any Storage is added. |
| Managed metadata | Name, description, path, visibility, format, processing settings, duration, size and timestamps where available. | The saved record and completed media agree on identity, duration, size and format. |
| Visibility | Public and Private are explicit file-record choices. | Visibility is reviewed before playback is connected; player authorization remains a separate control. |
| Upload | Binary upload with progress and a correlation id for the pending file record. | A valid upload reaches completion before Preview or a downstream selection is treated as ready. |
| Preview | Completed managed media can be opened for operator inspection. | The actual file provides the expected picture, audio, duration and seek behavior. |
| Output formats | Managed output families include MOV, MP4, AVI, FLV, MP3, HLS, MKV and MPEG-TS where the selected processing path supports them. | The installed format selector is authoritative, and the completed result matches its selected container and tracks. |
| Format rewrite | Changing format or transcoding settings can start a background rewrite that creates a separate managed copy. | Progress reaches completion, the original remains present and the new copy opens in the requested format. |
| Processing state | Background worker statistics can expose bitrate, FPS, media time, speed and progress. | Progress advances before completion, but the finished file is still opened separately; runtime state alone does not verify the file. |
| Web Player handoff | A verified managed file can be selected as a browser playback source. | The exact player URL starts, continues playing and enforces its own configured audience access. |
| Restreaming handoff | A managed file can be selected as a file-based Restreaming input. | The output job reads the intended file and delivers the tested media profile to its destination. |
| Optional connected Storage | Object storage and a metadata service can be registered, formatted and mounted as a managed POSIX-compatible namespace. | A small File Manager copy completes and reads back through the mounted managed path. |
| Copy progress | File Manager can copy a managed file to internal or configured external Storage and expose percentage and completion state. | Completion and destination read-back establish that the source can be considered for removal. |
| Encryption at rest | Managed files on internal disk and optional connected Storage are encrypted at rest; raw backing blocks alone do not expose playable media. | Normal and recovery access follows the managed metadata and file path rather than raw storage blocks. |
| Lifecycle API | Create/upload, count/list, get, update, remove, rewrite status, copy and copy-progress workflows are documented. | A non-critical file establishes the required lifecycle before production media is automated. |
| Deployment | Callaba cloud deployment or self-hosted Linux, with capacity determined by file sizes, concurrent processing and storage design. | The selected node and disks are load-tested with the real upload, conversion, playback and copy mix. |
A Callaba cloud deployment provides a managed starting point. Self-hosting keeps the infrastructure, network and data location under your team's control.
A Callaba node starts with encrypted internal disk; connected Storage is added only when the workflow requires another tier.
Launch Callaba in AWSThe application, encrypted media and any optional storage connections stay on infrastructure operated by your team.
Install Callaba self-hostedOnce the interface workflow is understood, documented endpoints cover upload and file creation, listing and inspection, metadata updates, converted copies, processing state, optional Storage copies and removal.
Cloud File Manager is where uploaded, recorded and processed media becomes part of a managed workflow. The file record brings its path, description, visibility, format, processing state and downstream handoffs together.
No. Internal disk is the default file location. Connected Storage is optional and is added only when the workflow needs another managed storage tier.
Yes. Changing the format or transcoding settings starts a background rewrite and produces a separate converted copy. The original stays in its own managed file record, while File Manager reports progress for the new result.
Yes. Once verified, the file can serve as a managed input for a Web Player or a file-based Restreaming workflow. Delivery and audience access still belong to the individual downstream job.
Yes. Callaba stores managed files encrypted at rest on internal disk and in optional connected Storage. Raw access to disk or backing object blocks alone does not expose a readable media file; the managed metadata and access path are required.
Callaba combines object storage with a metadata service and mounts the result as a managed filesystem namespace. Product modules can use familiar file paths while the backing bucket remains an implementation detail rather than being exposed as the product workflow.
No. Visibility belongs to the managed file record. Web Player authorization and audience access are separate downstream decisions that still need review before a viewer URL is shared.
A short upload or recording can establish the file record, visibility, preview and metadata first. From there, test the specific next step the workflow needs: a converted copy, Web Player, Restreaming or optional Storage.
