Cloudflare Launches CI SDK to Run End-to-End CI/CD Pipelines on Workflows

Cloudflare Launches CI SDK to Run End-to-End CI/CD Pipelines on Workflows Cloudflare has released its CI SDK, enabling developers and platforms to run complete continuous integration and deployment pipelines using Cloudflare Workflows, Sandbox environments, and Artifacts storage. The new CI SDK (@cloudflare/ci) allows CI/CD pipelines to be written in TypeScript instead of YAML, executing each step inside isolated sandboxes. Pipelines trigger directly on artifact push events through a new events field in Wrangler, eliminating the need to configure queues and consumers manually. Workflow steps support parallel execution and dependency caching backed by Cloudflare R2 snapshots. Pipelines can integrate Workers AI and Think agents via Durable Objects to automatically diagnose and self-heal failed build steps. TypeScript-Defined Pipelines and Direct Event Triggers Instead of relying on rigid YAML configurations, developers can orchestrate continuous integration workflows using TypeScript with the @cloudflare/ci SDK on Cloudflare Workflows. Each step translates into a workflow execution step that benefits from built-in retries and timeouts. Workflows can now be initiated automatically upon repository pushes through a new events trigger configuration, which triggers execution instances whenever a push event occurs in Artifacts without requiring Cloudflare Queues or consumers. Sandboxed Isolation, Caching, and Parallel Execution Build, lint, and test steps run within safe, isolated environments powered by the Sandbox SDK. Developers can optimize pipeline latency by caching the results of dependency installations as sandbox snapshots stored in Cloudflare R2, preventing redundant installs across subsequent steps. Workflows also allow independent steps to execute concurrently using standard promises, ensuring checks like linting and unit testing run in parallel before final deployment. Multi-Tenant Platform Support and Self-Healing Agents The system supports platform operators running standardized CI across customer codebases or enabling custom customer-defined dynamic workflows in the same namespace. Additionally, developers can leverage Workers AI and Durable Objects to implement Think healing agents within try/catch blocks; these agents can inspect build failures, apply fixes, and open commits automatically without manual intervention.

Cloudflare 推出基于 Workflows 与 CI SDK 的全栈 CI/CD 解决方案 Cloudflare 发布了构建于 Cloudflare Workflows 之上的全新 CI SDK，旨在让开发者与平台服务商直接在其平台上完成代码存储、构建、测试与部署全流程，摆脱复杂的 YAML 配置与第三方队列编排。 结合 Artifacts 代码存储与 CI SDK，开发者可通过 TypeScript 直接编写 CI/CD 流水线，取代传统的 YAML 配置文件。 支持在 wrangler 配置中通过全新的 events 字段监听 artifact push 事件，省去配置队列及消费者步骤即可直接触发 Workflow 实例。 每个 CI 步骤运行于隔离的沙箱环境中，借助 R2 存储安装依赖快照实现跨步骤缓存与并行执行，并继承 Workflows 内置的重试与超时机制。 平台可利用该架构同时管理通用构建流与租户自定义流，并可集成 Workers AI 与 Think Agent 实现构建失败时的代码自愈与自动修复提交。 TypeScript 驱动的沙箱工作流 传统的 CI/CD 通常依赖 GitHub Actions 及复杂的 YAML 配置，而 Cloudflare 将流水线抽象为 Workflow 任务。通过 @cloudflare/ci 提供的 CIWorkflow，开发者可直接使用 TypeScript 编排步骤。每个构建、检查或测试步骤均通过 Sandbox SDK 在隔离安全的环境中运行，不仅免去了手动调用沙箱 API 管理状态的麻烦，还天然获得了 Cloudflare Workflows 的自动重试与超时控制。 事件触发与多租户平台支持 以往订阅 Artifacts 推送事件需要额外部署 Cloudflare Queues 及消费者处理程序，如今只需在 Worker 的 wrangler 配置中声明 events 字段，即可在 cf.artifacts.repo.pushed 触发时直接运行 Workflow。针对构建平台场景，团队可以在同一命名空间下同时运行平台托管的通用构建流程与客户自定义的 Dynamic Workflows，既能针对单个仓库触发，也能针对整个命名空间生效。 依赖缓存与 AI 驱动的自愈能力 该方案利用 R2 存储 install 步骤的沙箱快照，实现依赖缓存，使构建、代码检查（lint）与类型检查等步骤能够通过 Promise.all() 并行执行以降低整体延迟。此外，通过引入基于 Workers AI 的 Think Agent，CI 流水线可以在步骤失败时捕获异常并调用 AI 代理自动修复代码并提交，省去开发者手动排查故障的运维负担。

