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.

wranglercloudflareci-cdtypescript+3

cloudflareAug 4, 2026

Your agent can now debug Workers with local tracing (opens in new tab)

Cloudflare now enables `wrangler dev` and `vite dev` to automatically capture OpenTelemetry traces for local Worker requests. Coding agents can discover the Local Explorer API, query traces and logs, inspect local resources, and debug failures without extra SDKs, configuration, or temporary logging. This lets agents diagnose and verify fixes locally before deployment. ## Automatic Tracing for Local Development - Wrangler and the Cloudflare Vite plugin capture traces for local Worker invocations. - Tracing requires no application code changes, SDK installation, or observability setup. - Instrumentation covers: - Outbound `fetch` requests - KV, R2, D1, Durable Objects, Queues, and other bindings - Fetch, scheduled, and queue handlers - Custom application spans - Miniflare collects runtime events and console output, then stores correlated OpenTelemetry traces and logs in a local SQLite-backed Durable Object. ## Agents Discover the Local Explorer API - When a supported coding-agent session is detected, the development server displays the Local Explorer API URL and trace-query endpoint. - The API exposes an OpenAPI schema, allowing agents to discover available operations dynamically. - Agents can query read-only traces and logs using SQL, then inspect or modify local Worker state and bindings. - Local resources available for inspection include D1, KV, R2, Durable Objects, and Workflows. ## Diagnosing and Verifying Failures - In an example `POST /api/orders` request: - KV successfully retrieves the active cart. - A D1 insert fails because the `delivery_window` column is missing. - The Queue is never called. - Without traces, an agent must add logs around each operation and repeatedly reproduce the request. - With traces, it immediately identifies the failed D1 operation, checks the local schema, applies the existing migration, reruns the request, and confirms success through a new trace. - The entire debugging cycle happens locally, without deployment or temporary instrumentation. ## Local Explorer for Human Developers - The browser-based Local Explorer displays the same telemetry available to agents. - Developers can inspect request spans, timing, attributes, errors, and correlated console logs. - It runs on the same localhost origin as the Worker. - Open it by pressing `e` in Wrangler or visiting `/cdn-cgi/explorer`. ## Getting Started - Update the relevant dependency: - `wrangler@latest` - `@cloudflare/vite-plugin@latest` - Continue asking agents to debug Workers locally as usual; trace access is provided automatically. Cloudflare’s recommendation is to use local tracing as part of the normal agent-driven development loop, giving agents structured runtime evidence to diagnose problems and validate fixes before deployment.

wranglerobservabilitycloudflare-workersdurable-objects+4

cloudflareAug 4, 2026

Introducing: Cloudflare Agents (opens in new tab)

Cloudflare is introducing Agents, a unified platform for deploying, observing, and improving hosted AI agents. Its first major feature is agent tracing, which exposes model calls, tool execution, token usage, approvals, subagents, and underlying Cloudflare infrastructure in one view. The goal is to help developers diagnose agent failures, understand costs and latency, and use operational data to continuously improve agent behavior. ## Agent Tracing Adds Visibility - Traditional telemetry can show that an HTTP request succeeded while hiding agent-level failures, such as: - Choosing the wrong tool - Passing stale context to a subagent - Entering a token-consuming retry loop - Cloudflare’s agent-aware traces capture: - Agent invocations - Model calls and token usage - Tool executions and results - Approval or pause events - Supported subagent calls - These agent spans appear alongside existing Workers telemetry for fetches, KV, D1, Durable Objects, and other infrastructure. - Initial integrations support Think, Flue, and AI SDK through OpenTelemetry-compatible tooling. ## Reviewing Agents in the Cloudflare Dashboard - A new Agents view lists observed agents, traces, sessions, instances, runs, and token usage. - Developers can inspect agent behavior through: - **Session replay**, which reconstructs recorded conversations - **Trace waterfalls**, which show execution timing and nested operations ## Session Replay - The Messages tab displays: - System instructions - User messages - Model reasoning - Tool calls, arguments, and results - Final responses - Replay is based on captured data and does not re-execute the agent. - It can reveal malformed tool arguments, inappropriate tool choices, subagent handoffs, retries, and context that influenced later decisions. - Think, Flue, and AI SDK provide `storeMessages` and `storeTools` controls to determine whether message and tool payloads are recorded. - Payload capture can be disabled when data may contain personal information, secrets, or other sensitive content. ## Trace Waterfalls Connect Agent and Infrastructure Activity - Traces show how much time each part of a turn consumed and how operations relate to one another. - A parent agent can be connected to nested subagents, model calls, tools, and Cloudflare resources. - Example operations include: - A parent `TravelPlanner` invocation lasting 2.72 minutes - An `itinerary_builder` subagent using 1.83 minutes - Model calls with duration and provider-reported token usage - Tool executions - D1 queries and KV writes triggered by those tools - Nested tracing makes it possible to follow work from the original agent through delegated tasks and the infrastructure each task used. ## Enabling Agent Tracing - Enable tracing in `wrangler.jsonc`: ```json { "observability": { "traces": { "enabled": true } } } ``` - Setup then depends on the agent stack: - **Think and Flue:** Emit agent, conversation, turn, model, and tool telemetry through their tracing integrations. - **AI SDK:** Wrap the SDK with Cloudflare’s `wrapAISDK()` adapter. - **Custom harnesses:** Use Cloudflare’s custom spans API and OpenTelemetry’s Generative AI semantic conventions. ## Broader OpenTelemetry Support - Cloudflare plans to support the OpenTelemetry API directly inside Workers. - Frameworks that already emit standard Generative AI spans will eventually work in the Agents view without Cloudflare-specific adapters. - Standard agent and conversation identifiers will allow Cloudflare to group spans into agents and sessions. - This complements Cloudflare’s existing ability to export OpenTelemetry data by allowing Workers to accept standard telemetry directly. ## OpenTelemetry Export - Agent telemetry is not restricted to Cloudflare. - Traces can be exported to OTLP-compatible observability providers by configuring a destination in the Worker’s Wrangler configuration. Cloudflare’s initial Agents release focuses on making AI behavior inspectable rather than treating agents as opaque application requests. Developers should enable tracing, choose payload retention carefully for privacy, and use session replay and nested traces to identify correctness, latency, cost, and orchestration problems.

