Last year, we enabled Media over QUIC (MoQ) on every Cloudflare server and opened the network for anyone to test. It provided a global MoQ endpoint, but not the isolation and access controls needed to run an application.
Today, weâre adding those isolation and access controls. The new MoQ provisioning API lets you create an isolated relay for your application and issue separate credentials for publishers and subscribers. The relays you create are available across Cloudflareâs network within seconds, with no servers to deploy, size, or load balance.
Cloudflare now supports the draft-14 and draft-16 versions of the MoQ Transport protocol with authentication support.
You can create relays through the API and the Cloudflare dashboard. They are completely free to use during beta.
A QUIC recap on MoQ
MoQ (originally short for Media over QUIC) is a new open protocol under development at the Internet Engineering Task Force (IETF), the standards body that also standardized HTTP, TLS, and QUIC. It is being developed in the open and will become a free public standard (an RFC) that anyone can implement. No single company owns it.
MoQ is a publish/subscribe system. A publisher sends out streams of data that have names, and subscribers ask for those streams by name. Between them sit relays, which are just CDN servers that copy each stream to everyone who wants it. A relay never has to look inside the data it forwards, so one publisher can reach a large audience without handling the fan-out itself.
Because relays don't care what's in the data, the same protocol can carry many things that each used to need a separate system: live video, video calls, low-latency messaging, and more. It runs on QUIC, the transport under HTTP/3, which is what keeps latency low.
The practical result is that you don't have to build and run your own fleet of specialized servers. You publish to a CDN through one simple API and get both low latency and large scale for much less cost.
How we got here: the MoQ open preview
Last year, we launched the first global MoQ relay network: every Cloudflare server in over 330 cities became a MoQ relay, free and open to anyone. Because these endpoints required no authentication, they were ideal for protocol testing and client development. More than 1,000 unique clients still connect each day to test against them.
But an unauthenticated relay isn't suitable for production, because you can't control who publishes and who subscribes. That rules out any application that needs confidentiality, access control, or a clear split between publisher and subscriber roles. Take a live auction site, where bids have to reach bidders in milliseconds. MoQ is a good fit, but publishers and subscribers need different permissions, so that a viewer's credentials can't be used to hijack the publisher's tracks.
What is a relay on the Cloudflare MoQ Network?
In most MoQ deployments today, a relay is a dedicated server or a dedicated process on a shared server. Scaling this architecture means running more instances, assigning clients to them, and adding load balancers as demand changes. This is not how any Cloudflare service works, including our Realtime SFU WebRTC service.
Provisioning a relay doesnât start a virtual machine, container, or dedicated process. Instead, it creates an isolated scope across the existing global network.
That scope separates your namespaces, tracks, and objects from those belonging to other relays. It also defines who can enter the scope and whether they can publish or subscribe. Clients connect to the Anycast endpoint, and Cloudflare handles routing them across the network.
If youâre familiar with web hosting, creating a Cloudflare relay is more like adding a virtual host than starting a new web server. Since the infrastructure is already running, the provisioning API adds your applicationâs configuration and credentials. This makes the relay available immediately without choosing regions, estimating capacity, or setting up a load balancer.
The control plane API for MoQ at Cloudflare
The provisioning API is a control plane: it manages relays and the tokens used to reach them, and it never touches the media that flows through them.
There are two kinds of resources.
- A relayis the isolated scope from the previous section, so one application's streams never mix with another's.Â
- Atokenis a credential that grants a set of operations (publish, subscribe, or both) on a single relay. Handing publishers and subscribers different tokens is what stops a viewer from taking over a broadcaster's tracks.
Each token is scoped to the operations a client needs, can be given an expiration, and can be revoked on its own. That lets you grant exactly the access a client should have, and take it back later without disrupting anyone else.
For now, each token applies to an entire relay and permits publishing, subscribing, or both. We're working in the IETF and the wider MoQ community on a richer scheme that works for everyone. If you have opinions, tell us at moq@cloudflare.com.
Provision a relayÂ
You can provision a relay two ways: with the HTTP API and in the Cloudflare dashboard.Â
With the API
Creating a relay takes a single API call and only needs 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"}'
Cloudflare returns a relay ID and the two default tokens:
The first token can publish and subscribe, and the second can only subscribe.
{
"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..."
}
]
}
]
}
}
To give a client narrower access, add more tokens. This one is a subscribe-only token for viewers that expires at the start of 2027:
In the Cloudflare dashboard
curl -X POST \
https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/moq/relays/$RELAY_ID/tokens \
-H "Authorization: Bearer $API_TOKEN" \
-d '{"operations": ["subscribe"], "label": "viewers", "expires_at": "2027-01-01T00:00:00Z"}'
You can also create a relay in the dashboard:
Go to Media  > Realtime > MoQ Relay. Select Create relay, give it a name, and then confirm.Â
Connect a publisher and a subscriber
You can create and manage tokens through the API or dashboard, just as you can the relay itself. Give your broadcaster the publish-and-subscribe token and your viewers the subscribe-only token. Each client sends its token when it opens a MoQ session, and the relay enforces what that token is allowed to do.
The token travels in the URL path. For example, with the open-source moq-rs tools, a broadcaster can publish a fragmented MP4 stream from ffmpeg:
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 when the session opens and checks whether the requested operation is allowed.
What we changed to support draft-16Â
The provisioning API is only one part of whatâs new. The MoQ transport itself is advancing fast, and Cloudflare now supports draft-16 of the IETF MoQ spec in its relays. This draft adds two features relevant to publishing and subscribing.
PUBLISH now lets a publisher send a track to a relay before a viewer requests it. Without PUBLISH, the first subscription must travel through the relay chain to the publisher before the publisher starts sending. With PUBLISH, the relay can already be receiving the track when the first viewer connects.
SUBSCRIBE_NAMESPACE lets a subscriber request every track announced under a namespace instead of requesting tracks individually. The subscription also covers tracks added later, such as a new video rendition or audio track introduced during a live stream.
You can now connect a draft-16 client to use both features.Â
Built in the open
MoQ is an open standard, developed at the IETF by engineers across the industry. This lets clients and relays implement a common protocol. That interoperability is less useful if every relay provider requires a different control plane for creating scopes and issuing credentials.
In that vein, weâre documenting the design behind this API in the MoQ CDN Provisioning Internet-Draft. The draft calls the provisioned resource a scope rather than a relay, but both terms refer to the same logical delivery context: a boundary that applications create and then enter with a credential.Â
The goal is for multiple CDN and relay implementations to support a common provisioning model. The document is still an Internet-Draft, not an RFC, and its API model may change as the working group develops it.Â
Available today, still free in beta
The MoQ relay provisioning API is available now, as part of the MoQ beta. It's free to use at any scale during this preview period.Â
The API will change as we develop it, so we recommend checking the __developer docs __for updates and breaking changes.Â
Weâd also love to hear what you want next. Finer-grained permissions? Bring-your-own signing keys? Let us know at moq@cloudflare.com.
Get started today
- Read the __developer documentation__Â
- Read the API reference docs.Â
- Read the provisioning draft.Â
- Email us: __moq@cloudflare.com__Â
- Building with MoQ? Join the __Cloudflare Developers Discord__to share your projects and tell us what the tech preview needs.