MoQ gets a control plane: isolated relays with per-role credentials
Cloudflare has opened its Media over QUIC (MoQ) network to application developers with a provisioning API that creates isolated relay scopes and issues separate credentials for publishers and subscribers. The relays are available across Cloudflare's global network within seconds — no servers to deploy, size, or load balance. The service remains free during beta.
The new API and dashboard controls come alongside support for draft-14 and draft-16 of the IETF MoQ Transport protocol, both with authentication support.
How MoQ relays work
MoQ is an IETF-standardized publish/subscribe protocol running on QUIC, the same transport underlying HTTP/3. Publishers send named streams of data; subscribers request those streams by name. Relays — CDN servers in this case — copy each stream to every interested party without inspecting the payload, so a single publisher can reach a large audience without handling fan-out itself.
Because relays are payload-agnostic, one protocol can carry live video, video calls, or low-latency messaging. The practical upshot: developers publish to a CDN through a single API and get low latency and large scale without running a fleet of specialized servers.
Cloudflare's implementation treats a relay not as a dedicated VM or process, but as an isolated scope across its existing anycast network. That scope separates one application's namespaces, tracks, and objects from another's, and defines who can enter and whether they may publish or subscribe. Provisioning a relay is closer to adding a virtual host than starting a new server — the infrastructure is already running, so the API only adds configuration and credentials. No region selection, capacity estimation, or load balancing is required.
p>Last year's open preview exposed a global MoQ endpoint with no authentication. More than 1,000 unique clients still connect daily for protocol testing, but an unauthenticated relay cannot support production workloads requiring confidentiality, access control, or a clear publisher/subscriber role split. The new API closes that gap.
The provisioning API
The API is a control plane: it manages relays and tokens but never touches media traffic. Two resource types exist:
- A relay — the isolated scope described above, keeping one application's streams separate from another's.
- A token — a credential granting publish, subscribe, or both operations on a single relay. Distinct tokens for publishers and subscribers prevent a viewer from hijacking a broadcaster's tracks.
Each token is individually revocable and can carry an expiration date, so access can be revoked without disrupting other clients. Tokens currently apply to an entire relay; finer-grained permissions are under discussion in the IETF and MoQ community.
Creating a relay
Provisioning a relay requires a single API call with just a name:
curl -X POST \
"https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/moq/relays" \
-H "Authorization: Bearer $API_TOKEN" \
-H "Content-Type: application/json" \
-d '{"name": "Production Relay"}'
The response includes a relay ID plus two default tokens — one with publish and subscribe permissions, and one that is subscribe-only. Narrower access is possible by adding tokens explicitly, such as a viewer token expiring at the start of 2027:
{
"result": {
"uid": "a1b2c3d4e5f67890a1b2c3d4e5f67890",
"name": "Production Relay",
"issuers": [
{
"type": "cloudflare_jwt",
"issuer": "cloudflare",
"cloudflare_tokens": [
{
"operations": ["publish", "subscribe"],
"expires": "2027-03-27T15:00:00Z",
"secret": "eyJ..."
},
{
"operations": ["subscribe"],
"expires": "2027-03-27T15:00:00Z",
"secret": "eyJ..."
}
]
}
]
}
}
Relays can also be created from the Cloudflare dashboard under Media > Realtime > MoQ Relay, then Create relay.

Connecting clients
Broadcasters receive the publish-and-subscribe token; viewers get the subscribe-only token. Each client presents its token when opening a MoQ session, and the relay enforces its permissions. The token travels in the URL path — for example, with the open-source moq-rs tools, a broadcaster can use ffmpeg to publish a fragmented MP4 stream:
ffmpeg -stream_loop -1 -re -i input.mp4 -f mp4 -movflags empty_moov+frag_every_frame+separate_moof+omit_tfhd_offset - \
| moq-pub -- --name my-namespace "https://draft-16.cloudflare.mediaoverquic.com/<publish_subscribe_token>"
A viewer connects with moq-sub:
moq-sub --name my-namespace "https://draft-16.cloudflare.mediaoverquic.com/<subscribe_token>" | ffplay -hide_banner -an -
The relay reads the token at session open and checks whether the requested operation is permitted.
What draft-16 adds
The MoQ transport spec is evolving quickly, and Cloudflare relays now support draft-16. Two features are relevant to publishing and subscribing:
PUBLISHlets a publisher send a track to a relay before any viewer requests it. Without it, the first subscription must propagate through the relay chain to the publisher before data flows. With it, the relay can already receive the track when the first viewer connects.SUBSCRIBE_NAMESPACElets a subscriber request every track announced under a namespace, including tracks added later — such as a new video rendition or audio track introduced mid-stream.
An open provisioning model
MoQ itself is an open IETF standard, but interoperability diminishes if every relay provider uses a different control plane for creating scopes and credentials. Cloudflare is documenting its API design in the MoQ CDN Provisioning Internet-Draft, which calls the provisioned resource a "scope" rather than a relay — both terms refer to the same logical boundary an application creates and enters with a credential. The goal is a common provisioning model across multiple CDN and relay implementations, though the draft is not yet an RFC and its API model may change.
The provisioning API is available now as part of the MoQ beta, free at any scale. Cloudflare notes that the API will evolve and recommends checking the developer docs for breaking changes. The team is soliciting feedback on finer-grained permissions, bring-your-own signing keys, and other feature requests at [email protected].



