Run CI/CD for millions of repos — on your platform, on Cloudflare

From code push to production, without the pipeline plumbing

Cloudflare has stitched its code storage, build and deploy offerings together with the CI SDK, built on Cloudflare Workflows. The result: teams can run CI/CD pipelines entirely on Cloudflare’s developer platform. An artifact push event can trigger a Workflow instance directly — effectively a CI job — through a new events field in the wrangler configuration file, eliminating the need to assemble event subscriptions, queues and queue consumers by hand.

With the @cloudflare/ci package installed, a Workflow can automate builds from an Artifacts repo in an isolated sandbox, run linters and typechecks, cache dependencies across steps, execute unit tests, invoke an AI agent to repair broken builds, and deploy conditionally only when checks pass.

Treating the pipeline as code, not YAML

Platform builders increasingly store code for millions of repositories — their own and their customers’ — on Artifacts. Each of those teams has different CI/CD needs. A platform may want to manage builds for its customers, writing the pipeline once and sharing it across all applications. Some customers may prefer to define their own CI jobs through dynamic workflows. Both can coexist in the same namespace, with platform-managed and custom pipelines running simultaneously.

A CI/CD pipeline is fundamentally a series of ordered steps that halt on failure and report the error — in other words, a Workflow. Where YAML-based pipeline definitions quickly become unwieldy, the CI SDK lets you express each step as a Workflow step.do() call in TypeScript, offering more control and easier configuration.

Previously, running sandboxed commands required calling the Sandbox API directly and managing state between steps. The CI SDK moves that responsibility into Workflows, which provide built-in retries and timeouts per step. Dependency caching lets you run an install step once and reuse the result across all subsequent steps, cutting down the latency of each CI run.

Defining a CI job with the SDK requires three pieces:

1. An install step that fetches external dependencies such as bundlers (e.g. esbuild), linters (e.g. eslint) or test runners (e.g. vitest).
2. Commands for each job step (e.g. bun run build, bun run test, bun run lint), which execute in parallel once dependencies are cached.
3. A deploy step running wrangler deploy, so a Worker ships automatically when the pipeline succeeds.

The flexibility of code means a CI Workflow can call out to an agent for self-healing: if a build step errors, the agent can fix it and push a commit for approval. That example is available in the self-healing example in the CI SDK repository.

Building and triggering a CI Workflow

Start a CI Workflow with import { CIWorkflow } from @cloudflare/ci. The first step is install, which downloads dependencies and external tools, tracks changes via a lockfile, and caches the sandbox state as a snapshot in R2 for reuse by subsequent steps.

Each subsequent step runs in its own isolated sandbox. Workflow steps start concurrently by default, reducing total run latency. To ensure all checks finish before deployment begins — for example, completing build, lint, test and typecheck first — wrap them in a Promise.all().

const deps: CiRunnerResult = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});

await Promise.all([
  deps.runner({ name: 'lint', command: 'bun run lint' }),
  deps.runner({ name: 'test', command: 'bun run test' }),
  deps.runner({ name: 'typecheck', command: 'bun run typecheck' }),
  deps.runner({ name: 'build', command: 'bun run build' }),
]);

await deps.runner({
  name: 'deploy',
  command: 'bun wrangler deploy',
  cloudflareCredentials: {
    accountId: this.env.CLOUDFLARE_DEPLOY_ACCOUNT_ID,
  },
});

Triggering the Workflow happens declaratively: add an events field to the Worker’s wrangler configuration under triggers, alongside the Workflow and Artifact bindings. When an artifact push event fires — specifically a cf.artifacts.repo.pushed event — the specified Workflow instance starts automatically. Each CI run appears as a Workflow instance, viewable step-by-step in the Workflows dashboard. This integration is Artifacts-first; future types will support events from other Cloudflare services.

For platforms running CI across every repository in a namespace, omit repoName and specify only the namespace in the filter field. The full configuration requires bindings for artifacts, workflows, containers and durable_objects (plus exports config) for sandbox access, along with an r2 binding when cache is enabled — the install snapshot lives in an R2 bucket.

Adding self-healing with an agent

Self-healing CI needs an LLM and an agent harness. The reference implementation pairs a Think agent with Workers AI, catching errors in pipeline steps and running fixes automatically in the cloud. Adding a Durable Object binding for the Think agent wires it into the Workflow.

The agent — named Healer in the example — extends the HealingAgent class and provides a heal method to invoke on failure. Wrap pipeline steps in a try/catch block to call that method when something breaks.

const deps = await ci.runner({
  name: 'install',
  command: 'bun install --frozen-lockfile',
  cache: { inputs: ['package.json', 'bun.lock'] },
});

This pattern is just one instance of the broader Bring Your Own Workflow model, where CI jobs can incorporate security rules, filters or conditional steps per platform, team or application.

Why Workflows underpin CI/CD

Running CI on Cloudflare Workflows provides several operational advantages:

1. Resilient retries: Failed steps retry automatically with state intact, and each step supports custom retry and timeout policies. Restarting from a specific step means a lint failure doesn’t force a full pipeline rerun.
2. Observability: The Workflows dashboard exposes every instance’s steps with inputs, outputs, and wall and CPU time. Workflow diagrams visualize concurrency and sequencing, and logs flow into Workers Observability and GraphQL for deeper analysis.
3. Custom logic in code: step.do() can call any code, such as an AI code reviewer, write build artifacts to R2 or send notifications when CI fails or merges to main — whatever your pipeline requires.

Beyond the pipeline

At its core, a CI/CD pipeline is simply a Workflow. Cloudflare's CI SDK lets you define your continuous integration logic in TypeScript rather than rigid YAML, applying the same primitives to your own codebase and those of your customers. This flexibility opens up possibilities beyond traditional build steps — you can model a healing agent that responds to failures or write build artifacts directly to R2.

Running CI on Workflows connects storage, builds, and deployments into one cohesive platform. That integration makes it straightforward to manage every stage of the pipeline, whether you are operating on your own repositories or handling builds on behalf of platform users.

Access to the Artifacts private beta is available via request form, and the Workflows CI guide covers getting started. For bug reports and feature requests, the Cloudflare Developers community on Discord provides a direct line to the team.

On the roadmap

Several enhancements are in development for the CI/CD offering:

• Direct Worker integrations: build.preview() and build.deploy() primitives will enable automatic deploy-on-push to the main branch and preview builds for non-default branches.
• Gradual deployments: Percentage-based rollouts managed via Workflows, giving you control over progression and rollback logic.
• Monorepo support: Simplified handling of multi-Worker deployments using a single CI pipeline.
• Flexible triggers: Push events from any version control system — not just Artifacts — to trigger CI jobs on a repository.