Cloudflare’s Developer Platform absorbed one of the Internet’s busiest open-source CDNs on June 23, 2026, as the Cloudflare engineering team documented in their migration post. cdnjs — which serves a free, immutable mirror of every popular JavaScript and CSS library — completed its migration from a hybrid GCP-Cloudflare architecture to running entirely on Cloudflare’s own building blocks: Workers, Workflows, D1, Queues, R2, KV, and Containers. The scale is not theoretical: 9 billion requests per day, 108,000 requests per second, a 98.6% cache hit rate across more than 330 data centers, as reported by Cloudflare’s blog and corroborated by W3Techs usage data. For a project that underwrites a significant portion of introductory JavaScript tutorials, CodePen demos, and Stack Overflow answers, that operational reality is the baseline.
The migration is not a simple lift-and-shift. It represents a deliberate architectural decision by cdnjs maintainers Ryan Kirkman and Thomas Davis to consolidate a pipeline that had been duct-taped across two cloud providers for six years. Understanding why they made that choice, and what they gained and lost, offers a concrete case study for any engineering team running infrastructure at the intersection of open-source stewardship and commercial-scale delivery, as detailed in the Cloudflare blog post.
The architecture cdnjs left behind
The previous setup split responsibilities across GCP and Cloudflare in ways that made operational visibility nearly impossible. On the serving side, Cloudflare Workers and KV handled edge delivery with a bare-metal origin fallback. That part worked well — 98% cache hit, billions of requests, no outages. But the publishing side, the pipeline that watches npm and GitHub for new library versions, downloads them, processes them, and writes the results so cdnjs can serve them, remained entirely on Google Cloud Platform, as described in the migration post.
That publishing pipeline was a chain of 26 Cloud Functions — one per letter of the alphabet — each doing one step and handing off to the next through shared storage. A single package update would trigger a GCS object event, which fired the next function, which unpacked the archive and wrote results somewhere else, triggering the next, and so on. Storage was doing double duty as a message queue, with no dead-letter queue, no backlog visibility, and no clean replay when a step failed.
The observability gap was the most painful problem. A single package update could pass through Cloud Functions, GCS object events, Pub/Sub topics, a git-sync VM, and Workers KV before a file reached a user. None of those systems shared a correlation ID. GCP Logging held one half of the story, Cloudflare Logpush held the other, and the two had no common key to join on. The problem was not outright failure — it was partial success. A version that processed cleanly, wrote to KV, and then silently failed to land in the GitHub repo would serve fine for weeks until someone noticed the two stores had diverged. There was no alert for that, because nothing in the system knew the full pipeline state.
The GitHub repository itself had become a liability. Years of releases pushed it past 1.1TB of packed storage, large enough that GitHub’s own archive service refused to generate tarballs or zip downloads. Forking became impractical, clones were slow, and the .gitignore had grown to 274 hand-curated entries blocking broken or weirdly-versioned releases.
What the Developer Platform changed
Moving the entire pipeline onto Cloudflare’s Developer Platform meant consolidating observability, eliminating the split-brain storage problem, and replacing the event-driven function chain with Workflows and Queues. The new architecture uses Workers for edge logic, Workflows for orchestrating the multi-step ingestion pipeline, D1 for structured metadata, R2 for object storage, and Queues for reliable message passing between pipeline stages, as Cloudflare’s engineering team explained. Cloudflare’s Developer Platform documentation describes these primitives as the foundation for building full-stack applications on a single global network.
The most immediate operational improvement is traceability. Because the entire pipeline now runs on a single platform, a correlation ID can follow a package from ingestion through processing to edge delivery, as Cloudflare’s engineering team documented. When something goes wrong — and at 9 billion requests per day, something will — the operations team can see the full lifecycle in one place rather than stitching logs together from two unrelated cloud providers.
The Developer Platform also provided primitives that did not exist when cdnjs first migrated to Cloudflare in 2020. Workflows, Queues, Durable Objects, R2, and Containers were not available then. The original architecture was built on what was possible at the time — a chain of GCP Functions with a git-sync VM — and it served the project well for six years. But as the platform matured, the mismatch between what cdnjs needed and what the hybrid architecture could support became the primary constraint on shipping velocity.
What this means for open-source infrastructure operators
The cdnjs migration matters beyond one project’s technical debt payoff. It demonstrates that open-source infrastructure projects can run entirely on a commercial cloud platform’s native tooling without sacrificing independence. cdnjs remains free, open-source, and community-driven. The fact that it now runs on Cloudflare’s Developer Platform does not make Cloudflare a gatekeeper — it makes Cloudflare’s primitives the substrate on which a community project operates, which is a fundamentally different relationship than hosting or sponsorship.
For engineering teams evaluating whether to consolidate infrastructure onto a single platform, the cdnjs case offers a data point. The migration was motivated not by cost or performance — the previous architecture was not slow — but by the operational tax of maintaining a hybrid setup. When the publishing pipeline requires 26 separate functions, each with its own deployment and logs, and the serving layer lives on a different provider with a different observability model, the engineering cost of keeping both systems healthy eventually exceeds the cost of consolidation.
The tradeoff is vendor concentration. Running cdnjs entirely on Cloudflare’s Developer Platform means the project’s infrastructure is now tied to a single vendor’s platform roadmap, pricing changes, and outage profile. Cloudflare has been a good steward of the cdnjs project — hosting it free of charge since 2011 and taking over maintenance in 2019 — but the dependency is real. For a project that serves as the JavaScript CDN backbone for roughly 12% of all websites, that concentration warrants attention from the broader community. W3Techs data confirms that CDNJS holds a 48.3% share of the JavaScript CDN market and is used by 11.6% of all websites, underscoring how much of the web depends on this single infrastructure choice.
The platform feedback loop
The migration also pushed Cloudflare’s own platform limits. cdnjs surfaced constraints in the Developer Platform during the move, and Cloudflare grew to meet them. This is the dogfooding dynamic at work: an internal project stress-tests the platform, finds the gaps, and the platform evolves to close them. The result is a stronger CDN infrastructure for everyone, not just cdnjs users.
For readers who depend on cdnjs — whether as a <script> tag in a tutorial, a dependency in a build pipeline, or a reference in documentation — the migration should be invisible. The URL cdnjs.cloudflare.com stays the same. The SRI hashes remain verifiable. The free, no-sign-up, no-rate-limit delivery model continues unchanged. What changed is the plumbing underneath, and that change is worth understanding because it illustrates how open-source infrastructure projects can leverage commercial platforms without becoming captive to them.
This pattern echoes what happens when other open infrastructure projects choose commercial developer platforms. When MoneyGram joined the Solana Developer Platform as a validator, it demonstrated the same dynamic: a community-facing project adopting a commercial platform’s primitives to gain scalability, while the platform gains real-world usage data to refine its offerings. The cdnjs migration is a parallel case in the CDN infrastructure layer, and the zBrandco article on MoneyGram’s Solana validator role explores this trend further.
Practical takeaways for infrastructure teams
The cdnjs case offers three actionable lessons for teams running infrastructure at scale, as Cloudflare’s engineering team documented. First, hybrid architectures accumulate operational debt faster than either provider alone. When serving and publishing live on different platforms with different observability models, the integration cost eventually exceeds the cost of consolidation. Second, platform primitives mature — Workflows, Queues, Durable Objects, R2, and Containers were not available when cdnjs first moved to Cloudflare in 2020, but they are now the foundation of a project serving 9 billion requests daily. Third, vendor concentration is a real tradeoff, not a hypothetical one. The cdnjs project accepted it deliberately, and the community should monitor it.
For teams considering a similar consolidation, the cdnjs migration timeline and the specific pain points it resolved — split-brain storage, missing correlation IDs, unobservable partial successes — provide a concrete checklist of what to audit before committing to a single-platform strategy. Cloudflare’s post-quantum authentication rollout to origin servers, covered in the zBrandco article on that development, shows how the same platform continues to layer security primitives onto the infrastructure that now hosts cdnjs, reinforcing the value of consolidating on a single provider’s tooling when the primitives are mature enough. The practical takeaway is that platform consolidation should be driven by operational necessity, not by vendor marketing.
