Cloudflare has migrated cdnjs, its CDN for JavaScript and CSS libraries, to the Developer Platform. For architects, the important aspect is not just the migration itself, but how the new delivery and publishing scheme was constructed without changing the URL, package contents, and SRI hashes.
The issue with cdnjs was not traffic, but a division of responsibility. The service was already handling about 9 billion requests per day, averaging 108,000 requests per second, with a 98.6% cache hit rate. However, the publishing path remained distributed among Cloud Functions, Google Cloud Storage, Pub/Sub, a virtual machine with git-sync, GitHub, and Workers KV. This setup worked, but complicated maintenance: one circuit was responsible for serving files, while another handled their preparation, leading to an accumulation of architectural inertia between them.
Cloudflare chose a pragmatic path of consolidation. R2 became the source of truth for published files, KV served as the storage for metadata, versions, and SRI hashes, Workers became the entry point for delivery, and Workflows acted as the orchestrator for publishing. This is not merely a migration of components to a single platform. It represents a shift in model: from a set of disparate integrations to a unified managed pipeline, where the state can be monitored and processing can be resumed after a failure. The trade-off is also evident. The company achieved a more cohesive architecture but retained a fallback to DigitalOcean Spaces and an external origin in the previous logic, as fault tolerance in such a service cannot be built on a single storage solution.
The implementation faced several technical limitations. Packages are now first checked on a schedule through a workflow that looks at npm and GitHub for releases. They are then uploaded to R2 and passed to separate processing workflows for files. These workflows extract content, minify and compress assets, write the results back to R2, update KV, and synchronize the Algolia search index. This pipeline is convenient for error recovery, but it depends on platform limitations. For compression, Cloudflare uses Containers, as the current algorithms require buffering the entire library in memory. In Workers, this does not yet fit within a convenient implementation, although the company is considering streaming support as a way to move this part back to Workers.
Particular attention had to be paid to the immutability of package bytes. For a public CDN, this is not a trivial detail. If minification or compression changes, SRI hashes also change. This breaks consumer trust in the artifacts. Therefore, the migration was designed to preserve existing URLs, package contents, and SRI hashes. In engineering terms, this means that Cloudflare optimized the internal topology but did not alter the external service contract.
The transition also revealed platform limits. Cloudflare raised the limit for Worker subrequests from 1,000 to 10 million, and the limit for Workflow steps from 1,024 to 10,000, with the possibility of configuring up to 25,000. This is an important signal: even within its own Developer Platform, the company had to expand boundaries to support a production scenario of this scale. As a result, cdnjs became an example of dogfooding not in a marketing sense, but as a test of the platform under real load and the actual complexity of the publishing circuit. The final scheme appears more compact, but its main advantage lies elsewhere: it is more explainable, more observable, and more resilient to failures than the previous combination of several cloud systems.