Realtime SFU forwards media tracks and DataChannels between endpoints. Your application supplies the signaling, state, and permissions around those connections.
An endpoint can be a browser, embedded device, native process, or server with a WebRTC implementation. Endpoints publish media, subscribe to media, or do both.
Media and DataChannels flow over WebRTC between the endpoint and SFU. Signaling exchanges setup information through your backend, including SDP offers and answers.
Your backend coordinates which publications an endpoint can send or receive. The SFU carries the selected media:
The connection patterns guide gives complete media and DataChannel setup sequences. The backend can use HTTPS, WebSockets, or another application protocol to communicate with endpoints. Its SFU API calls use HTTPS. Workers is one backend option; containers and conventional servers use the same interfaces.
A WebSocket media adapter connects an external service that exchanges media over WebSockets instead of implementing WebRTC.
With Realtime SFU, your application does not deploy SFU servers or select an SFU region. It creates connections through the HTTPS API and identifies remote publications by their publisher session ID and track name.
Cloudflare operates the SFU infrastructure. Your application still supplies its signaling backend, identity, discovery, and permissions. A room, broadcast, or device group is application state; the Connection API exposes sessions and publications that you compose into that topology.
Each layer owns a different part of the application:
| Layer | Responsibilities |
|---|---|
| Endpoint | Capture or generate media, own PeerConnections, apply session descriptions, and present connection state |
| Application backend | Authenticate users and devices, authorize operations, hold SFU credentials, and call the SFU API |
| Application state | Track membership, published media, subscriptions, operator roles, and resource cleanup |
| Realtime SFU | Establish WebRTC sessions and forward the media tracks and DataChannels selected by your application |
Rooms, participants, robot names, and controller roles are application concepts. For example, a Durable Object can hold one room's membership or one device's controller lease. Another backend can store the same state using its own services.
The publish and subscribe operations support several application shapes:
| Application | Publication and subscription pattern |
|---|---|
| Video room | Participants publish their media and subscribe to other participants |
| Broadcast | One publisher sends tracks that multiple viewers subscribe to |
| Device monitoring | A device publishes media and telemetry; an authorized operator can reply with controls |
| Cloud gaming | A native process publishes audio/video; viewers receive media and one viewer sends input |
| AI audio | A WebSocket adapter moves media between WebRTC endpoints and an audio-processing service |
An endpoint may use one bidirectional session or separate publishing and receiving sessions. Each session has one PeerConnection and one negotiation state machine. Refer to negotiation before sharing a session across concurrent operations.
Create an SFU application through the dashboard or API. Keep its App Secret on trusted backend infrastructure. In Workers, store the app values as Worker secrets.
An endpoint authenticates to your backend using your application's identity mechanism. The backend checks which resources it can access before making an SFU request. A room name, session ID, or track name does not establish permission.
After publication, your application distributes the publisher's session ID and track name to authorized subscribers. The SFU does not supply a room-presence protocol. Refer to sessions and tracks for identifier ownership.
The video room uses a Worker and one Durable Object per room for membership and track discovery. Pocket Radio applies the same separation to a device, browser listeners, and an exclusive controller.
Explore the SFU network visualization ↗ for an illustration of endpoint connections and media routing.