Serving 9 billion daily requests entirely on Cloudflare Workers

The Surprising Relevance of a Legacy CDN

AI coding assistants are single-handedly keeping legacy script tags alive. When ChatGPT, Claude, or Cursor scaffolds a quick HTML prototype, they almost always reach for cdnjs. They do this because their training data is completely saturated with it. For fifteen years, thousands of blog posts, README files, and Stack Overflow answers have pointed to those exact URLs. But more importantly, the URL pattern is consistent. The file versions are immutable. It is exactly the kind of dependency a large language model can output reliably without hallucinating a broken import path.

That is why a legacy script-tag content delivery network is still serving nine billion requests a day in the era of modern bundlers like Vite and Turbopack. It accounts for almost half of the entire JavaScript CDN market. And until recently, keeping it online was a massive operational headache.

Picture trying to debug a broken deployment pipeline where half your logs are in Google Cloud, and the other half are in Cloudflare. There is no shared correlation ID. Your ingestion pipeline is a chain of twenty-six different Cloud Functions, one for each letter of the alphabet, passing state through object storage events. A package version processes cleanly, writes to edge storage, and then silently fails to land in your actual source of truth. And that source of truth? A 1.1 terabyte GitHub repository that has grown so massive, GitHub's own archive service refuses to let you download it. You have split-brain storage. You have partial failures. And you have no way to alert on the drift because nothing in the system knows the full pipeline state. That was the legacy publishing pipeline for cdnjs.

A Masterclass in Edge Orchestration

Cloudflare recently decided to eat their own cooking and migrate this entire 9-billion-request-a-day machine exclusively onto their own Developer Platform. The result is a masterclass in how to orchestrate long-running, CPU-heavy tasks when standard serverless functions hit a wall.

Standard serverless workers are built for fast, short-lived HTTP requests. They fall apart when you need to run a multi-step pipeline over hours. They really fall apart when you need to fetch large package tarballs and run intense file compression. Cloudflare's platform has strict compute and V8 isolate limits on workers. You cannot run a heavy Rust minification routine directly inside a standard worker without hitting a wall.

So how do you handle heavy CPU tasks like compression under those constraints? You build an asynchronous handoff. Cloudflare replaced the twenty-six Google Cloud functions with Cloudflare Workflows. Every ten minutes, a cron job triggers a parent workflow. It checks npm and GitHub for updates. When it finds a new version, it spawns a child workflow to download the tarball into an R2 storage bucket. Then it spawns a processing workflow for every single file. This workflow extracts the file, and then it reaches the CPU limit.

This is where the handoff happens. The workflow writes the uncompressed file to an R2 bucket. It drops a job message onto a Cloudflare Queue. And then it actively hibernates. It stops running. Over in a Cloudflare Container, a Rust compression service picks the job off the queue. The container has the sustained CPU resources to crush the file down. It minifies the file, compresses it, and writes the finished result to a second R2 bucket. The moment that file hits the second bucket, an R2 event notification fires. That notification wakes the hibernating workflow back up so it can complete the final publishing steps.

Solving the Fan-In, Fan-Out Problem

Because Workflows provide durable execution, the state of each step is preserved. If a network timeout happens during the download, the workflow resumes from the exact last successful step. But this design introduces a massive orchestration problem. How do you manage fan-in and fan-out state when processing thousands of files per package concurrently? A large npm package might have ten thousand individual files. The parent workflow needs to wait for all ten thousand child processing workflows to finish before it can safely publish the package and update the search index.

You cannot manage that state in memory. You cannot hold open ten thousand network requests. Cloudflare solved this by deploying a small Durable Object as a parallel execution counter. It acts entirely as a stateful fan-in and fan-out coordinator. Every time the parent workflow spawns a child, it increments the counter on the Durable Object. Every time a child workflow finishes its compression cycle and wakes back up, it pings the Durable Object to decrement the counter. The parent workflow simply waits and wakes up when that counter reaches zero.

The storage layer was completely rebuilt to support this. They abandoned the split-brain GitHub repository. Now, R2 is the single source of truth for all file content. R2 has no practical size limits, so massive source maps and font packs that previously caused issues now live natively alongside everything else. Workers KV is still used, but strictly for metadata. Things like package info, version lists, and Subresource Integrity hashes. KV is optimized for high read volume and infrequent writes, which fits metadata perfectly.

The Reality Check of Vendor Lock-In

This architecture is a staggering technical achievement. It proves you can run massive, asynchronous, multi-step pipelines entirely at the edge. But it also requires a reality check regarding vendor lock-in. Cloudflare claims this migration resulted in fewer moving parts. Look closely at the topology. They replaced a Google Cloud and GitHub pipeline with:

• Workers
• Workflows
• R2
• KV
• Queues
• Containers
• Durable Objects

The system is not less complex. The moving parts just live entirely under a single vendor's control plane now. Relying heavily on Durable Objects as concurrency counters and using specific Queue implementations tightly couples your application logic to Cloudflare's proprietary abstractions. You are trading architectural portability for managed scale.

And testing this end-to-end is incredibly difficult. Simulating the interaction between hibernating Workflows, R2 bucket events, external Containers, and stateful Durable Objects locally is notoriously fragile.

Navigating Hidden Hurdles and Platform Limits

There is also a significant blind spot in this architecture around error handling across the compute boundaries. Handing off a job to a Rust container is brilliant for bypassing worker limits, but the engineering details skip over how an out-of-memory failure in that container is handled. If the external container crashes before writing the compressed file to the second R2 bucket, the R2 event notification never fires. Dealing with timeouts bubbling back up to a hibernating workflow across that Worker-to-Container boundary is a complex failure mode you have to account for.

Then there is the reality of platform limits. During this migration, Cloudflare initially planned to re-process all the old legacy packages and write the new results directly to R2. They had to roll that attempt back. File minifiers and compressors are not fully deterministic across versions. Processing old files with modern tools generated correct code, but the new outputs had slightly different Subresource Integrity hashes. Because millions of websites pin those hashes in their HTML script tags, changing them would break existing sites across the internet. So they were forced to orchestrate a massive, exact copy of millions of files between accounts instead.

That forced copying effort slammed them directly into hard platform limits. They hit a ceiling of one thousand subrequests per worker invocation. A package with thousands of files burned through that in one go. They also hit a limit of 1,024 steps per Workflow. Their solution was walking down the hall and asking the internal platform teams to raise the limits. Subrequests were bumped to ten million on paid plans. Workflows were raised to a default of ten thousand steps, configurable to twenty-five thousand. That is a luxury exclusive to internal dogfooding. When external customers hit arbitrary platform limits, they usually have to re-architect their systems or shard their workloads via message queues while waiting months for feature requests to be approved.

The Blueprint and the Tradeoff

We also do not know what this architecture would cost an enterprise customer. Running nine billion daily requests and durable workflows with thousands of parallel container executions obscures the financial reality of the platform, because Cloudflare is naturally eating the cost for a free public good.

What this migration reveals is exactly what it takes to orchestrate complex state at the edge. If you are building globally distributed applications where latency is paramount, this is the blueprint. You can wire together serverless storage, state, and compute to replace massive legacy monoliths. You can hand off CPU-heavy work to containers and use Durable Objects to tally the concurrent results. You just need to understand the tradeoff. You are fully committing to one vendor's way of doing things. You aren't just writing code. You are learning a highly specific set of abstractions for distributed systems. If you are willing to accept the lock-in, the scale is unmatched.

This is TAKEYOURPILLS.TECH. Go ship something.