What is tus?
tus is an open HTTP protocol for resumable file uploads. A client creates or discovers an upload resource, sends bytes from known offsets, and continues from the confirmed offset after an interruption.
How tus works
The tus protocol represents an in-progress upload as an HTTP resource with a server-confirmed byte position. A client appends data only at that position and can query the resource after reconnecting, avoiding retransmission of accepted bytes. Its core behavior is small, while negotiated extensions add creation, checksums, expiration, concatenation, or deferred length. In an ingest workflow, tus separates reliable transfer state from later validation, transcoding, and publication.
Key facts
- 1A client sends a PATCH with
Upload-Offset, and the server accepts it only when that value matches stored state; an offset conflict prevents bytes from being silently appended in the wrong place. - 2HEAD retrieves the server’s current offset so an interrupted client can resume, while the
Tus-Resumableheader identifies the protocol version expected for compatible requests and responses. - 3Optional checksum and expiration extensions address different failure modes: one detects corrupted chunks, while the other tells clients that an unfinished upload resource may cease to exist.
When tus matters
Choose tus for large uploads or unreliable connections where restarting an entire transfer would be costly. Client and server implementations must agree on offsets and extensions or resumption can fail.
Common use cases for platform workflows
These examples cover platform workflows broadly, not specifically tus.
- Running repeatable upload, import, processing, AI, storage, and notification pipelines.
- Tracking long-running media work independently from an application request.
- Referencing centrally stored credentials by name instead of sending storage secrets with each request.
Working with platform workflows
This guidance covers platform workflows broadly, not just tus.
A client authenticates and submits files or references together with workflow instructions. The platform validates the request, schedules dependent operations, records state transitions, and exposes results through a response, polling endpoint, or notification.
Platform concepts become reliable only when their lifecycle is explicit. Authentication, idempotency, retries, timeouts, observability, quotas, and terminal states should be designed together rather than added after failures occur.
What you gain
- Reusable workflows separate application intent from processing infrastructure.
- Stable job identifiers and lifecycle events improve observability and recovery.
- Managed queues and workers let products scale without embedding every media tool.
What it costs
- Synchronous responses are simple but keep connections open while long work executes.
- Aggressive retries improve recovery from transient faults but can duplicate work or overload a dependency.
- Higher concurrency reduces queue time until resource contention or a downstream limit becomes the bottleneck.
Before production
- 1Define authentication, authorization, idempotency, retries, and terminal error behavior.
- 2Observe queue time, execution time, callbacks, and partial results with stable identifiers.
- 3Exercise malformed, duplicate, interrupted, and unauthorized requests before launch.