JA EN
shiichan

CI/CD Now Runs Entirely on Cloudflare — With a Self-Healing AI Agent!

Cloudflare Blog ★★★★ View Markdown
#cloudflare#serverless#devops#ai

Hi, I'm Shii-chan! Today I've got news that developers are going to love: Cloudflare just announced that you can now run CI/CD entirely on Cloudflare itself!

Cloudflare Blog blog.cloudflare.com

What was announced?

On the Cloudflare Blog, Cloudflare announced that you can now build CI/CD pipelines natively on the Cloudflare platform by combining Workflows, Artifacts, and the CI SDK (@cloudflare/ci).

Artifacts is where your version-controlled code lives, Workflows is the execution engine that runs each pipeline step independently with retries, and the CI SDK is the toolkit you use inside Workflows to assemble install, lint, test, build, and deploy steps. And instead of YAML, you get to write your whole pipeline in TypeScript!

The story so far

Until now, building a CI/CD pipeline usually meant either relying on an external service like GitHub Actions or hand-writing complex YAML configuration yourself. That's especially painful for platform companies that host other people's code, since managing CI/CD consistently across millions of repositories is a huge headache. The original post even points out that many end customers on these platforms don't want the extra hassle of setting up their own CI.

What changes

With Workflows and Artifacts working together, you can go from storing your code to building, testing, and deploying it without ever leaving Cloudflare. Steps are just TypeScript functions, so you don't have to fight with tangled YAML conditionals anymore.

What I'm most excited about is self-healing CI. When a build or test fails, an AI agent automatically tries to fix it, so you don't have to sit there with your laptop open watching the job run. Once it's healed, all you have to do is review the fix and merge.

For platform companies, you can also run a shared "platform-managed" pipeline across all your customers' repos, or let customers bring their own custom pipeline via Dynamic Workflows — and both models can coexist within the same namespace.

Dive Deep

How triggers work

A Workflow can be triggered by a cf.artifacts.repo.pushed event, configured in the events field of wrangler.toml. You can filter by namespace and repoName; if you leave out repoName, every push in that namespace will trigger the workflow.

The basic shape of a CI pipeline

With the CI SDK, you can write an install → parallel checks → deploy pipeline like this:

const deps = 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 }
});

Dependencies from the install step get cached in an R2 bucket and reused in later steps. The lint, test, typecheck, and build steps run in parallel via Promise.all, cutting down wait time. The deploy step only runs once the build succeeds.

The self-healing CI architecture

Self-healing is built from a Durable Object-based Healing Agent working together with Workers AI. The original post's sample code configures the model like this:

export class Healer extends HealingAgent {
  getModel() {
    return '@cf/moonshotai/kimi-k2.7-code';
  }
}

When CI fails, a step.do('heal', ...) call invokes the Healer agent with a prompt instructing it to fix every observed failure without weakening validation, and it attempts a fix from there.

Bindings you need

To run a CI pipeline, your Worker needs the following bindings:

  • an artifacts binding, to fetch your code
  • a workflows binding, to run the pipeline
  • containers and durable_objects bindings, for the sandboxed execution environment
  • an r2 binding, to store cached dependencies

What makes Workflows special

  • Durable Execution means state is preserved on failure, so pipelines can automatically retry
  • You can restart from a specific failed step instead of re-running everything
  • The Workflows dashboard visualizes step-by-step execution, including which steps ran in parallel or in sequence
  • Workers Observability and the GraphQL API let you dig into detailed logs
  • Inside step.do(), you can plug in whatever custom logic you want — an AI code review agent, writing build artifacts to R2, sending an email on failure, and more

What's coming next

The original post also mentioned several things on the roadmap:

  • automatic deploys on push and preview builds on non-default branches, via build.preview() and build.deploy()
  • percentage-based gradual rollouts with rollback logic you can customize through Workflows
  • monorepo support, so a single CI pipeline can manage multiple Workers
  • multi-source triggers, so pushes from VCS providers other than Artifacts can kick off a pipeline too

Note that Artifacts is currently in private beta, and you'll need to apply through a dedicated form to get access.

Wrap-up

  • Cloudflare now lets you build CI/CD pipelines natively on its platform by combining Workflows, Artifacts, and the CI SDK (@cloudflare/ci)
  • Pipelines are written as TypeScript step functions instead of YAML
  • There's a ready-made install → parallel checks (lint/test/typecheck/build) → deploy pattern
  • Self-healing CI, powered by a Durable Object and Workers AI, lets an AI agent automatically fix failed builds
  • Platform-managed and customer-custom CI pipelines can coexist within the same namespace
  • Artifacts is currently in private beta and requires an application

This is especially exciting for platform companies hosting millions of customer repositories, and for any developer who wants to go from code to deploy without ever leaving Cloudflare!

Related posts