Build custom audio, video, and low-latency data applications with Cloudflare Realtime SFU and TURN.
The Realtime SFU documentation explains the product and API primitives. Use this repository to run an application, understand how its media and data move through Realtime, and adapt the same architecture to your product.
Start with video-to-jpeg/. After deployment, a browser
publishes camera video through Realtime SFU. A WebSocket media adapter converts
the video to JPEG frames for processing and viewing in a Worker.
This example keeps the Realtime SFU credential on the server. Its publisher and administrative operations still need application authorization.
Start with ai-tts-stt/. After deployment, one browser publishes
microphone audio for speech recognition, while generated speech is broadcast to
connected listeners.
This example keeps Realtime SFU and Workers AI credentials on the server. Its public control and cleanup operations still need application authorization.
| Goal | Start with | What it demonstrates | Status |
|---|---|---|---|
| Process WebRTC video | video-to-jpeg/ | Browser video, a Worker, a Durable Object, and a WebSocket media adapter | Experimental |
| Build speech applications | ai-tts-stt/ | Speech recognition, generated audio, Workers AI, and bidirectional adapters | Experimental |
| Broadcast generated speech | tts-ws/ | An external text-to-speech provider and Realtime SFU fanout | Experimental |
| Learn media publishing | echo/ | Low-level audio and video track operations | Legacy |
| Learn DataChannels | echo-datachannels/ | DataChannel transport, publishing, and subscription | Legacy |
| Learn simulcast | echo-simulcast/ | Multiple video layers and subscriber layer selection | Legacy |
| Connect a WebRTC model | openai-webrtc-relay/ | Browser and model PeerConnections joined through Realtime SFU | Legacy |
| Combine Realtime SFU and TURN | sfu-turn-go/ | Pion, TURN relay transport, and Realtime SFU DataChannels | Legacy |
| Test TURN relay transport | turn-go/ | Two Pion PeerConnections using Cloudflare TURN | Legacy |
| Ingest and play a broadcast | whip-whep-server/ | WHIP ingest, WHEP playback, a Worker, and a Durable Object | Legacy |
The machine-readable catalog records difficulty, components, credential location, demo and architecture links, measured setup time when available, and known limitations.
Blueprints are complete application starting points. Each blueprint includes a deployable application, an architecture diagram, browser and server code, security boundaries, reconnect and cleanup behavior, troubleshooting, and reproducible checks.
We are currently building the first application blueprints. In the meantime, start with the examples above.
Use a blueprint to:
- Deploy the documented application.
- Observe the intended media or data flow.
- Inspect the Realtime SFU operations and application state.
- Adapt the implementation while preserving its documented boundaries.
All blueprints live under blueprints/. Existing example
directories remain available. When a blueprint replaces an older example, the
old directory points developers to the current implementation.
Never place a Realtime SFU bearer token in browser source, generated browser assets, public variables, URLs, or logs.
The application backend stores provider credentials and makes Realtime SFU API requests. It also decides who can publish, subscribe, control resources, or perform destructive operations. Session names, track IDs, and URLs identify resources; they do not authorize access.
Some examples intentionally allow anonymous viewing or demo control. Each README identifies these limitations and the boundary an application must add.
- Maintained: Actively owned, current with the documented API, and covered by its declared checks.
- Experimental: A working application under active development. Review its known limitations before adapting it.
- Legacy: A focused or historical example retained for learning and existing links. Follow its safety warning before running it.
Status describes the repository implementation. It does not certify that an application fits every production environment.
Keep the human-facing README and catalog.yaml consistent. Add complete
application blueprints under blueprints/, preserve existing example
directories, and keep known limitations next to the implementation.
Run the repository checks before submitting a change:
npm ci
npm run checkThe checks validate catalog and blueprint metadata, local documentation links, likely credentials in source, and browser assets declared by active blueprints.