Cloudflare just moved cdnjs, the open source CDN that serves JavaScript and CSS libraries, onto its own Developer Platform. The migration consolidates publishing and delivery onto Workers, R2, KV, Workflows, Queues, Durable Objects and Containers, all while preserving package contents, URLs and SRI hashes at a scale of 9 billion requests per day. That last part matters. Most engineering teams would balk at touching a system with that kind of traffic. Cloudflare treated it as a proof point for its own stack.
This is not a story about a company eating its own dog food for the sake of it. The practical takeaway is that the tools used to build this migration are the same ones available to any developer. When a platform runs its own open source CDN on its own serverless primitives, it signals that these building blocks are ready for production, not just demos. If you have been waiting for permission to trust Workers or R2 with something serious, this is as close to a reference architecture as you will get.
The migration also connects to a pattern we have seen elsewhere. Cloudflare recently moved its main blog from WordPress to EmDash, its open source content management system, and documented the performance gains. That move was about owning the stack end to end. This cdnjs migration is the same instinct applied to a much larger surface area. Both stories point to a broader shift: infrastructure teams are no longer content to rent servers and call it done. They want platforms that let them build, deploy and scale without juggling a dozen external services. The fact that cdnjs still serves the same URLs and SRI hashes means users did not have to change a single line of code. That is the quiet kind of progress that matters.
What we would tell a reader who asks about this is straightforward. Look at the operational decisions, not the scale. Cloudflare chose to run publishing and delivery on the same platform, which means fewer moving parts and a single mental model for how data flows. That consolidation is the real innovation here, not any single technology. The use of Workflows for orchestration and Queues for async processing suggests they are treating this as a distributed system problem, not a file hosting problem. For teams considering a similar move, the lesson is to focus on the seams between your services. If you can remove the friction there, you can handle growth without rewriting everything.
The open question is whether this becomes a template for other large scale open source projects. If cdnjs can run on a serverless platform at 9 billion requests a day, the argument that these tools are only for small or experimental workloads loses its footing. We would watch to see if Cloudflare publishes more details on cost per request or failure modes under load. That kind of transparency would give other teams the confidence to follow. For now, the concrete point is this: the line between "developer platform" and "production infrastructure" just got thinner, and that is good news for everyone who has been waiting for serverless to grow up.