Persistent Websockets are not trivial to support for a number of reasons, even just by yourself with your own L4 infrastructure, much less from a global service

Persistent Websockets are not trivial to support for a number of reasons, even just by yourself with your own L4 infrastructure, much less from a global service provider, so it makes sense to take some measurements and set an entry fee. They also generally aren't critical resources for many apps and for ones that are don't tend to require cache layers for them to work, meaning you can deploy your own service for that part; AFAIK, you can proxy arbitrary TCP connections through Cloudflare's network using Argo to still get DDOS/IP protection, and manage the L4 backend yourself; they don't restrict this kind of usage. Also, CF Workers do allow WebSockets attached to durable objects; they don't have pricing information on them now though; they're still letting people get their feet wet. The pricing you're referring to is just if people want to turn on WebSockets for their CDN, I think. > 100,000's of concurrent lite upd 'websockets' This obviously is not true, much less for $2. :) You can have "100,000s" of "connections" using HTTP/2 today, including with WebSockets, thanks to transport streams. But this number doesn't mean anything by itself; you often don't ridiculous ratios of streams:clients like 1000:1 or whatever, it's often much smaller, so the per-connection overhead matters a lot in practice e.g. if your ratio is 3:1, then the initial handshake and state tracking matter significantly when considering total overhead. Your QUIC framework still has to do connection tracking, congestion control, encryption, stream muxing, etc. It's not magically a billion times less "expensive" than TCP for magical reasons, but it does avoid some of TCP's long-tail pitfalls in terms of latency and mobile use. WebTransport also avoids some of the design constraints of WebSockets (unreliable transport!), which helps, and in some cases is a significant performance boost for end to end performance between the client & server. But it's not going to magically make running WebTransport services 100x faster, or easier vs the competition or whatever. The reality is that "100,000s concurrent instances" of anything is complex to support either yourself or at scale from providers. I wouldn't bet money on WebTransport being easier for these providers to offer than WebSockets will. If anything, it is currently, and will remain MORE difficult to support right now; due to the fact QUIC stacks haven't had decades of optimization stuffed into them, high-scale QUIC deployments tend do a lot worse in terms of CPU cycles and utilization. That will change, but not now. And they might still support it despite this! Because WebTransport is really useful technology, don't get me wrong. (This is even before you get into the ever-fierce debate about UDP, about whether people will end up blocking it and requiring HTTP/2 fallbacks, etc...)