Cloudflare Workers and R2 have become the foundation for cdnjs. The architecture handles 9 billion requests per day and changes the approach to CDN pipelines.
The cdnjs system has hit a wall not in delivery, but in evolution. With 108,000 requests per second and a 98.6% cache hit rate, the delivery layer operated stably. Degradation began within the publishing pipeline. New versions of libraries were difficult to process, and changes required coordination between GCP Functions, VMs, and Cloudflare. Observability suffered: debugging turned into a manual assembly of logs from different systems. This is a typical growth point for high-load systems: not runtime, but developer velocity becomes the bottleneck.
The solution is to build the entire system on the Cloudflare Developer Platform. R2 was chosen as the source of truth, while KV was retained only for metadata. This is a pragmatic compromise: KV is optimized for frequent reads and rare writes, which is ideal for SRI hashes and versions. Workers Cache replaced a separate caching layer, removing unnecessary coupling. The trade-off is clear: a strong dependency on a single vendor, but with gains in manageability and architectural consistency.
The implementation revealed where the platform is still “thin.” The pipeline is built on Workflows: every 10 minutes, the system checks npm and GitHub, downloads packages into R2, and processes them. CPU-heavy operations, such as compression, were offloaded to Containers. This is an important pattern: Workers remain the orchestrator, while heavy tasks are performed outside their constraints. The combination of Workflows + Queues + R2 events ensures resilience: in the event of a failure, the process continues from the last step. Durable Objects were used as a counter for synchronizing thousands of files—a simple but reliable coordination mechanism.
Critical complexity arose during data migration. Regenerating files broke SRI hashes due to the non-determinism of compression. This breaks contracts with clients where the hash is fixed. Ultimately, we chose to copy “as is” from KV to R2. But here we hit limits: 1,000 subrequests per Worker and 1,024 steps in a Workflow. The solution was sharding through Queues and parallel invocations. Notably, the platform limits were increased to 10 million subrequests and 25,000 steps. This is a rare case where user load directly influences the evolution of the platform.
The result is a fully unified architecture. cdnjs now operates on Workers, R2, KV, Queues, and Containers without external dependencies in the pipeline. Reliability has increased due to the cache → R2 → DigitalOcean fallback chain. Observability has improved due to a unified runtime environment, although specific metrics are not disclosed. The system retains key properties: no rate limiting, global availability, and immutable versions.
An interesting side effect is the influence of AI. LLMs actively use cdnjs due to stable URLs and the accumulated data corpus. This strengthens the requirements for immutability and verifiability (SRI). In this context, the architecture with R2 as the source of truth and hash verification appears not just convenient, but necessary.
The industry has long discussed moving pipelines closer to edge infrastructure. cdnjs demonstrates how this works in practice: not through simplification, but through task decomposition and explicit orchestration. The ability to transform packages into ES modules directly in the pipeline in the future is a logical continuation of this model.