wranglercloudflare-workersdurable-objectsopentelemetry+4

cloudflareJul 6, 2026

Your Worker can now have its own cache in front of it (opens in new tab)

Workers Cache places a tiered Cloudflare cache directly in front of a Worker, allowing cacheable responses to be served without running the Worker or incurring CPU time. It is enabled with a single Wrangler configuration block and controlled through standard HTTP headers such as `Cache-Control` and `Cache-Tag`. The feature gives server-rendered applications a middle ground between expensive per-request rendering and slow, rebuild-dependent static generation. ## How Workers Cache Works - Enable it in Wrangler with: ```json { "cache": { "enabled": true } } ``` - Cacheable requests are checked against Cloudflare’s cache before the Worker runs. - Cache hits return immediately without invoking the Worker or consuming CPU time. - Cache misses execute the Worker, and cacheable responses are stored for later requests. - Caching follows the Worker across: - Custom domains - `workers.dev` - Service bindings - Preview environments - Workers for Platforms tenants - Responses use familiar HTTP controls: - `Cache-Control` for TTL and behavior - `stale-while-revalidate` for background refreshes - `Vary` for content negotiation - `Cache-Tag` for targeted invalidation ## Purging Cached Content - Workers can purge their own cache programmatically: ```js await ctx.cache.purge({ tags: ["product:123"] }); ``` - Purging can target cache tags or path prefixes. - `ctx.props` supports cache keys that are safe for multi-tenant applications. ## Why Server-Rendered Apps Need This - Originally, Workers were positioned in front of an origin and Cloudflare’s cache. - Modern frameworks such as Astro, Next.js, Remix, SvelteKit, and TanStack Start often make the Worker the application’s origin. - Without a cache in front, every request runs application code, even when the response has not changed. - This creates recurring rendering latency and CPU costs for server-rendered pages. ## A Middle Ground Between Static and Dynamic Rendering - Static-site generation provides fast responses but requires rebuilding and redeploying whenever content changes. - Rendering every request keeps content current but imposes latency and compute costs on every visitor. - Workers Cache enables on-demand rendering: - The first request renders and caches the page. - Subsequent requests are served from cache. - Expiration triggers a fresh render according to the configured TTL. - This delivers static-like speed without framework-specific systems such as Incremental Static Regeneration. ## Stale-While-Revalidate - `stale-while-revalidate` allows Cloudflare to serve an expired response immediately while refreshing it in the background. - Without it, the first request after expiration waits for the Worker to render the page again. - With it: - Users receive the stale response instantly. - The response includes `Cf-Cache-Status: UPDATING`. - The Worker refreshes the cached response asynchronously. - A typical policy is: ```http Cache-Control: public, max-age=300, stale-while-revalidate=3600 ``` This keeps content fresh for five minutes while allowing stale content to be served for up to an additional hour during background refreshes. Workers Cache is available to all Workers on every plan. For server-rendered applications, enabling it and defining appropriate HTTP cache headers provides a simple way to reduce latency and execution costs while retaining controlled content freshness.

wranglercloudflare-workershttp-cachingstale-while-revalidate+2

