Cloudflare has completed a full migration of cdnjs, its open source content delivery network for JavaScript and CSS libraries, to its Developer Platform, consolidating infrastructure that was previously split across Cloudflare and Google Cloud Platform. The company announced the shift in a detailed technical post, describing the effort as an example of using its own services at the scale of a widely deployed public utility. The new architecture relies entirely on Workers, R2, Workflows, Queues, Durable Objects, KV, and Containers, with R2 now functioning as the authoritative source for published package files while maintaining existing URLs, package contents, and Subresource Integrity hashes.
The service now handles roughly 9 billion requests each day, which translates to an average of 108,000 requests per second distributed across more than 330 Cloudflare data centers worldwide. Cloudflare reports a 98.6% cache hit rate and estimates that cdnjs is deployed on approximately 12% of websites. Before the migration, the publishing pipeline was fragmented: Google Cloud Functions checked npm periodically for package releases, Google Cloud Storage stored packages, Pub/Sub managed messaging, and a virtual machine running git-sync kept repository content synchronized. The system relied on 26 Cloud Functions divided into alphabetic shards to track package updates, while the GitHub repository had ballooned beyond 1.1 terabytes of packed storage and published files were duplicated in both GitHub and KV.
According to the report, the revised architecture designates Cloudflare R2 as the source of truth for published files, with KV storing package metadata, versions, and SRI hashes, a Worker managing requests, and Workers Cache supplying the caching layer. Published content is also mirrored to DigitalOcean Spaces as a backup if R2 can't deliver a file. Package ingestion is now managed through Cloudflare Workflows: a scheduled workflow monitors npm and GitHub for releases, downloads packages into R2, and triggers processing workflows for individual files. The processing pipeline extracts package contents, minifies and compresses assets, saves the resulting files in R2, updates metadata in KV, and refreshes the Algolia search index, with workflow state enabling processing to pick up from the last completed step after a failure.
Cloudflare explained that preserving package bytes was essential because any changes to minification or compression would alter SRI hashes, breaking existing integrations. The company noted that compression posed a constraint because current processing algorithms require buffering an entire library in memory, so Cloudflare uses Containers for compression instead of running the processing directly in Workers. The migration also revealed platform limits, prompting Cloudflare to increase Worker subrequests from 1,000 to 10 million and Workflow steps from 1,024 to 10,000, with up to 25,000 available on request. The company said it's investigating streaming support that could eventually allow compression processing to shift to Workers.
The final architecture consolidates artifacts in R2, metadata in KV, delivery through Workers, and publishing via Workflows, replacing the earlier hybrid model that spanned multiple cloud providers. Cloudflare characterized the migration as an internal demonstration of its Developer Platform's ability to support high-scale public services. The shift builds on a 2020 change that moved cdnjs file serving to Workers and Workers KV, eliminating dedicated origin machines for regular traffic while keeping an external origin as a fallback, and introduced precompressed Brotli and gzip assets to boost delivery efficiency. For organizations considering similar consolidations, the approach underscores the operational trade-offs between simplicity and flexibility when moving core infrastructure to a single vendor's stack. Enterprises evaluating multi-cloud versus single-platform strategies will weigh the benefits of tighter integration against the risks of concentrated dependency.