Cloudflare Stream handles most video hosting and live broadcast needs without you touching the pipeline. But the moment you want burned-in subtitles on a hosted video, live overlays on a stream, or a composite view of multiple camera feeds, you’re out of managed-territory and into custom media processing — which means a long-running process, not a request/response handler.
On October 2, 2026, Cloudflare released Streamline, a developer playground that demonstrates one workable architecture for this on their platform. Even if you never deploy it, the decomposition is worth studying.
The core problem: video outlives requests
A media process can run for minutes or hours. That breaks the usual serverless mental model, where your handler’s lifetime is the request. Streamline’s answer is a three-part split:
- Containers do the heavy lifting. FFmpeg runs inside a long-lived Container with predictable CPU and memory — the right home for real-time media processing.
- Durable Objects handle orchestration: session state, Container lifecycle, and a preview relay.
- Workers are the control plane — signaling, identity, and the API surface for users or agents.
The key property: once a pipeline starts, the Container keeps processing even if the controlling Worker disconnects. The application can resume later, and a maximum-duration cap guarantees sessions eventually close instead of running forever.
A lifecycle detail worth stealing
Containers normally sleep after a period without incoming requests. For a media pipeline, that’s exactly wrong — an encoding job may legitimately go quiet while it works. Streamline handles this by overriding the onActivityExpired() callback: if the session’s expiry hasn’t been reached, the container renews its own activity; otherwise it destroys itself. If you’re running anything long-lived on Containers, you’ll likely need the same pattern.
The API surface is deliberately small
Two npm packages make up the developer interface: a session-based client (@cloudflare/streamline/client) and a Durable Object base class that routes requests, hosts the preview relay, and exposes security hooks. From the client, you create a session, session.start(config) with a JSON pipeline definition, optionally session.ingest() chunks from a webcam or camera feed, push updated PNG overlays via session.annotation(), and session.stop() when done.
The pipeline config is just inputs, operations, and outputs. Supported operations today are filter (blur, saturation), overlay, subtitle burn-in, and encode — applied in a fixed engine-defined order, so the array order you pass is ignored. Inputs can be RTMPS pull from a Stream Live input, HLS from a hosted Stream video, or direct ingestion from your app. Outputs go back to a Stream Live input over RTMPS, or to a WebSocket preview that relays fMP4 fragments through the Durable Object.
Two honest limitations from the write-up: FFmpeg is an implementation detail behind the interface (good for portability, but you can’t tune it directly), and the operation set is currently narrow — anything beyond those four operations is out of scope. Cloudflare also notes that animated overlay updates can be throttled in practice by PNG size, bandwidth, and processing power.
Why this matters beyond video
The pattern generalizes: put the stateful, long-running thing in a Container; keep the durable session brain in a Durable Object; make the Worker a thin, stateless control layer that any client — browser, agent, embedded device — can drive. Cloudflare explicitly designed the client API to be agnostic about whether a human or an agent is driving, and the factory-camera-to-AI-analysis use case they describe is an agent consuming the same session API a browser does.
That client-agnostic control plane is a recurring theme in the Cloudflare ecosystem; we’ve looked at a similar split of responsibilities in cheap-first routing where your app owns the policy and the gateway owns the plumbing. Streamline applies the same instinct: the session API is stable, the media engine underneath is swappable.
The practical next step if this fits a project: clone the playground, run it locally with Docker (no Durable Object needed in dev mode), and prototype your pipeline before deciding whether the four supported operations cover your real requirements.