cloudflareJun 24, 2026

Unlocking the Cloudflare app ecosystem with OAuth for all (opens in new tab)

Cloudflare opened self-managed OAuth to all customers so developers can build SaaS integrations, internal platforms, CI/CD workflows, and agentic tools without relying on difficult-to-manage API tokens. The expansion required improvements to permissions, consent, revocation, and phishing protections, as well as a major upgrade to the Hydra-based OAuth engine. Cloudflare used staged migrations, custom database changes, token-handling safeguards, and queued revocations to minimize disruption and preserve users’ security controls. ## Why Cloudflare Expanded OAuth Access - Previously, third-party OAuth integrations were limited to manually approved partners. - Other developers had to use API tokens, which are less convenient and poorly suited to delegated access. - Self-managed OAuth lets customers: - Request narrowly scoped permissions. - Give users clearer consent controls. - Revoke application access from the dashboard. - Build integrations and agentic tools using standard OAuth flows. - Cloudflare improved consent screens to identify the requesting application and its permissions, while making application ownership more visible to reduce phishing risks. ## Planning the Hydra Upgrade - Cloudflare used Hydra, an open-source OAuth engine, but its older deployment could not support the platform’s growing scale and new use cases. - The upgrade was split into two stages: - First, move to the latest 1.X release. - Then, perform the larger 2.X migration. - The 1.X database migrations created operational risks: - Standard index creation could take exclusive locks on critical tables. - Schema changes added columns and moved data between tables. - Hydra’s SDK used `SELECT *`, creating deserialization problems after schema changes. - Cloudflare rewrote migrations to use `CREATE INDEX CONCURRENTLY` and built a custom Hydra version that selected explicit columns. ## Designing a Blue-Green Migration - An in-place 2.X upgrade was rejected because of the volume of schema changes. - A blue-green deployment was chosen, but the migration would take several hours. - Disabling writes would prevent new authorizations and revocations, leaving users unable to manage application access during the upgrade. - Instead, Cloudflare kept writes enabled while reducing the amount of data that could be lost during the cutover: - Token expiry times were temporarily extended to multiple hours, reducing refresh-token writes. - Revocation events were written to Cloudflare Queues. - After switching to the green database, queued revocations could be replayed. - Preserving revocations was essential to prevent applications that users had disabled from regaining access. ## Lessons from the 1.X Upgrade - The custom migrations completed faster than expected without user impact. - A hard cutover was necessary because the old Hydra version could not read tokens created by the new version. - The new version introduced stricter refresh-token invalidation: - Reusing a refresh token invalidated the entire access and refresh-token chain. - This caused problems for high-volume clients such as Wrangler and MCP clients. - Cloudflare added refresh-token coalescing in the Worker routing layer: - Briefly caching requests allowed retries to be served without triggering invalidation. - Hydra 2.X provides a configurable refresh-token grace period, offering a more direct solution for safe retries. ## Executing the 2.X Upgrade - Cloudflare prepared a blue-green migration to avoid several hours of customer-facing downtime. - The strategy depended on reducing token writes, recording all revocations externally, switching databases, and replaying queued events afterward. - The provided article ends while beginning the detailed discussion of the 2.X execution. Cloudflare’s approach demonstrates that opening a security-sensitive platform to broad OAuth usage requires more than exposing an authorization endpoint. Safe adoption depends on explicit permissions, transparent consent, reliable revocation, backward-compatible token behavior, and migration plans that protect users even during infrastructure cutovers.

wranglercloudflare-workersoauthdatabase-migrations+3

cloudflareJun 19, 2026

Temporary Cloudflare Accounts for AI agents (opens in new tab)

