Cloudflare CI/CD as Workflows: TypeScript Pipelines, Agent Self-Healing, and the End of YAML Fatigue

On August 4, the third day of its Agents Week, Cloudflare announced the CI SDK: a way to run continuous integration pipelines as Cloudflare Workflows, written in TypeScript instead of YAML, with each step executed in an isolated sandbox and an optional AI agent that heals failed runs. The pitch in the title is literal: "Run CI/CD for millions of repos, on your platform, on Cloudflare." The intended audience is not the individual developer running one pipeline, it is the platform builder running CI for hundreds of thousands of customer repositories.

The post is the build-and-test half of a larger story we covered this morning: Cloudflare's Agent Development Lifecycle. The CI SDK sits on top of Artifacts, Cloudflare's versioned code storage, and Workflows, its durable execution engine, and it turns the store-build-deploy path into one Workflow with a shared, cached environment across steps.

What shipped#

The CI SDK. @cloudflare/ci is a TypeScript library that maps a pipeline to a Workflow. A ci.runner() call runs a command in a sandbox; steps you return from it can be cached. The canonical example in the announcement runs bun install --frozen-lockfile once with a cache keyed on package.json and bun.lock, then fans out lint, test, typecheck, and build in parallel with Promise.all, and finally deploys with bun wrangler deploy using credentials passed through the Workflow.

Because each step runs in its own sandbox with the install step's snapshot restored, dependency caching means the lint, test, and build steps do not reinstall anything. The snapshot is stored in an R2 bucket on your account. Retries and timeouts come from Workflows' durable execution, and a failed step can be restarted from that step without rerunning the pipeline.

Artifact push triggers. Previously, wiring CI to a push meant setting up an event subscription, a Queue, a consumer, and a handler. The new events field on the Workflow trigger targets a Workflow instance directly: an artifact push fires cf.artifacts.repo.pushed, and a filter can scope it to one repo or an entire namespace. Omit repoName and the same workflow runs on every push to every repo in the namespace, which is the platform-owned CI case: write the pipeline once, share it across all customer applications.

Self-healing CI. The flagship example is a Healer agent that extends Cloudflare's HealingAgent class, wraps pipeline steps in try/catch, and on a CiRunnerFailure calls healer.heal() with the enriched failure and a prompt like "Fix every observed failure without weakening validation." The agent works in a container alongside the CI steps, makes the fix on a branch, and reports the branch, commit, and step count. You merge the commit instead of babysitting the pipeline. The example model is Kimi K2.7 Code via Workers AI, but the harness accepts any model.

Inherited Workflows guarantees. Every CI run is a Workflow instance, which means the existing dashboard shows step-by-step inputs, outputs, wall and CPU time, plus a visualizer for concurrent versus sequential steps. Logs go to Workers Observability and are queryable via GraphQL. Because a Workflow step is arbitrary code, a pipeline can do anything a Worker can: write build artifacts to R2, email on failure, or dispatch a code review agent mid-pipeline.

Why it matters to developers#

The headline is the audience: this is aimed at platforms, not at the solo developer happy with GitHub Actions. If you run a vibe-coding product, an internal platform, or a customization-through-code extension of your customer product, the pitch is that your CI becomes a Cloudflare Workflow you own, written in TypeScript rather than YAML.

The YAML point matters more than it sounds. GitHub Actions workflows are the most common YAML CI on earth, but they are also the least testable: a syntax error surfaces at runtime, conditional expressions are stringly typed, and reusing logic across jobs means copying blocks. The CI SDK's translation is direct, each step becomes step.do() with ordinary TypeScript control flow. Typechecking a pipeline file is the same as typechecking the code it builds. Our piece on workflows as code state machines made the same argument about orchestration generally: when the pipeline is real code, the editor, the linter, and the typechecker all participate.

The self-healing agent is the interesting escalation, because it reframes what CI failure means. A failed build is not a notification anymore, it is an input to an agent that has the failing command's output, the repo state, and permission to push a fix branch. That is a different contract than "agent suggests a diff in a comment." Cloudflare's own Astro dogfooding post, published the same day, reports driving a repository's open issue count to zero with this kind of automated triage, and our review-queue analysis noted that agent-authored fixes only scale when the pipeline itself can route them.

Two constraints keep this honest. First, it is not a migration path from GitHub Actions: there is no YAML importer, and the SDK's value comes from writing pipelines in TypeScript from the start. Second, the artifact-push trigger is Artifacts-first today; push events from GitHub and other version control systems are listed as coming next, not available now. The "millions of repos" framing assumes the repos live in Artifacts, which means the full store-build-deploy loop is the offer, not a standalone CI replacement.

How it fits with adjacent tools#

Cloudflare is assembling the platform pieces in sequence: Artifacts for storage, Sandboxes for isolated execution, Workflows for durable orchestration, Containers for the heavier step runtimes, and now the CI SDK on top. The trajectory is the same one Cloudflare Computer previewed for agent runtimes: give the agent, or the pipeline, a first-class execution environment with retries, observability, and credentials, and the surrounding infrastructure stops being the bottleneck.

For teams that already run on Cloudflare Workers, the appeal is consolidation: deploy previews on push to non-default branches and production on push to main are listed as coming next, alongside gradual percentage-based rollouts and monorepo support. For teams that do not, the calculus is the usual platform bet, they are betting that durable execution plus sandboxes plus code storage beats the incumbent CI incumbents, and that TypeScript pipelines are enough of a win to justify leaving YAML behind.

Continue Reading#

• Cloudflare's Agent Development Lifecycle - the umbrella post this CI SDK fits under, with the seven platform requirements
• Cloudflare Computer: agent runtime preview - where Cloudflare's sandboxed execution model is heading
• Agent workflows as code state machines - why treating orchestration as real code beats YAML pipelines
• AI coding agents need review queues - how agent-authored fixes get reviewed at scale, the pipeline's job after healing
• Vercel AI Gateway spend budgets - the cost-control side of running agent-heavy pipelines in production

Sources#

• Run CI/CD for millions of repos, on your platform, on Cloudflare - Cloudflare Blog
• The CI SDK - github.com/cloudflare/ci
• The Agent Development Lifecycle has arrived on Cloudflare - Cloudflare Blog
• Cloudflare Computer: your agent needs a computer - Cloudflare Blog
• How we built a software factory to drive Astro's GitHub issue count to zero - Cloudflare Blog