Cloudflare Runs cdnjs on Its Own Edge Platform, Moving 9 Billion Daily Requests Off Google Cloud

The web's most-used open-source JavaScript library network now runs entirely on Cloudflare's edge platform. As of June 23, 2026, cdnjs — the free CDN that serves JavaScript and CSS libraries to roughly 12% of all websites — completed a full migration to Cloudflare Workers, Workflows, R2, KV, and Queues, ending a six-year stretch where parts of its publishing pipeline sat on Google Cloud.

cdnjs now runs on Cloudflare's edge platform

cdnjs is a strange piece of the internet's plumbing. It has no signup, no API keys, and no rate limits. A developer drops a <script> tag pointing at cdnjs.cloudflare.com and a library loads from Cloudflare's edge, anywhere in the world. That simplicity made it a default for tutorials, CodePen demos, and Stack Overflow answers for fifteen years. Today it averages 108,000 requests per second — about 9 billion a day — served across more than 330 Cloudflare data centers with a 98.6% cache hit rate.

Cloudflare detailed the migration in a blog post published this week, explaining why a platform that was already working well got rebuilt from the inside out.

Why fix something that wasn't broken

The old architecture served users fine: 98% cache hits, billions of requests, no meaningful outages. The problem was internal. Shipping new features or fixing package-processing bugs meant coordinating deployments across Google Cloud Functions, a git-sync VM, and Cloudflare's edge. Observability was the worst part — debugging a single package update meant hand-stitching logs from GCP Logging and Cloudflare Logpush, which shared no common correlation key.

Five pain points pushed the rebuild:

No shared trace. A package update passed through Cloud Functions, Google Cloud Storage events, Pub/Sub topics, a git-sync VM, and Workers KV before reaching a user. None shared a request ID. Partial failures — a version that wrote to KV but silently missed the GitHub repo — could serve fine for weeks before anyone noticed.
Split-brain storage. Files lived in Workers KV at the edge and a GitHub repository as source of truth. Neither was authoritative, and drift was hard to reconcile.
Object events as glue. Cloud Functions handed off work through storage buckets, with no dead-letter queue, no backlog visibility, and no clean replay.
26 functions for 26 letters. Checking npm for updates required one Cloud Function per alphabet letter, each with its own deployment and logs.
A repo GitHub couldn't serve. The cdnjs/cdnjs repository grew past 1.1TB of packed storage, so GitHub's own archive service refused to generate tarballs, forks became impractical, and the .gitignore had ballooned to 274 hand-curated entries.

Retiring that stack also shrank the attack surface. Cloud Functions, a git-sync VM, container images, GCS buckets, and service-account keys all disappeared — closing what Cloudflare calls "all of the recently opened cdnjs vulnerabilities."

Edge-native rebuild

The new cdnjs runs on the same building blocks any Cloudflare customer can rent. R2 object storage is the single source of truth for file content, with no practical size limit, so source maps, font packs, and big bundles that never fit in KV now live alongside everything else. The S3-compatible API means the entire catalog is accessible to any S3 client. KV keeps only metadata — package info, version lists, SRI hashes.

Workers Cache, a tiered cache Cloudflare launched this year, now sits in front of the serving worker, replacing a separate internal caching layer. DigitalOcean, which has hosted the cdnjs website for years, now hosts a storage mirror too: every file published to R2 is copied to DigitalOcean Spaces as a disaster-recovery copy and live fallback, so the chain is cache → R2 → DigitalOcean.

The ingestion pipeline runs on Cloudflare Workflows. Every ten minutes a cron job triggers a workflow that checks npm and GitHub for new library versions. Each new version spawns a download workflow, then per-file processing workflows that extract, minify, and compress, and finally a publishing workflow that writes to R2 and KV and updates the Algolia search index. Because Workflows provides durable execution, a network timeout or compression error resumes from the last successful step instead of restarting the whole run.

The migration hit platform limits — and lifted them for everyone

Moving the existing catalog was harder than building the new pipeline. Cloudflare had tried once before and rolled back: regenerated files didn't byte-match what KV had been serving, and for a CDN where users pin SRI hashes in their HTML, that's a serving break. So this time the team copied existing content from KV to R2 as-is instead of regenerating it.

That exposed two hard platform ceilings. Workers capped subrequests at 1,000 per invocation on paid plans, and Workflows capped steps at 1,024 per run. A package with thousands of files would blow through either in one pass. Rather than just working around the limits, Cloudflare's cdnjs team asked the Workers and Workflows teams to raise them — and they did. Subrequests now go up to 10 million on paid plans; Workflows now default to 10,000 steps, configurable to 25,000.

"Limits we hit are limits we lifted for everyone," Cloudflare wrote. "If the Cloudflare Developer Platform can serve 9 billion requests a day and publish packages with hundreds of thousands of compressed, minified files, it can probably run whatever you're building."

Why a `<script>` CDN still matters in 2026

One reason cdnjs still sees 9 billion daily requests: LLMs love it. When ChatGPT, Claude, or Cursor scaffold a quick HTML demo, they reach for cdnjs because their training data is full of it — fifteen years of blog posts, READMEs, and tutorials pointing at the same URL pattern. Versions are immutable, so a model can emit a dependency reliably without hallucinating.

Supply-chain concerns cut the other way too. Every file on cdnjs carries an SRI hash, mirrors are auditable, and the whole project is open source. In an era of escalating dependency attacks, an immutable, hash-verified mirror of well-known libraries is a defense in depth.

Cloudflare is also mulling the next step: serving modern browser-native ES modules from cdnjs, so the same packages could be imported without a bundler. The Workflows-plus-Containers pattern that pre-compresses files today would work for transforming them. The company isn't committing to it — but it notes the option didn't exist a year ago.

What it means for edge computing

The cdnjs migration is a dogfooding exercise with real signal for the cloud industry. Cloudflare took one of the busiest free CDNs on earth, moved its serving AND publishing infrastructure onto an edge platform, and used the exercise to raise platform limits that benefit every developer on the service. It's also a reminder that "edge" is no longer just a caching layer — it's now running multi-step, durable, stateful pipelines that would previously have lived in a hyperscaler's region.

For companies weighing cloud migration in the other direction — pulling workloads back from central regions toward the edge — the cdnjs run is a useful benchmark. The platform handled 9 billion requests a day, a 98.6% cache hit rate, and a catalog of hundreds of thousands of files, and it did so with the same primitives any paying customer can use.

The move also says something about how Cloudflare sees its own roadmap: the company used its flagship free project to prove the Developer Platform can carry production workloads end to end, and it published the full engineering postmortem — including the limits it hit and the fixes it landed — as a template for anyone considering the same shift. That transparency is the difference between marketing and a real migration story.

cdnjs remains free, forever, for everyone. No API keys, no rate limits, no signup walls. In an internet increasingly full of paywalls and account gates, Cloudflare's decision to keep a 9-billion-requests-a-day infrastructure project open is worth protecting — and now it runs on the platform its host controls end to end.

Sources: Cloudflare blog — Dogfooding at scale: migrating cdnjs · Developers Digest — cdnjs Runs Entirely on Cloudflare's Developer Platform · Cloudflare on X

Fiber optic patch panel in a data center