We are moving toward a world in which you can store, build, test, and deploy your code fully on Cloudflare. We built the first piece with [Artifacts](https://developers.cloudflare.com/artifacts/), versioned code storage that scales to millions of repos. We have stitched the store, build, and deploy steps together with the [CI SDK](https://github.com/cloudflare/ci), built on [Cloudflare Workflows](https://developers.cloudflare.com/workflows/), so that you can run your continuous integration (CI) pipeline on Cloudflare. You can send `artifact push` events directly to your Workflow, triggering an instance of its execution — a CI job, essentially — through a new `events` field in your wrangler configuration file. Then, directly from the Workflow with [@cloudflare/ci](https://www.npmjs.com/package/@cloudflare/ci) installed, you can: `install` once and cache dependencies across steps in the CI job Today, everyone is building a platform, whether it’s an internal vibe coding platform or an extension of your customer-facing product via customization through code. [Platforms are now using millions of repos on Artifacts](https://x.com/dillon_mulroy/status/2077508376217452866) to store their code, and their customers’ code, and version control across the two. But every team has their own needs for a continuous integration and deployment pipeline. For platforms, they might want to define a CI job for their own code differently from that of their customers. Many of the end customers building on these platforms don’t want the extra headache of managing their continuous integration and continuous deployment (CI/CD) pipeline. Instead, the platform can manage the build process on their customers’ behalf: write the CI/CD pipeline once and share it across all the applications that their customers are building. Some of the platform’s customers might want to define their own CI; if so, they can write their own Workflow and run custom CI jobs on just their repo, facilitated by [dynamic workflows](https://blog.cloudflare.com/dynamic-workflows/). The beauty is, you don’t have to pick and choose: both platform-managed and custom CI can run at the same time, in the same namespace. Before today, we had all the pieces to allow platforms to wire their CI/CD pipeline together on Cloudflare. Now, we’re bringing a better developer experience to make it simple. A CI/CD pipeline — commonly orchestrated with GitHub Actions — is a series of steps that run in a specific order where, if any step fails, you stop running the pipeline and report the error. In essence, a CI/CD pipeline is just a Workflow. CI/CD, when defined by a YAML file, can get complicated quickly, given the constraints that so often lead to YAML fatigue. But each step in a CI/CD pipeline can translate simply to a Workflow `step.do()`. Instead of YAML, you can define your CI/CD pipeline in Typescript for greater customization and configurability. We are launching new tools in the [CI SDK](https://github.com/cloudflare/ci) that allow you to run each step in your CI pipeline (e.g. `build`, `lint`, and `typecheck`) in a safe, isolated environment, built directly on Cloudflare’s developer platform via Workflows and the [Sandbox SDK](https://developers.cloudflare.com/sandbox/). Plus, you can now kick off a CI job directly on push instead of configuring an event subscription, a queue, and a queue consumer. Previously, you’d have to call the Sandbox API directly and manage state yourself across different steps in the CI pipeline. The SDK allows you to run each sandboxed command in its own Workflow step, providing the retries and timeouts built into Cloudflare Workflows. You can also speed up your CI pipeline by caching step results — for example, your install step — so that you don’t need to reinstall for all subsequent operations. Dependency caching reduces the latency of your CI/CD pipeline since every CI step won’t need to rerun the install. To define your CI job, all you need to do is: `bun run build`, `bun run test`, `bun run lint`). With your dependencies cached, each CI step can execute in parallel, reducing the latency of the overall run. `wrangler` `deploy` in a Writing your own CI pipeline in a Workflow allows you to customize as much as you want. For example, you could call an agent from your CI Workflow to give your CI jobs self-healing functionality: if a step in your build errors, the agent can fix it automatically, and push a commit for your approval. Try an example of self-healing CI Workflows with Project Think: [https://github.com/cloudflare/ci/blob/main/examples/self-healing](https://github.com/cloudflare/ci/blob/main/examples/self-healing) To write your own CI Workflow, get started with `import { CIWorkflow } from@cloudflare/ci`. Start with an `install` step: `vite`, `react`). Then define steps for the build and checks, each executed in its own safe, isolated sandbox environment. By default, each step in a Workflow starts independently, meaning the steps will execute concurrently unless otherwise specified. Running each step in parallel reduces the latency of your CI run. To ensure that all checks complete before the CI pipeline continues (for example, finish `build`, `lint`, `test`, and `typecheck` before the deploy step starts), wrap in a `Promise.all()`: Now, to actually trigger your CI Workflow, add an `events` field to your Worker’s wrangler configuration, alongside your Workflow and Artifact bindings. The `events` field is a new field supported within your `triggers` field. You could already subscribe to Artifacts through Cloudflare Queues [via event subscriptions](https://developers.cloudflare.com/artifacts/guides/event-subscriptions/) and kick off a build pipeline every time there’s a push event. But that requires setting up the event subscription, Queue, consumer, and queue handler. Now, you can target a Workflow with that event — every time that event fires, it will trigger an instance of the Workflow. Specify the CI Workflow as your `artifact push` trigger’s target to automatically trigger a Workflow instance on every `cf.artifacts.repo.pushed` event. Each CI run surfaces as a Workflow instance so you can view its step-by-step execution and observability directly in the Workflows dashboard. This is an Artifacts-first integration; coming soon, the `types` will support events from sources across your Cloudflare account to allow for programmatic consumption across the product suite. If you want to run the CI Workflow on every repo in your namespace — for example, if you are a platform running CI on all of your customers’ repositories — omit `repoName` and only specify the `namespace` in `filter`. To fully configure your CI Workflow, add bindings to each piece of the infrastructure which powers the pipeline: `artifacts`, `workflows`, `containers` and `durable_objects` (+ `exports` config) bindings (to access your sandboxes), plus an `r2` binding if you are using `cache`. The R2 binding is required as the snapshot of your `install` step sandbox is stored in a [bucket](https://developers.cloudflare.com/r2/buckets/). To allow your CI job to self-heal, you’ll need two pieces: the LLM and its agent harness. In the example above, we included a [Think agent](https://developers.cloudflare.com/agents/harnesses/think/) using [Workers AI](https://developers.cloudflare.com/workers-ai/) to catch errors in your pipeline and run the fixes on your behalf. Your CI job can be run and re-run remotely — no need to watch with your laptop open or check back every few minutes. Instead, Cloudflare handles it in the cloud, running your healer agent alongside the CI steps in a container. Instead of babysitting the CI job, making a manual fix, and re-running the pipeline, you’ll just need to merge the commit after your agent has made the fix. To set up an agent that self-heals your CI pipeline, add a Durable Object binding for your Think agent: Create your Think agent — `Healer` — by extending the `HealingAgent` class, which includes a `heal` method for you to call on failure. Pass whichever model you’d like to use: Then, wrap your steps in a `try/catch` block where a failure triggers the healing agent: This example demonstrates a self-healing CI pipeline, but really, the Bring Your Own Workflow model allows you to customize the CI job however you want. This can be a place to add security rules, filters, or conditional CI steps. Using the BYO-W model, platforms can configure their CI/CD pipelines across different teams, customers, or applications according to each individual use case. By running your CI pipeline on a Cloudflare Workflow, you automatically inherit: A CI/CD pipeline is just a Workflow — and with the CI SDK, you can define your CI across your code, and that of your customers, in simple Typescript rather than inflexible YAML. Building off the Cloudflare Workflows primitives, you can define whatever logic you’d like, whether that’s a healing agent, like our Think example, or writing build artifacts to R2. Running CI on Workflows helps bridge the gap between storage (via Artifacts), builds, and deployments. As a platform, this allows you to easily manage each step on your own code and on behalf of your customers. [Request to join](http://forms.gle/DwBoPRa3CWQ8ajFp7?cf_target_id=37346A378E06FC53CEE53925EE8AAF47) the Artifacts private beta and get started with our [Workflows CI guide](https://developers.cloudflare.com/artifacts/guides/build-and-deploy-on-push/). If you have any feature requests or notice any bugs, share your feedback directly with the Cloudflare team by joining the [Cloudflare Developers community on Discord](https://discord.cloudflare.com/). What’s coming next: `build.preview()` and `build.deploy()` primitives to automatically deploy on push to main and create previews on push to non-default branches