SYSTEM Cited by 1 source
Cloudflare CI¶
Cloudflare CI is the @cloudflare/ci workflow surface used in Cloudflare's Agent Development Lifecycle example. It exposes a runner API inside a durable workflow, allowing a task to install dependencies once, then reuse the result to run lint, test, typecheck, and build in parallel before a deployment step. (Source: sources/2026-08-04-cloudflare-agent-development-lifecycle)
Programming model¶
The source demonstrates the following shape:
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' }),
]);
A subsequent runner deploys with an account ID supplied through cloudflareCredentials. This is an example of a workflow-owned delivery path, not evidence of the system's general availability, isolation semantics, runner implementation, or production scale.
Role in the agent lifecycle¶
Cloudflare positions CI as one dynamic workflow among many. The same control plane may call agents, browsers, feature flags, logs, traces, or child workflows while an agent moves from implementation toward an observed release. See patterns/workflow-orchestrated-agent-lifecycle.
Caveats¶
The article does not disclose availability, concurrency, caching implementation, runner isolation, credential-scoping mechanics, pricing, or failure behavior of @cloudflare/ci. The code is illustrative and should not be read as a complete production reference.
Seen in¶
- sources/2026-08-04-cloudflare-agent-development-lifecycle — code-level example of install, parallel validation, and credentialed deploy.