Dogfooding at scale: migrating cdnjs to Cloudflare's Developer Platform
Source
Simona Badoiu
Author
Simona Badoiu
Date
Key takeaways · AI-distilled
Splitting storage across Workers KV and a GitHub repo left neither one authoritative. A version could land in KV, silently fail to reach git, and serve fine for weeks. No component knew the full pipeline state, so that alert could not exist.
The old ingestion chain used a storage bucket as its message queue: each function dropped a file, and the bucket's new-object event fired the next step. That buys you no dead-letter queue, no backlog visibility, and no clean replay when a step fails.
Just polling npm for new versions took 26 Cloud Functions, one per letter of the alphabet, each with its own deployment and its own logs. Answering the question is ingestion healthy meant checking all 26.
In the rebuild, R2 holds file content and KV holds only metadata: package info, version lists, SRI hashes. KV is built for heavy reads and rare writes, and R2 has no practical size cap, so source maps and font packs finally fit.
Serving now reads cache to R2 to DigitalOcean Spaces, where every published file is mirrored. The disaster-recovery copy doubles as a live fallback, so an R2 outage degrades into a slower read rather than downtime.
Why it matters
It's a rare public dogfooding case study showing how Cloudflare's own Workers/Workflows/R2 stack holds up at extreme scale, and it reveals concrete new platform limits (10M subrequests, 25K Workflow steps) that any engineer building on Cloudflare should know about.
Key quotes
“The limits we hit are limits we lifted for everyone.”
“When ChatGPT, Claude, or Cursor scaffold a quick HTML demo, they reach for cdnjs because their training data is full of it.”
