Cloudflare Ships an Open-Source CI SDK That Defines Pipelines in TypeScript on Workflows and Sandboxes

Overview

Cloudflare has released @cloudflare/ci, an open-source software development kit that lets developers define continuous integration and deployment pipelines in TypeScript rather than YAML, running each pipeline stage as a durable Cloudflare Workflow. The company announced the tool in a post titled “Run CI/CD for millions of repos — on your platform, on Cloudflare”, framing it as part of a broader push to let teams “store, build, test, and deploy” code “fully on Cloudflare.”

What We Know

The CI SDK sits on top of two existing Cloudflare products: Artifacts, described by Cloudflare as “versioned code storage that scales to millions of repos,” and Workflows, the orchestration engine that now runs the pipeline steps themselves, according to Cloudflare’s announcement. Pipelines are triggered by sending artifact push events to a Workflow through a new events field in a project’s wrangler configuration file, and Cloudflare summarizes the underlying design philosophy in a single line: “In essence, a CI/CD pipeline is just a Workflow,” the company wrote in the announcement.

The cloudflare/ci GitHub repository shipped its initial commit on August 4, 2026, and is licensed under Apache 2.0. Because pipeline steps run as retryable Workflow steps, the project’s README states that “runner commands execute inside retryable Workflow steps” and that “commands with external side effects must therefore be idempotent, as required by Cloudflare Workflows.” The README also flags a second limitation: CiRunnerResult.logs “contains raw command output and is not secret-redacted; only provider notification previews and failure messages are redacted,” according to the project README.

The package “targets Cloudflare Workers and publishes TypeScript source for Workers-aware bundlers such as Wrangler” rather than shipping as a standalone Node.js package, and Workers that import @cloudflare/ci/worker must enable the nodejs_compat compatibility flag, per the repository documentation. InfoQ reports that developers can use Promise.all() to run independent checks — linting, testing, type-checking, and building — concurrently before deployment stages.

The repository ships two example Workers: a basic install-check-deploy pipeline, and a self-healing variant that the project’s README calls an “application-owned Healing Agent that consumes the package’s neutral runner-failure diagnostics.” In its announcement, Cloudflare describes an example that included “a Think agent using Workers AI to catch errors in your pipeline and run the fixes on your behalf,” and says enabling self-healing requires “two pieces: the LLM and its agent harness,” according to Cloudflare. As the company put it: “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.” The README is explicit that this Healing Agent, along with “its tools, and its AI dependencies,” is example code and “not part of @cloudflare/ci” itself.

The initial integration works only with Cloudflare Artifacts as a source provider; InfoQ notes that Artifacts is currently in private beta. Cloudflare lists several features as not yet built, including build.preview() and build.deploy() primitives for automatic deployment on push, percentage-based gradual rollouts managed through Workflows, simplified monorepo support for multi-Worker deployments, and triggers that would let CI jobs run from version-control systems other than Artifacts, according to the announcement.

What We Don’t Know

Cloudflare has not published a numbered release or version tag for @cloudflare/ci — the GitHub repository currently has no tagged releases. Pricing, general-availability timing for the Artifacts source provider, and a public roadmap timeline for the still-unbuilt features listed above have not been disclosed.

Analysis

The release folds CI/CD into Cloudflare’s existing Workers ecosystem rather than treating it as a separate product: pipelines are Workflows, build steps run inside Cloudflare’s Sandbox containers, and the self-healing example is opt-in application code layered on top of a smaller, YAML-free core package. That positions @cloudflare/ci less as a direct GitHub Actions or GitLab CI replacement today — given its dependency on the still-private-beta Artifacts source provider — and more as an early building block for teams that already run application code on Workers and want their build pipeline to live in the same runtime and language.