Cloudflare 已将 cdnjs 完整迁移到其开发者平台，用 Workers、R2、Workflows、Queues、Durable Objects、KV 和 Containers 替换了分布在 Cloudflare 与 Google Cloud Platform 上的发布基础设施。迁移还将 R2 设置为已发布包文件的权威来源，同时保留了现有的 URL、包内容和子资源完整性（SRI）哈希。
Cloudflare 表示，cdnjs 当前大约每天处理 90 亿次请求，平均在超过 330 个 Cloudflare 数据中心中每秒约 108,000 次请求，缓存命中率为 98.6%，约 12% 的网站使用 cdnjs。Cloudflare 将此次迁移描述为在广泛使用的公共服务规模上对其开发者平台进行内部验证（dogfooding）的示例。
此次迁移基于 2020 年的一次架构调整，当时 Cloudflare 将 cdnjs 的文件服务迁移到 Workers 和 Workers KV，在常规流量下替代专用源服务器，同时保留外部源作为回退方案，并引入预压缩的 Brotli 和 gzip 资源提高传输效率。但发布路径一直保持分散：Google Cloud Functions 定期检查 npm 获取发布包、Google Cloud Storage 存储包、Pub/Sub 负责消息传递，另有一台运行 git-sync 的虚拟机同步仓库内容，系统使用 26 个按字母分片的 Cloud Functions 监控包更新。
新架构以 Cloudflare R2 作为已发布文件的权威来源，KV 存储包的元数据、版本和 SRI 哈希，Worker 负责请求处理，Workers Cache 提供缓存层；若 R2 无法提供文件，已发布内容还会镜像到 DigitalOcean Spaces 作为回退。包摄取由 Cloudflare Workflows 编排，定时工作流检查 npm 和 GitHub 发布、将包下载到 R2 并为单个文件启动处理工作流，流水线提取内容、压缩存储结果、更新 KV 元数据并刷新 Algolia 搜索索引，工作流状态支持失败后从上次完成步骤恢复。
由于现有压缩算法需将整个库缓冲到内存，Cloudflare 使用 Containers 完成压缩工作，并表示正在探索流式支持，未来可能迁移到 Workers。保持包字节不变至关重要，因为混淆或压缩的更改可能改变 SRI 哈希。迁移还暴露了平台限制，促使 Cloudflare 将 Worker 子请求限制从 1,000 提高到 1,000 万，并将 Workflow 步骤从 1,024 提升到 10,000，可配置上限为 25,000。