Media over QUIC has a strange problem for a protocol this well-backed: there is a great deal written about it and almost nowhere to try it.
Search for it, and you will find explainers, IETF drafts, and Cloudflare's announcement that they run relays at the edge. What you will not easily find is a server you can point a browser at. Until recently, the honest answer to "how do I try MoQ" was "compile this Rust project and good luck."
Disclosure before anything else: I work at Ant Media, and we build the server this runs on. I am writing this because I spent last week deploying it end-to-end, and the notes seemed worth having in one place — including the parts that went wrong, which are the useful parts.
What MoQ actually is, briefly
MoQ is a live media protocol built on QUIC, currently being standardised by the IETF. The working group includes Google, Cloudflare, Cisco, Meta and Akamai. The goal is to replace WebRTC, HLS and RTMP with one protocol that covers all of them.
The reason it exists is a trade-off every streaming engineer has lived with. WebRTC gives you real-time latency and no CDN — every viewer is a peer connection, and scaling means an SFU and a lot of servers. HLS gives you CDN scale and several seconds of delay, which breaks anything interactive.
MoQ runs on QUIC, where a delayed packet does not block the ones behind it, and uses a publish/subscribe model that a CDN can cache. That is the whole pitch: sub-second delivery with a fan-out story that is a caching problem rather than a connection-count problem.
It uses WebTransport, so it works in the browser with no plugin and no peer connection bookkeeping.
What you end up with
A single EC2 instance running a MoQ relay, a browser publisher, and a browser player. You publish from one tab, watch in another, and the debug panel tells you what you are actually getting rather than what a marketing page claims.
It takes roughly ten minutes from installation to publishing and playing your MoQ stream.
The four steps
1. Launch the AMI. A c5.xlarge is plenty for evaluation. The image arrives with the server already running.
2. Add port 4443 to the security group, on TCP and UDP. That is where the relay listens. Read the next section before you skip past this.
3. Turn on SSL from the web panel. Open http://your-server-ip:5080 — HTTP on 5080, because that is how the server starts before a certificate exists. Then Settings → SSL → Subdomain of antmedia.cloud → Activate. You get an allocated subdomain and a Let's Encrypt certificate, and the server restarts on https://your-subdomain.antmedia.cloud:5443.
You do not need to own a domain. This surprised me, and it removes the most annoying prerequisite.
4. Install the plugin. SSH in as ubuntu:
# fetch the plugin release onto the server
curl -L "https://drive.usercontent.google.com/download?id=1X9ymWsDjfdNdcXH2h0y2Ak2IWpmnkijk&export=download&confirm=t" -o MoQPlugin-release.zip
# unpack it and step into the folder
unzip MoQPlugin-release.zip
cd MoQ-Plugin
# make the installer executable, then run it
chmod +x install-moq-plugin.sh
sudo ./install-moq-plugin.sh
# put the browser publisher and player into your application
sudo mkdir -p /usr/local/antmedia/webapps/live/moq
sudo cp -r moq-ams-player-build/* /usr/local/antmedia/webapps/live/moq
# restart so the server loads the plugin
sudo service antmedia restart
Then open the publisher at /live/moq/publish.html, pick a stream ID and hit publish. Open the player at /live/moq/play.html in a second window, enter the same stream ID, and select the source track.
The two important things
The security group rule has to cover UDP, not just TCP.
With only TCP open, every page loads perfectly. The publisher initialises. The player initialises. The WebTransport session simply never establishes, and nothing surfaces an error worth reading. Everything looks like a working install right up until it isn't.
If you are deploying anything QUIC-based on EC2, open both.
Browser support is the real constraint today, not the protocol.
Chrome, Edge, and Brave are fine. Safari needs 26.4 or later. If you were thinking about anything consumer-facing, that is a meaningful chunk of an audience, and it is the thing most likely to decide whether MoQ is usable for you right now.
The honest part: this is moq-lite
What we ship is moq-lite, a deliberately reduced subset of the IETF moq-transport draft, specified separately as draft-lcurley-moq-lite. It is forward-compatible with moq-transport and works against moq-transport relays, including Cloudflare's.
It leaves things out on purpose — no sub-groups, no gaps, no joining fetch, no object properties. In practice, most applications do not need them, but it is a real difference, and you should know it is there.
More broadly: if any vendor tells you they support MoQ, ask which draft and what they have tested against. The standard is still moving. Draft-20 is the interop target for the working group's October interim, and the transport draft is not scheduled to be requested for publication until the end of 2026. Ours included — this is a fair question to ask us.
Where I would leave it
MoQ is at the stage where you should run it in staging and form an opinion, not where you should migrate anything. The reason to look now is that the architecture question — do we keep running an SFU — becomes much easier to answer once you have seen the alternative work.
If you try it and something breaks, I would rather hear it than not. The full deployment guide with screenshots is on our site.
Top comments (0)