Cloudflare introduced Temporary Cloudflare Accounts for AI agents, allowing them to deploy Workers without human-driven signup or authentication. With `wrangler deploy --temporary`, an agent receives a temporary account, API token, and deployment URL, then has 60 minutes to claim the account. If unclaimed, the account and its resources are automatically deleted. ## Why Frictionless Deployment Matters - Background agents often operate without a human available to complete OAuth, copy tokens, or approve MFA. - Temporary deployments support the agent’s rapid write → deploy → verify iteration cycle. - Throwaway environments let agents test code cheaply and independently. - Agent platforms increasingly need deployment workflows that work without requiring users to create accounts on unfamiliar services. ## How Temporary Accounts Work - The feature is integrated into Wrangler, Cloudflare’s CLI for creating, configuring, and deploying projects. - When an unauthenticated deployment encounters the normal signup barrier, Wrangler informs the agent about the `--temporary` option. - Running `wrangler deploy --temporary` provisions: - A temporary Cloudflare account - An API token for Wrangler - A claim URL that can be returned to the user - The temporary account can be reused for multiple deployments during the 60-minute window. ## Agent Deployment and Iteration - An agent can create a TypeScript “Hello World” Worker, deploy it, and use the returned preview URL to verify the result. - It can then modify the source and redeploy without repeating account setup. - Agents can use this loop to test and refine applications autonomously. ## Claiming or Expiring the Account - Users can open the claim link, sign up for or sign in to Cloudflare, and permanently take ownership of the temporary account. - Claiming includes associated Workers, databases, and other bindings. - Unclaimed accounts are automatically deleted after 60 minutes. ## Broader Agent Provisioning Efforts - Cloudflare is also working with Stripe on protocols for agents to create accounts, start subscriptions, register domains, and obtain deployment credentials without manual token or payment entry. - Its collaboration with WorkOS on `auth.md` aims to support agent-driven account creation through established OAuth standards. - Temporary accounts are positioned as one step toward making Cloudflare and other services easier for AI agents to use. Developers should update Wrangler and try `wrangler deploy --temporary` for autonomous, short-lived deployments, while consulting Cloudflare’s documentation for current limitations.

wranglerai-agenttypescriptcloudflare-workers+4

cloudflareApr 13, 2026

Building a CLI for all of Cloudflare (opens in new tab)

Cloudflare is rebuilding Wrangler into a unified CLI for its entire platform, motivated by the growing role of coding agents in configuring and deploying Cloudflare applications. The technical preview, available as `npx cf` or the globally installed `cf` package, currently covers only a subset of products but is intended to support the full API surface. The effort depends on a new TypeScript-based schema system that can generate consistent commands, configuration, bindings, documentation, and agent-oriented interfaces. ## A CLI for all of Cloudflare - Cloudflare offers more than 100 products and nearly 3,000 HTTP API operations. - Agents increasingly use Cloudflare APIs to: - Build and deploy applications - Configure accounts - Query analytics and logs - Create agents and platforms - Cloudflare aims to expose its products consistently through: - CLI commands - Workers Bindings - SDKs - Configuration files - Terraform - Documentation and OpenAPI schemas - MCP servers and Agent Skills - The new Wrangler technical preview can be tried with: - `npx cf` - `npm install -g cf` - A broader internal version already supports the full Cloudflare API, with ongoing work to make command output useful for both humans and agents. ## A new schema and code-generation pipeline - Existing OpenAPI schemas already generate: - Cloudflare SDKs - The Terraform provider - The Code Mode MCP server - Other interfaces, including Wrangler commands, Workers Bindings, configuration, documentation, and Agent Skills, were previously maintained manually. - Manual synchronization was error-prone and could not scale to Cloudflare’s full product range. - OpenAPI alone is insufficient because it primarily describes REST APIs, while Cloudflare also needs to represent: - Interactive CLI workflows - Multiple local and remote actions - RPC-style Workers Bindings - Agent Skills and related documentation - Cloudflare therefore created a TypeScript schema format containing: - API definitions - CLI commands and arguments - Context required to generate different interfaces - Conventions, linting, and guardrails enforce consistency while allowing the schema to generate OpenAPI and future interfaces. ## Consistency for agents and humans - Agents depend on predictable command names and flags. Inconsistent syntax can cause them to call commands that do not exist. - Cloudflare is enforcing conventions at the schema layer, including: - `get`, never `info` - `--force`, never `--skip-confirmations` - `--json`, never `--format` - Applying these rules across interfaces avoids discrepancies between the CLI, REST APIs, and SDKs. - Wrangler must also clearly distinguish local and remote resources. - This is especially important for D1, R2, and KV, where local simulation and remote bindings can coexist. - Clear defaults and output indicating whether an operation targets local or remote resources help agents avoid modifying the wrong environment. ## Local Explorer for simulated resources - Local Explorer is available in open beta through Wrangler and the Cloudflare Vite plugin. - It lets developers inspect locally simulated: - KV - R2 - D1 - Durable Objects - Workflows - Local resources use the same underlying API structure as Cloudflare’s remote APIs and Dashboard. - Cloudflare’s local development environment runs Workers APIs locally, including D1 backed by SQLite through Miniflare. - Previously, developers had to inspect `.wrangler/state` or use third-party tools to understand local data. - Local Explorer provides an interface showing: - Which bindings are attached to a Worker - What data those bindings contain - It can be opened with the `e` keyboard shortcut and helps developers or agents verify schemas, seed test data, and reset local databases. Cloudflare’s direction is to make Wrangler a consistent, machine-readable interface to the entire platform. The technical preview is early, but the new schema-driven system and Local Explorer establish the foundation for a CLI that is easier for both developers and coding agents to use safely.

wranglerdatabase-designcloudflaretypescript+4