Cloudflare has moved cdnjs, the open source JavaScript and CSS library CDN that serves about 9 billion requests a day, onto its Developer Platform, replacing a mixed publishing stack spread across Cloudflare and Google Cloud Platform with Workers, R2, Workflows, Queues, Durable Objects, KV, and Containers. The company says the overhaul keeps the service’s URLs, package contents, and Subresource Integrity hashes intact while making R2 the source of truth for published files.
Cloudflare shifts cdnjs onto its own platform
Cloudflare described the migration as a large-scale example of “dogfooding” its own platform services. cdnjs is widely used: Cloudflare says it handles roughly 9 billion requests per day, averaging 108,000 requests per second across more than 330 Cloudflare data centers, and is used by about 12% of websites. For a service at that scale, the move is as much about operational simplification as it is about proving out Cloudflare’s newer developer-facing products.
The migration did not change what users request from cdnjs. Existing URLs continue to work, package contents are preserved, and the SRI hashes used by websites to verify file integrity remain the same. That matters because many sites depend on exact bytes for browser caching and security checks, so even small changes to minification or compression can break deployments.
Why the old cdnjs setup needed a rebuild
Cloudflare’s earlier architectural shift in 2020 had already moved file serving away from dedicated origin machines and into Workers and Workers KV for normal traffic, while keeping an external origin as a fallback. It also introduced precompressed Brotli and gzip assets to improve delivery efficiency. But the publishing side of the system remained split across different services and clouds.
According to Cloudflare, the old ingestion pipeline relied on Google Cloud Functions to periodically check npm for releases, Google Cloud Storage to hold packages, Pub/Sub for messaging, and a virtual machine running git-sync to synchronize repository content. The setup had become unwieldy enough that the company tracked package updates using 26 Cloud Functions divided into alphabetic shards. Meanwhile, the GitHub repository had grown beyond 1.1 TB of packed storage, and published files were represented in both GitHub and KV.
How the new Cloudflare Developer Platform architecture works
The redesigned system centers on R2 as the authoritative store for published package files. KV now stores metadata, versions, and SRI hashes, while a Worker handles incoming requests and Workers Cache provides the caching layer. Cloudflare also mirrors published content to DigitalOcean Spaces as a fallback if R2 cannot serve a file.
Package ingestion is orchestrated with Cloudflare Workflows. A scheduled workflow checks npm and GitHub for releases, downloads packages into R2, and triggers processing workflows for individual files. Those workflows extract package contents, minify and compress assets, write the resulting files back to R2, update metadata in KV, and refresh the Algolia search index. Cloudflare said the workflow state makes it possible to resume from the last completed step if a failure interrupts processing.
Why R2 became the source of truth
Moving the source of truth into R2 simplifies the system’s data model. Instead of depending on multiple stores and a chain of synchronization steps, the service now treats one object store as the canonical location for the files it publishes. That is especially useful for a CDN that must keep file bytes stable over time.
The company also noted that preserving package bytes was critical because any alteration in minification or compression could change SRI hashes. By making R2 the anchor for published content and separating metadata into KV, Cloudflare reduced the chance that serving and publishing paths drift out of sync.
Compression pushed some work outside Workers
One constraint in the migration was compression. Cloudflare said the existing processing algorithms need an entire library buffered in memory, which makes them a poor fit for direct execution in Workers. As a result, the company uses Containers for compression rather than running that work entirely inside Workers.
Cloudflare said it is exploring streaming support that could eventually let this processing move into Workers as well. For now, the hybrid approach reflects a practical split: Workers handle delivery and orchestration, while Containers take on the heavier in-memory processing step.
Platform limits surfaced during the migration
The migration also revealed how far the service pushed Cloudflare’s platform quotas. To support the new architecture, Cloudflare increased Worker subrequests from 1,000 to 10 million and raised Workflow steps from 1,024 to 10,000, with up to 25,000 configurable. Those changes highlight both the scale of cdnjs and the operational demands of using serverless-style building blocks for a high-volume public service.
That kind of adjustment is notable because it shows the migration was not just a matter of swapping one service for another. Cloudflare had to tune platform limits to accommodate a real workload rather than an internal prototype, which is exactly the sort of stress test that “dogfooding” is meant to expose.
What the migration means for Cloudflare and cdnjs
For Cloudflare, the project is a showcase of its Developer Platform running a globally visible service at production scale. The architecture now uses R2 for artifacts, KV for metadata, Workers for delivery, and Workflows for publishing, with Containers filling an important processing gap. That combination gives the company a concrete example of how its platform pieces fit together in the real world.
For cdnjs users, the most important detail is continuity. Cloudflare says the migration preserved the service’s URLs, package contents, and integrity hashes, so developers should not need to make changes simply because the backend moved. The service also keeps its fallback path in place through DigitalOcean Spaces, adding another layer of resilience.
Key points from the migration
- cdnjs serves about 9 billion requests per day, or roughly 108,000 requests per second.
- Cloudflare says the service reaches more than 330 Cloudflare data centers.
- The CDN is used by approximately 12% of websites.
- R2 is now the source of truth for published package files.
- KV stores metadata, versions, and SRI hashes.
- Workers handle request delivery and Workers Cache provides caching.
- Workflows orchestrate package ingestion and processing.
- Containers handle compression because the current algorithms need full libraries in memory.
Cloudflare’s broader platform message
Beyond the engineering details, the migration reinforces Cloudflare’s message that its platform can support more than lightweight edge logic. cdnjs is a public, high-volume service with strict integrity requirements and a complex publishing pipeline, which makes it a demanding test case for any cloud platform. Cloudflare’s decision to move it entirely onto its own stack signals confidence in the maturity of those services.
At the same time, the project shows that large migrations still require careful design tradeoffs. Some work is now cleaner and more centralized, but other tasks still depend on Containers and platform limit changes. That balance is common in modern infrastructure: the goal is not to eliminate every special case, but to reduce fragmentation while keeping the system reliable.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: August 15, 2026 at 1:54 am
0 views
