Cloudflareは、JavaScriptおよびCSSライブラリ向けのオープンソースCDNであるcdnjsを、自社のDeveloper Platformへ完全に移行した。これにより、これまでCloudflareとGoogle Cloud Platformに分散していた公開インフラは、Workers、R2、Workflows、Queues、Durable Objects、KV、Containersへ置き換えられた。この移行では、公開済みパッケージファイルの単一の正確な情報源（source of truth）としてR2を採用するとともに、既存のURL、パッケージの内容、Subresource Integrity（SRI）ハッシュはそのまま維持された。
Cloudflareは、cdnjsが現在、1日あたり約90億件のリクエストを処理しており、330か所を超えるCloudflareのデータセンター全体で平均毎秒10万8,000件のリクエストを処理していると述べた。cdnjsが現在1日あたり約90億件のリクエストを処理しており、330カ所を超えるCloudflareのデータセンター全体で平均毎秒10万8,000件のリクエストを処理していると述べている。また、このサービスのキャッシュヒット率は98.6％で、約12％のWebサイトで利用されているという。Cloudflareは今回の移行について、広く利用される公開サービスの規模でDeveloper Platformを実運用する「ドッグフーディング」の事例だと説明している。
この移行は、Cloudflareが2020年のアーキテクチャ変更でcdnjsのファイル配信をWorkersおよびWorkers KVへ移行した取り組みを発展させるものだ。当時は、通常トラフィック向けの専用オリジンサーバーを置き換える一方で、フォールバックとして外部オリジンを維持していた。またCloudflareは、配信効率を向上させるために、事前圧縮済みのBrotliおよびgzipアセットも導入していた。
しかし、パッケージ公開の処理経路については分散されたままだった。Google Cloud Functionsが定期的にnpmのパッケージリリースを確認し、Google Cloud Storageがパッケージを保存し、Pub/Subがメッセージングを処理していた。また、git-syncを実行する仮想マシンがリポジトリの内容を同期していた。このシステムでは、パッケージ更新を監視するために、アルファベットごとに分割された26個のCloud Functionsが使用されていた。同時に、GitHubリポジトリのGitパックファイル形式での保存容量は1.1TBを超える規模にまで増大しており、公開済みファイルはGitHubとKVの両方で管理されていた。
/filters:no_upscale()/news/2026/08/cloudflare-cdnjs-migration/en/resources/1cdjnprevious-1786326571811.jpeg)
以前の cdnjs の公開および配信アーキテクチャ（出典：Cloudflareブログ記事）
新しいアーキテクチャでは、公開済みファイルの単一の正確な情報源（source of truth）としてCloudflare R2が採用されている。KVにはパッケージのメタデータ、バージョン情報、SRI（Subresource Integrity）ハッシュが保存され、Workerがリクエスト処理を担う。また、Workers Cacheがキャッシュレイヤーとして機能する。さらに、公開コンテンツはR2がファイルを配信できない場合に備え、フォールバック先としてDigitalOcean Spacesにもミラーリングされている。
パッケージの取り込みは、現在Cloudflare Workflowsによってオーケストレーションされている。スケジュール実行されるワークフローがnpmやGitHubのリリースを確認し、パッケージを取得してR2へ格納した後、個々のファイルを処理するワークフローを起動する。処理パイプラインでは、パッケージ内容の展開、アセットの minify（不要部分の削減）と圧縮、生成されたファイルのR2への保存、KV内のメタデータ更新、さらにAlgolia検索インデックスの更新が行われる。また、ワークフローの状態が保持されるため、障害発生時には最後に完了したステップから処理を再開できる。
/filters:no_upscale()/news/2026/08/cloudflare-cdnjs-migration/en/resources/1cdjn-new-1786326571811.jpeg)
R2、Workers、KV、Workflowsを利用した新しいcdnjsアーキテクチャ。（出典：Cloudflareブログ記事）
Copilot said:
圧縮処理は制約の一つだった。既存の処理アルゴリズムでは、ライブラリ全体をメモリ上にバッファリングする必要があるためだ。そのためCloudflareは、処理を直接Workers上で実行するのではなく、圧縮処理にContainersを利用している。Cloudflareは、将来的にはこの処理をWorkersへ移行できるようになる可能性があるとして、ストリーミング処理のサポートを検討していると述べている。
SRIハッシュが変更される可能性があるため、パッケージのバイト列をそのまま保持することは極めて重要だった。というのも、最小化（minify）や圧縮処理の内容が変わると、SRIハッシュも変化してしまう可能性があるためだ。また、この移行によってプラットフォームの制限も明らかになり、CloudflareはWorkerのサブリクエスト数上限を1,000件から1,000万件へ、Workflowのステップ数上限を1,024から10,000へ引き上げた。さらに、設定によっては最大25,000ステップまで利用できるようになった。結果として、新しいアーキテクチャでは、R2を成果物保存に、KVをメタデータ管理に、Workersをコンテンツ配信に、そしてWorkflowsを公開処理に利用している。