cloudflareAug 4, 2026

Run CI/CD for millions of repos — on your platform, on Cloudflare (opens in new tab)

Cloudflare is bringing code storage, CI, and deployment together on its platform. Its CI SDK turns Cloudflare Workflows into TypeScript-defined pipelines that can build, test, and deploy repositories stored in Artifacts. The approach supports both platform-managed CI for customer applications and custom workflows, while adding isolated execution, caching, parallelism, and optional AI-powered self-healing. ## Cloudflare-Hosted CI/CD - Artifacts provides versioned code storage capable of supporting millions of repositories. - Artifact push events can directly trigger Workflow executions through a new `events` configuration field. - A CI job can: - Build code in an isolated environment - Run linters, typechecks, and unit tests - Cache dependencies between steps - Automatically fix failed steps with an AI review agent - Deploy only after successful validation ## CI/CD as a Cloudflare Workflow - A traditional CI/CD pipeline is essentially an ordered sequence of Workflow steps. - Instead of complex YAML configuration, developers can define pipelines in TypeScript using `step.do()`. - The CI SDK combines Workflows with the Sandbox SDK to run commands safely and independently. - Workflow retries and timeouts manage state and failures without requiring developers to call the Sandbox API directly. - Push-triggered jobs no longer require separately configuring event subscriptions, queues, and consumers. ## Dependency Caching and Parallel Execution - An initial install step can download dependencies and tools such as bundlers, linters, and test runners. - Cache inputs can include files such as `package.json` and `bun.lock`. - The resulting sandbox snapshot is stored in an R2 bucket and reused by later steps. - Build, lint, test, and typecheck steps can run concurrently with `Promise.all()`. - A deploy step runs only after all required checks complete successfully. ## Platform-Managed and Custom CI - Platforms can define one reusable CI/CD pipeline for applications created by their customers. - Platform-owned code and customer code can use different pipelines while remaining in the same namespace. - Customers who need specialized behavior can define their own Workflow and run custom CI on their repository. - Both managed and custom CI pipelines can operate simultaneously. ## Extensible and Self-Healing Pipelines - Developers can import `CIWorkflow` from `@cloudflare/ci` and define their own workflow. - Each build or validation step runs in a separate isolated sandbox. - Workflows can invoke an AI agent when a build fails. - The agent can diagnose issues, apply a fix, and push a commit for approval. - Cloudflare provides a self-healing CI example through Project Think. Cloudflare’s recommended model is to treat CI/CD as ordinary TypeScript Workflow code: install dependencies once, run checks in parallel, and deploy only after success. This gives platforms a reusable default pipeline while preserving the flexibility for individual teams or customers to customize their own builds.

buncloudflareci-cdtypescript+3

cloudflareApr 20, 2026

Orchestrating AI Code Review at scale (opens in new tab)

Cloudflare built a CI-native AI code review system to reduce review bottlenecks without overwhelming engineers with noisy or generic model feedback. Instead of using one large prompt, it orchestrates up to seven specialized agents for areas such as security, performance, compliance, and documentation, then uses a coordinator to deduplicate and assess findings. The system now reviews tens of thousands of merge requests, approving clean changes and blocking serious bugs or vulnerabilities. ## Why Naive AI Review Wasn’t Enough - Traditional code review can leave merge requests waiting for hours and creates repeated context switching. - Commercial AI review tools provided useful functionality but lacked the flexibility and customization required across Cloudflare’s organization. - A basic “send the Git diff to an LLM” approach produced: - Vague recommendations - Hallucinated syntax errors - Repetitive advice such as adding error handling where it already existed - Complex codebases required specialized analysis rather than generic summarization. ## Specialized Agents and Coordination - The system launches up to seven focused reviewers covering: - Security - Performance - Code quality - Documentation - Release management - Internal Engineering Codex compliance - A coordinator agent: - Deduplicates overlapping findings - Evaluates the actual severity of issues - Produces one structured review comment - The system can actively block merges when it detects serious defects or security vulnerabilities. ## Plugin-Based Architecture - The platform uses composable plugins so it can support different: - Version-control systems - AI providers - Internal standards - Repository-specific requirements - Each plugin implements a `ReviewPlugin` interface with three lifecycle phases: - `bootstrap`: Runs concurrently and is non-fatal. - `configure`: Runs sequentially and is fatal if essential configuration fails. - `postConfigure`: Handles asynchronous work after configuration assembly. - Through `ConfigureContext`, plugins can: - Register agents and AI providers - Set environment variables - Inject prompt sections - Configure agent permissions - Plugins contribute through the context API rather than accessing the final configuration directly. - The core assembler combines these contributions into `opencode.json`. - This separation prevents unrelated components from becoming tightly coupled; for example, GitLab logic does not need to understand Cloudflare AI Gateway settings. ## Plugin Responsibilities - `@opencode-reviewer/gitlab` - Provides GitLab merge request data and a comment server. - `@opencode-reviewer/cloudflare` - Configures AI Gateway model tiers and fallback chains. - `@opencode-reviewer/codex` - Checks compliance with internal engineering RFCs. - `@opencode-reviewer/braintrust` - Adds distributed tracing and observability. - `@opencode-reviewer/agents-md` - Verifies that repository `AGENTS.md` instructions are current. - `@opencode-reviewer/reviewer-config` - Retrieves remote model overrides for individual reviewers. - `@opencode-reviewer/telemetry` - Tracks reviews asynchronously. ## Why OpenCode - Cloudflare already used OpenCode extensively and understood its behavior. - Its open-source implementation allows engineers to: - Investigate problems directly - Contribute fixes upstream - Extend the system through its SDK - Cloudflare engineers had contributed more than 45 upstream pull requests at the time of writing. - Its server-first design was especially important: - Review sessions can be created programmatically. - Prompts can be sent through an SDK. - Multiple concurrent sessions can be managed without scraping or wrapping a CLI interface. ## Coordinator Process - The coordinator runs OpenCode as a child process using `Bun.spawn`. - Its prompt is passed through `stdin` rather than a command-line argument. - This avoids Linux’s `ARG_MAX` limit, which previously caused `E2BIG` failures for unusually large merge requests containing extensive descriptions or logs. - OpenCode runs with `--format json`, emitting JSONL events through standard output. - This event-based interface allows the orchestration layer to collect and process results from concurrent reviewer sessions. A practical takeaway is to treat AI review as an orchestrated CI system rather than a single LLM prompt. Specialized agents, strict plugin boundaries, structured outputs, and observability are essential for making automated review reliable enough to influence merge decisions at organizational scale.

bundatabase-designllmgitlab+4