This update enables production-ready low-latency media applications by providing the necessary isolation and security controls for MoQ. Engineers can now deploy global pub/sub infrastructure without managing servers, leveraging Cloudflare's network for scale and security.
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.
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.
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.
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 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.
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.
You can provision a relay two ways: with the HTTP API and in the Cloudflare dashboard.
Creating a relay takes a single API call and only needs a name:
Cloudflare returns a relay ID and the two default tokens:
The first token can publish and subscribe, and the second can only subscribe.
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:
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.
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:
A viewer connects with moq-sub:
The relay reads the token when the session opens and checks whether the requested operation is allowed.
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.
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.
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.
Continue reading on the original blog to support the author
Read full articleThis integration allows engineers to automate security responses using real-time global threat intelligence. By exposing live actor and industry data directly in the WAF, teams can proactively block sophisticated attacks with minimal latency and full Infrastructure as Code support.
Monitoring global disruptions helps engineers distinguish between application bugs and systemic infrastructure failures. These events underscore the importance of multi-region redundancy and the technical mechanisms, like BGP and filtering, that govern global internet reachability.
This feature allows AI-generated or user-provided code to have its own persistent, low-latency database without manual provisioning. It bridges the gap between ephemeral serverless execution and stateful application needs in a secure, sandboxed environment.
This allows engineers to meet strict data sovereignty and compliance requirements without losing global DDoS protection. By decoupling ingestion from processing, teams can precisely control where TLS termination and L7 logic occur, which is critical for regulated industries and AI data privacy.
