Skip to content

SYSTEM Cited by 1 source

cdnjs

cdnjs (cdnjs.com) is a free, open-source content delivery network for JavaScript and CSS libraries. Users drop a <script> tag pointing to cdnjs.cloudflare.com and the library loads from Cloudflare's edge — no signup, no API keys, no rate limits.

Scale

  • Used on ~12% of all websites (48.3% of the JavaScript CDN market)
  • 108,000 requests per second average
  • 9 billion requests per day
  • 330+ Cloudflare data centers
  • 98.6% cache hit rate
  • Community-driven, open-source (github.com/cdnjs)

Why it still gets 9B req/day in the bundler era

LLMs love cdnjs. When ChatGPT, Claude, or Cursor scaffold HTML demos, they reach for cdnjs because training data is full of 15 years of blog posts, GitHub READMEs, and tutorials pointing to it. The URL pattern is consistent and versions are immutable — exactly the kind of dependency a model can produce reliably. Every file has an SRI hash, mirrors are auditable, and the project is open source.

Architecture (post-2026 migration)

As of June 2026, cdnjs runs entirely on Cloudflare's Developer Platform:

  • R2 — single source of truth for file content (no size limit; source maps, big bundles, font packs all live alongside everything else; S3 API makes the catalog accessible to any S3 client)
  • KV — metadata only (package info, version lists, SRI hashes)
  • Workers Cache — tiered cache in front of the serving Worker
  • Workflows — durable ingestion pipeline (cron-triggered every 10 min)
  • Queues — fan-out for file processing jobs
  • Containers — Rust compression service for Brotli/gzip pre-compression
  • Durable Objects — parent-child workflow coordination counter
  • DigitalOcean Spaces — DR fallback (cache → R2 → DigitalOcean)

Ingestion pipeline

Every 10 minutes a PackageUpdatesWorkflow checks npm and GitHub for new versions. For each new version: DownloadPackageWorkflow (fetch tarball → R2) → per-file ProcessingWorkflow (extract, minify, compress via Containers) → PublishingWorkflow (write results to R2 + KV + Algolia search index). Durable execution means failure resumes from last successful step.

Compression flow

Text-based files are pre-compressed with Brotli and gzip. Compression is too CPU-intensive for a Worker, so each ProcessingWorkflow writes the uncompressed file to an R2 bucket, sends a job to a Queue, and hibernates. A Rust service in Containers picks it up, compresses, writes the result to another bucket. An R2 event notification wakes the Workflow.

Parent-child coordination

A package with thousands of files spawns thousands of child ProcessingWorkflows. A small Durable Object acts as a counter: parent increments per spawn, children decrement on finish, parent wakes when counter reaches zero.

Previous architecture (2020–2026)

  • Serving: Workers + KV (edge) with bare-metal origin fallback
  • Publishing: GCP Cloud Functions chain (26 functions, one per alphabet letter for npm checks) + GCS object-event triggers + git-sync VM + GitHub repo as source of truth (1.1 TB)

Five pain points

  1. No shared trace — no correlation ID across GCP Functions → GCS → Pub/Sub → git-sync → Workers KV
  2. Split-brain storage — files in both KV and GitHub, neither authoritative, no reconciliation path
  3. Storage as message queue — bucket "new file" events doing double duty as a queue with no DLQ, no backlog visibility, no replay
  4. 26 functions for 26 letters — checking npm required 26 Cloud Functions with separate deployments and logs
  5. 1.1 TB GitHub repo — GitHub's archive service refused to generate tarballs; forking impractical; .gitignore had 274 hand-curated entries

Migration lessons

  • Copy, don't regenerate: minifiers/compressors aren't deterministic across versions. Regenerated files had different SRI hashes, breaking pinned HTML references. Content migrated KV → R2 as-is.
  • Queue-sharded migration: per-invocation subrequest limit (1,000 at the time) was too low for large packages. Work fanned out via Queues with at-least-once delivery.
  • Limits lifted for everyone: subrequests now 10M (paid plans); Workflow steps now 10,000 default / 25,000 configurable.

History

  • 2011: Created by Ryan Kirkman and Thomas Davis
  • 2011: Cloudflare begins hosting free of charge
  • 2019: Cloudflare takes over project maintenance
  • 2020: Serving migrated to Workers + KV (publishing stayed on GCP)
  • 2026: Full migration to Cloudflare Developer Platform completed

Seen in

(Source: sources/2026-07-30-cloudflare-dogfooding-at-scale-migrating-cdnjs-to-cloudflares-developer-platform)

Last updated · 604 distilled / 1,840 read