Dogfooding at scale: migrating cdnjs to Cloudflare’s Developer Platform

**cdnjs**, one of the Internet’s busiest open-source CDNs, now runs entirely on **Cloudflare’s Developer Platform**. The service handles about **9 billion requests a day**. Cloudflare moved the stack onto its own building blocks rather than keeping it on external infrastructure—an explicit dogfood of Workers, Workflows, and the rest of the platform under real production load.

The migration is not a demo or a staging slice. At that request volume, every limit on **Workers** and **Workflows**—concurrency, duration, orchestration reliability, edge routing—gets exercised continuously. Cloudflare used that pressure to raise those limits for all customers, so capacity and tooling gains are not reserved for an internal flagship.

For engineers and builders, the useful signal is operational proof. If a public CDN at multi-billion daily request scale can sit fully on Workers and Workflows, those primitives are no longer only for light edge logic or simple glue jobs. Teams designing high-traffic static and library distribution can treat the same platform as a serious hosting target, not only a side channel in front of a traditional origin.

In market terms, Cloudflare is both operator and vendor. Putting **cdnjs** on the same Developer Platform it sells closes a credibility gap that competitors still have to answer with synthetic benchmarks or partial migrations. It also tightens the loop between product development and production pain: platform bugs and ceilings surface first on Cloudflare’s own traffic.

Watch for how far the raised **Workers** and **Workflows** limits show up in public docs and quotas, and whether more of Cloudflare’s own large properties follow the same full cutover. For teams already on the platform, re-check concurrency and workflow ceilings against this load class; for teams evaluating edge runtimes for open-source or multi-tenant CDNs, treat the **cdnjs** move as a concrete scale reference rather than a marketing claim.