cloudflareAug 7, 2026

Introducing Radar Researcher: An AI tool for exploring Internet data in plain language (opens in new tab)

Cloudflare Radar Researcher is an AI-powered assistant that lets users explore Radar’s Internet data through natural-language questions. It replaces manual API queries, filters, and chart hunting with interactive visualizations, explanations, follow-up questions, and auditable analysis. The beta tool is designed for both casual users and technical researchers, while grounding responses in real data from Radar’s API. ## Why Cloudflare Built Radar Researcher - Cloudflare Radar publishes global Internet data covering: - DNS queries from the 1.1.1.1 resolver - HTTP traffic across Cloudflare’s network - Internet quality measurements from Cloudflare Speed Test - Network outages and other datasets - Radar serves a wide audience, from journalists and curious users to network operators and academics. - AI lowers the barrier to using complex datasets by allowing users to ask questions without knowing a dataset’s structure, terminology, or API. - The tool is especially useful for people working under time pressure, such as journalists investigating current Internet disruptions. ## Natural-Language Data Exploration - Radar Researcher is available from every Radar page in a docked panel. - Users can: - Ask questions in plain language. - Receive short answers or more detailed reports. - View real, interactive Radar charts alongside explanations. - Continue with suggested follow-up questions. - Use text, voice input, or Radar’s search bar. - Conversations are saved in searchable history, can be pinned, and can be shared through links that expire after 30 days. - Users can inspect how the assistant interpreted their question, which datasets it queried, and how it derived its answer. ## Explaining Existing Charts - An “Explain with AI” action lets users start a conversation from any Radar visualization. - The assistant receives: - A screenshot of the chart for visual context. - The exact underlying data from Radar’s API. - The current location, date range, and applied filters. - This combination lets the model explain the exact chart being viewed while preserving numerical accuracy and context. ## Example: Internet Quality in Portugal - A user can ask about home Internet quality in Portugal without manually selecting API parameters or searching Radar pages. - Researcher queries the Internet quality API and presents the results through familiar interactive charts. - Users can ask follow-up questions, such as comparing Portugal with Spain or another neighboring country. - The assistant can also suggest related investigations, including common Internet outages. ## Example: Investigating an Internet Shutdown - Researcher can support more open-ended investigations for engineers, researchers, journalists, and network operators. - For Iran’s 2026 government-directed shutdowns, it: - Retrieved recorded outage events. - Collected corresponding HTTP traffic data. - Explained the timeline in natural language. - The analysis described traffic falling from approximately 0.58 on January 7 to nearly zero by January 9, partially recovering around January 17, and approaching normal levels by January 27. - It displayed the findings as an annotated traffic chart and a table of outages, including another shutdown beginning February 28. - Suggested follow-ups included comparing Iran’s traffic with neighboring countries. ## Cloudflare’s Technical Implementation - The application runs entirely on Cloudflare’s developer platform. - A Cloudflare Worker uses the Cloudflare Agents SDK. - Each conversation is stored in a stateful Durable Object with its own SQLite database. - Chat history, titles, and streaming responses persist even if users leave the page during generation. - Workers AI runs open models, including Kimi K2.7. - An ordered fallback chain across three model families helps maintain availability if one model provider reaches capacity. - Requests are routed through AI Gateway. Radar Researcher makes Cloudflare’s extensive public datasets easier to use without sacrificing precision or transparency. It is particularly valuable when users need fast, context-specific analysis backed by interactive charts and verifiable source data.

durable-objectsllmcloudflare-workerssqlite+3

cloudflareAug 6, 2026

The next generation of MCP (opens in new tab)

MCP’s latest specification makes the protocol fully stateless, removing the session management and persistent connections that complicated remote deployments. Requests now carry the information they need, enabling MCP servers to run on simpler request-scoped infrastructure such as serverless Workers. The update also redesigns elicitation, improves HTTP observability, and strengthens authorization practices. ## MCP Becomes Stateless - Earlier MCP implementations required an `initialize`/`initialized` handshake and an `Mcp-Session-Id` for subsequent requests. - Stateful sessions created operational challenges: - Sticky-session routing - Open-stream management - Session migration during deployments - Reconnection problems when instances disappeared - The new protocol removes: - The mandatory handshake - `Mcp-Session-Id` - Protocol sessions from the core request path - Each request includes its protocol version, client identity, and capabilities. - `server/discover` is available for optional server inspection. - MCP servers can now execute a request and return its result without storing protocol state. - Cloudflare’s `McpAgent` is no longer required for MCP itself; developers can use `createMcpHandler` and deploy on Workers. - Durable Objects remain useful when the application—not MCP—requires state, persistence, or real-time coordination. ## Elicitation Uses Multi Round-Trip Requests - Elicitation allows servers to request additional information or approval, such as confirming a deployment or refund. - Previously, `elicitation/create` depended on an open stream, adding timeout, scaling, and infrastructure complexity. - The new Multi Round-Trip Request model works as follows: - The server returns an `input_required` result. - The client gathers the user’s response. - The client retries the operation with the requested input. - This is a breaking change from the previous approach but removes the need to preserve a transport session. ## HTTP Infrastructure Can Inspect MCP Requests - Streamable HTTP requests now include `Mcp-Method` and `Mcp-Name` headers. - Gateways, rate limiters, and web application firewalls can identify operations such as `tools/call` without parsing JSON-RPC bodies. - Operators can apply method-specific policies and collect tool-level metrics using standard HTTP infrastructure. - Results from `tools/list`, `prompts/list`, `resources/list`, and `resources/read` can include: - `ttlMs` hints - `cacheScope` hints - Deterministically ordered tool catalogs help clients reuse results and maintain stable prompt caches. ## Authorization Continues to Evolve - The specification prioritizes authorization approaches in this order: - Pre-registered clients when an established relationship exists - Client ID Metadata Documents (CIMD) for dynamic registration - Dynamic Client Registration (DCR) as a fallback - DCR is deprecated for new implementations, although the provided text ends before describing the full authorization changes. The new MCP specification significantly reduces deployment complexity by making the protocol request-oriented rather than session-oriented. Developers should migrate from `McpAgent` to `createMcpHandler` where application state is unnecessary, adopt MRTR for elicitation, and update HTTP and authorization integrations to use the new headers and registration guidance.

durable-objectsmodel-context-protocolcloudflare-workersjson-rpc+2

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.

durable-objectsobservabilitycloudflare-workerssqlite+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.

durable-objectscloudflare-workersopentelemetrywrangler+4

cloudflareAug 3, 2026

Your agent needs a computer, not a container — introducing @cloudflare/computer (opens in new tab)

Cloudflare argues that scalable AI agents need their own computer-like environment—filesystem, shell, tools, and execution capabilities—rather than isolated access to ad hoc tools. Its early-preview `@cloudflare/computer` package abstracts across isolates, containers, and browsers while sharing a durable filesystem. The goal is to provide scalable, efficient compute for potentially hundreds of millions or billions of concurrent agents. ## Why Traditional Containers Do Not Scale - Coding agents work best when they can inspect files, run commands, install packages, modify code, and test their changes. - Giving every agent a dedicated container is too resource-intensive for large-scale deployments. - The industry is increasingly demanding CPU compute because agent workloads require substantial execution capacity in addition to GPU-based model inference. - Cloudflare believes agent infrastructure must move beyond conventional container-per-agent architectures. ## Isolates and On-Demand Containers - Cloudflare’s isolates start and stop quickly, scale horizontally, hibernate while idle, and can preserve agent state. - Durable Objects can host the agent loop and invoke containers only when heavier computation is necessary. - This architecture combines: - Isolates for lightweight, scalable coordination and file operations. - Containers for Linux environments, npm, native binaries, and other resource-intensive tasks. - Cloudflare wants to hide the complexity of combining these primitives from application developers. ## A Shared, Durable Filesystem - `@cloudflare/computer` gives each agent a declaratively initialized workspace containing the files and tools needed for its task. - Agents can select the most suitable execution environment: - Isolates for file manipulation, data processing, or Git operations. - Containers for commands requiring Linux, npm, or native binaries. - All environments operate on synchronized copies of the same source filesystem. - The filesystem can work with Git repositories, storage buckets, and arbitrary files. - File operations can be performed through Code Mode or Bash. - Operations are gated, audited, and observable, enabling fine-grained permissions and a record of agent activity. ## Using `@cloudflare/computer` - A workspace can be attached to any Durable Object to provide virtual filesystem and execution capabilities. - Installation uses: ```bash npm install @cloudflare/computer ``` - A `Workspace` is initialized with Durable Object storage and can be connected to an agent framework such as `@cloudflare/think`. - The example describes a bug-triage agent that: - Works in `/workspace/repo`. - Reproduces and investigates bugs. - Applies focused fixes when appropriate. - Runs verification commands. - Reports changes, commands, and verification results. - The package supports multiple execution backends, including Cloudflare Containers, and allows developers to implement custom backends. Cloudflare is presenting `@cloudflare/computer` as an open-source experiment and is seeking feedback from customers building agents at scale. Its practical recommendation is to use isolates as the default execution layer and attach containers only for tasks that genuinely require them, while sharing a controlled, durable workspace across both.

durable-objectstypescriptcloudflare-workersisolates+3

cloudflareAug 3, 2026

Cloudflare Workers and Containers now support inbound TCP connections and gRPC (opens in new tab)

Cloudflare is expanding Workers to support low-latency, TCP-based applications such as real-time voice AI and gRPC services. New inbound socket handling lets Workers route connections through Durable Objects and Containers, while Cloudflare also enables full-duplex gRPC servers running in containers. Together, these capabilities allow developers to deploy language-agnostic TCP and gRPC services closer to users across Cloudflare’s global network. ## Inbound TCP with `connect(socket)` - Workers can now accept inbound TCP sockets through a new `connect()` handler. - The socket exposes readable and writable streams, allowing Workers to send, receive, and proxy raw bytes. - Connections can be routed: - Between Workers - From Workers to Durable Objects - From Durable Objects to Cloudflare Containers - Developers can pipe data in both directions to preserve full-duplex communication. - Containers can run arbitrary TCP servers written in any language, such as Python services listening on port `8080`. - Cloudflare Spectrum provides the TCP ingress layer and routes incoming connections to the selected Worker. ## Full-Duplex gRPC in Containers - Developers can deploy gRPC servers written in languages such as Go inside Cloudflare Containers. - Bidirectional streaming allows clients and servers to exchange messages over one persistent connection. - This is particularly useful for: - Real-time voice AI - Low-latency inference - Mobile and distributed applications - Streaming RPC workflows - A sample Go server sends an initial connection message, echoes incoming messages, and sends a closing message when the client disconnects. - Cloudflare’s network of more than 330 locations can bring gRPC workloads closer to users, reducing latency. ## gRPC APIs from Workers - Workers can serve unary and server-streaming gRPC APIs. - Workers can also call external gRPC servers. - Developers write the application using gRPC-Web, while Cloudflare automatically converts incoming and outgoing requests to standard gRPC. - This provides a simpler integration path for applications that need gRPC without managing raw protocol translation themselves. ## Availability - The features are being introduced through a private beta. - Interested developers must sign up to gain access. Cloudflare recommends these capabilities for applications requiring persistent, low-latency, bidirectional communication. The combination of Spectrum, Workers, Durable Objects, and Containers provides a flexible path for running raw TCP protocols and gRPC services close to end users.

durable-objectscloudflare-workersgrpctcp+3

cloudflareJun 17, 2026

Bringing more agent harnesses to Cloudflare, starting with Flue (opens in new tab)

Cloudflare argues that production AI agents need more than an agent harness: they require platform primitives for durable state, execution, storage, and secure compute. It presents a three-layer stack—framework, harness, and runtime—and introduces Flue as the first framework built on the Cloudflare Agents SDK. Flue uses a declarative approach based on Pi, while Cloudflare supplies the infrastructure needed to resume interrupted work and run agents reliably at scale. ## The Three-Layer Agent Stack - **Framework — Flue** - Provides project structure, conventions, integrations, CLI commands, and developer experience. - **Harness — Pi or Project Think** - Runs the agentic loop: calls tools, processes results, manages context, and continues until a task is complete. - **Runtime/platform — Cloudflare Agents SDK** - Supplies compute, state, storage, durable execution, sandboxing, and workflow primitives. - Cloudflare’s goal is to make these runtime capabilities available to any harness or framework. ## Flue’s Declarative Agent Model - Flue 1.0 Beta is built on the Pi harness, which also powers OpenClaw. - Developers describe what an agent knows rather than explicitly scripting its orchestration. - An agent is defined through its: - Model - Skills - Sandbox - Instructions - This allows relatively compact agents to autonomously handle tasks such as reproducing and diagnosing bug reports. ## Flue’s Developer Experience - **Integrated channels** - Preconfigured integrations let agents work in Slack, GitHub, Linear, and Discord. - Channels handle event verification and dispatch boilerplate. - **Headless and UI-ready operation** - Agents can run as background processes. - `@flue/react` provides hooks for streaming agent state, tool execution, and messages into frontend applications. - **Ecosystem integrations** - Commands such as `flue add channel slack` generate Markdown blueprints that coding agents can modify and integrate into a project. ## Durable Execution with Durable Streams - Production agents face host crashes, LLM API timeouts, restarts, and interrupted tool calls. - Flue records prompts, tool responses, model decisions, and other execution events in an append-only log. - This durable event history prevents in-memory state from being lost. - If a process fails, another process can replay the log and resume from the exact point of interruption. ## Deployment Across Clouds - On Node.js, Flue agents run as long-lived processes on VMs, containers, GitHub Actions, or existing servers. - On Cloudflare, each agent runs in its own Durable Object. - This provides: - Isolated storage and compute - Automatic scaling - No need to provision servers or manage sticky sessions - Protection from noisy neighbors - Cloudflare deployments use Agents SDK features including `runFiber()`, `stash()`, and `onFiberRecovered()` for durable execution. - Sandboxed code execution uses `@cloudflare/codemode` and `@cloudflare/shell` with a durable workspace. ## Requirements for Production Agent Harnesses - An agent turn is a multi-step process that may involve token streaming, tool calls, human approval, or delegated subagents. - These operations can last seconds or minutes and may fail at any point. - Persisting only conversation history is insufficient because it does not preserve active execution state, pending tool calls, or the agent’s current position. - Cloudflare’s fiber-based primitives provide checkpointing so interrupted agent turns can recover instead of leaving users with stalled requests. Cloudflare’s recommendation is to treat the framework, harness, and runtime as separate but coordinated layers. Frameworks like Flue make agents easy to build, while the Agents SDK supplies the durable execution and infrastructure primitives required to operate them reliably in production.

durable-objectscloudflare-agents-sdkdurable-executionflue+3

cloudflareMay 13, 2026

Browser Run: now running on Cloudflare Containers, it’s faster and more scalable (opens in new tab)

Browser Run was rebuilt on Cloudflare Containers to improve speed, reliability, and scale. The migration increased capacity to 60 browser launches per minute and 120 concurrent browsers—four times the previous limit—while cutting Quick Action response times by more than 50%. The main architectural changes were global Container deployment, regional pools of pre-warmed browsers, and replacing eventually consistent KV state with transactional D1 and batched Queue updates. ## Browser Run’s Role - Provides programmatic access to headless browsers on Cloudflare’s global network. - Supports: - End-to-end testing - Suspicious URL investigation - PDF rendering - Screenshots and content extraction - Web interaction for AI agents - The goal is to offer secure, responsible browser automation at massive scale. ## Why the Previous Infrastructure Was Limiting - Browser Run originally shared infrastructure with Browser Isolation (BISO). - BISO’s larger container images caused slower startup and development cycles. - Browser Run lacked optimal global distribution, affecting latency and resilience. - BISO’s long-running sessions conflicted with Browser Run’s short, bursty workloads. - These differences created scaling and availability bottlenecks. ## Gradual Migration to Containers - A Worker initially routed a small number of requests to Container-based browsers while others continued using BISO. - This dual-running setup allowed the team to: - Compare performance - Find implementation bugs - Validate stability - Rollout stages included: - Quick Actions - Free-account Workers browser binding connections - Pay-as-you-go accounts - Contract customers - Customers did not need to change code or redeploy Workers. ## Regional Pools for Lower Latency - Durable Object-enabled Containers can create the Durable Object near the request while starting the Container elsewhere. - This is acceptable for one-off commands but inefficient for WebSocket workflows involving many messages. - The team introduced regional pools of pre-warmed, Durable Object-backed browsers. - Requests are assigned to a nearby Durable Object–Container pair, reducing latency between: - The user and Durable Object - The Durable Object and browser Container - The design requires global browser-state observability so capacity can be allocated and reassigned as demand changes. ## Replacing KV with D1 and Queues - Workers KV was initially used to track browser availability. - Its eventual consistency and cache TTL—around 30 seconds or longer—caused race conditions: - A browser could appear available when another request had already claimed it. - Delayed state updates led to over-allocation and limited responsiveness to traffic spikes. - Browser state was moved to D1, whose SQLite transactions provide atomic assignment. - A browser is exclusively assigned to one user, preventing simultaneous claims through transactional updates. Example acquisition logic updates selected candidates to `picked` and returns their data in one operation: ```sql WITH candidate_pool AS (...) UPDATE containers SET status = 'picked' WHERE sessionId IN ( SELECT sessionId FROM candidate_pool ORDER BY RANDOM() LIMIT ?5 ) RETURNING data; ``` ## Batching State Updates - D1 shards are maintained by location. - Thousands of containers report their state every five seconds, which could overload the database if each update were written individually. - Queue-based batching groups 100 updates into a single write. - This increases theoretical capacity from roughly 5,000 containers per location to as many as 500,000. - The team reports a P95 batch-write latency of 0.1 ms. - Queue consumers use: - Maximum batch size: 100 - Maximum batch timeout: 1 second - Maximum retries: 1 The migration is live, requires no customer changes, and gives Browser Run more room to handle demand from AI agents and other high-volume browser automation workloads.

durable-objectscloudflare-workerssqlitewebsockets+4

cloudflareApr 16, 2026

Artifacts: versioned storage that speaks Git (opens in new tab)

Artifacts is a distributed, versioned filesystem designed for AI agents and other high-volume compute environments. It creates repositories programmatically while remaining compatible with standard Git clients, enabling isolated repositories for agent sessions, sandboxes, and large numbers of forks. Cloudflare argues that Git’s familiar data model—commits, history, diffs, and branching—can serve as a general-purpose state-management primitive beyond traditional source control. ## A Git-Compatible Filesystem for Agents - Artifacts repositories can be created through the Workers API or REST API. - Applications receive a Git remote and authentication token, allowing agents to clone and use repositories with ordinary Git commands. - Repositories can be created dynamically for: - Individual agent sessions - Sandbox instances - Large-scale forked environments - Non-Git clients such as Workers, Lambda functions, and Node.js applications can use the API directly or language-specific SDKs. - Existing repositories can be imported from sources such as GitHub, then independently forked for isolated or read-only work. ## Why Git Fits Agent Workflows - Most AI coding agents already understand Git, including common workflows and edge cases. - Git’s object and commit model works well for storing: - Source code and configuration - Session prompts and agent history - Other large collections of small, versioned data - Git provides built-in capabilities for: - Tracking state over time - Reverting changes - Comparing versions - Forking from historical points - Using Git avoids requiring agents to learn a new protocol, CLI, or specialized tool. ## Beyond Source Control - Artifacts can persist an entire agent session’s filesystem and history without requiring dedicated block storage. - Cloudflare uses per-session repositories to: - Restore sandbox state - Share sessions with other people - Time-travel through both prompts and filesystem changes - Fork a session from any point for collaboration or debugging - The same semantics can support non-code data, such as customer-specific configuration that needs rollback, cloning, or diffing. - Cloudflare expects non-Git use cases to be as important as conventional repository workflows. ## Implementation on Cloudflare - Artifacts are built on Durable Objects, which provide isolated, stateful compute capable of supporting millions of repository instances. - The system uses an in-house Git implementation written in Zig and compiled to WebAssembly for Cloudflare Workers. - The implementation was designed to be: - Small - Broadly Git-compatible - Extensible for features such as notes and Git LFS - Efficient in a Workers environment Artifacts is currently available in private beta for paid Workers customers, with a public beta planned for early May. It is intended as a practical way to give agents and applications disposable, persistent, and fully versioned environments without abandoning the Git ecosystem.

durable-objectsdatabase-designtypescriptcloudflare-workers+4

cloudflareApr 15, 2026

Project Think: building the next generation of AI agents on Cloudflare (opens in new tab)

Project Think is Cloudflare’s next-generation Agents SDK for building persistent, scalable AI agents. It combines durable execution, sub-agents, persistent sessions, sandboxed code execution, and runtime-created extensions, while allowing developers to use individual primitives or an integrated Think base class. Its central argument is that agents should run as durable, one-to-one infrastructure rather than ephemeral processes on laptops or permanently running servers. ## Why Agents Need a New Foundation - Coding agents increasingly act as general-purpose assistants by reading context, writing and executing code, observing results, and iterating. - Existing agents are limited by: - Dependence on a laptop or costly VPS - Fixed costs while idle - Manual installation, updates, identity, and secret management - Unlike traditional applications, agents are typically one-to-one: each user, task, or conversation may require a distinct agent. - Supporting millions of concurrent agents with always-on containers would be economically impractical. ## Project Think’s Core Primitives Project Think introduces: - Durable execution through fibers, including checkpointing, crash recovery, and automatic keepalive - Isolated sub-agents with independent SQLite databases and typed RPC - Persistent, searchable sessions with message trees, branching, and compaction - Sandboxed code execution using Dynamic Workers, codemode, and runtime npm resolution - An execution ladder spanning workspaces, isolates, npm packages, browsers, and sandboxes - Self-authored extensions that let agents create tools dynamically ## Long-Running Agents with Durable Objects - Each agent is implemented as a Durable Object with: - A stable identity - Persistent SQLite-backed state - Message-based wake-up - Automatic hibernation when idle - Agents can resume after HTTP requests, WebSocket messages, alarms, or inbound email. - Hibernated agents consume no compute, allowing many more agents than an always-on VM or container model. - Durable Objects provide automatic routing, recovery, and per-agent state without separately managed load balancers, databases, or process supervisors. - For example, 10,000 agents active only 1% of the time require capacity for roughly 100 active agents rather than 10,000 continuously running instances. ## Durable Execution with Fibers - Long LLM calls and multi-step workflows can be interrupted by deployments, restarts, or resource limits. - `runFiber()` makes a function invocation durable by: - Registering it in SQLite before execution - Allowing progress to be checkpointed with `stash()` - Recovering interrupted work through `onFiberRecovered` - Agents can save intermediate findings, resume from the latest checkpoint, and broadcast progress to clients. - The SDK automatically keeps the agent alive while a fiber runs. - `keepAlive()` and `keepAliveWhile()` support active work lasting minutes or longer, such as CI pipelines, design reviews, and video generation. Project Think’s recommendation is to treat agents as persistent, addressable infrastructure: use the low-level primitives for customization, or adopt the Think base class for a faster, integrated starting point.

durable-objectsdatabase-designsqliteagents-sdk+4

cloudflareApr 15, 2026

Rearchitecting the Workflows control plane for the agentic era (opens in new tab)

Workflows was originally designed for human-paced events, but autonomous agents now create and manage workflow instances at machine speed. To support this shift, the platform increased its limits substantially and redesigned its control plane for horizontal scalability. The new architecture replaces V1’s account-level bottleneck with distributed components while preserving durable execution, retries, and human-in-the-loop pauses. ## The Shift to Agent-Driven Workloads - Workflows initially handled events such as sign-ups and purchases, typically requiring only one instance per person. - Persistent agents can operate for hours or days and launch dozens of workflows from a single session. - Concurrent agents can create thousands of workflow instances within seconds. - Workflows also serve as durable execution harnesses for agent loops, maintaining progress across failures and supporting asynchronous work. ## Higher Workflows Capacity The platform now supports: - **50,000 concurrent instances**, up from 4,500. - **300 instance creations per second per account**, up from 100. - **2 million queued instances per workflow**, up from 1 million. These increases were driven by observed usage patterns and a redesign of the control plane. ## V1: A Single Account-Level Bottleneck - Each workflow consists of durable, independently retryable steps that can run tasks, wait for events, or sleep until a scheduled time. - SQLite-backed Durable Objects provide execution, coordination, and storage. - An **Engine Durable Object** is created for each workflow instance and handles execution, retries, and sleeping. - A single **Account Durable Object** manages account-wide workflow and instance metadata. - All create, update, and list operations passed through the Account object. - High-volume customers could generate thousands of requests per second as instances started and completed, overwhelming the singleton. - The original rate limits were therefore hard architectural limits rather than adjustable product settings. ## V2: Horizontal Scaling Principles The redesigned control plane is based on several architectural changes: - The instance’s **Engine is now the sole source of truth** for whether that instance exists. - The system verifies that an Engine exists before queuing an instance, avoiding queued instances with no running execution object. - Instance lifecycle and liveness operations are distributed across workflows and regions so they can scale horizontally. - The Account singleton stores only essential metadata and has a bounded maximum number of concurrent requests. - Limits are designed to be flexible and increaseable rather than constrained by one central bottleneck. ## SousChef and Gatekeeper - V2 introduces two central components: **SousChef** and **Gatekeeper**. - SousChef acts as a “second in command” to the Account, taking over work that previously concentrated all workflow and instance management in one Durable Object. - Together, these components are intended to distribute control-plane responsibilities and enable higher creation rates and concurrency. - The migration was performed with live traffic, allowing customers to move to the new architecture without interruption. The redesign aligns Workflows with agentic workloads by moving coordination away from a single account-level Durable Object. Developers running high-volume or highly concurrent agents should benefit from the new limits and a control plane that can continue scaling independently.

durable-objectsdatabase-designsqlitescalability+3

cloudflareApr 13, 2026

Durable Objects in Dynamic Workers: Give each AI-generated app its own database (opens in new tab)

Dynamic Workers make it possible to run AI-generated code securely in lightweight isolates, but disposable execution is not enough for persistent applications. Cloudflare’s Durable Object Facets address this by letting a supervised Durable Object dynamically load an AI-generated Durable Object class with its own SQLite-backed storage. This combines sandboxed, persistent application state with centralized control over provisioning, access, logging, metrics, and billing. ## From Disposable Code to Persistent Apps - Dynamic Workers load code on demand in secure isolates rather than containers. - Isolates start quickly and use little memory, making them suitable for short-lived AI-generated tasks. - Persistent AI-built applications need: - Custom user interfaces - Long-lived state - Secure execution - A remote SQL database could provide storage, but it introduces network latency and additional infrastructure. ## Why Durable Objects Fit - Each Durable Object has: - A globally unique name - One active instance per name - An attached SQLite database stored locally - Local SQLite storage provides extremely low-latency access. - AI-generated applications can therefore use normal Durable Object storage APIs, including key-value and SQL storage. ## Limitations of the Traditional Model - Standard Durable Objects require: - A class extending `DurableObject` - Exporting the class from the Worker - Wrangler configuration to provision storage - A namespace binding for access - This model does not naturally support code loaded dynamically at runtime. - Giving an agent direct control of Durable Object namespaces could also allow uncontrolled object creation and storage use. - A platform needs an intermediary to enforce limits and provide observability, billing, and other operational controls. ## Durable Object Facets - Facets allow a normal, statically configured Durable Object to dynamically instantiate another Durable Object class. - The outer object acts as a supervisor: - Loads the agent’s code as a Dynamic Worker - Selects the exported Durable Object class - Forwards requests or RPC calls - Controls and monitors the application - The dynamically loaded class can directly extend `DurableObject`. - Each facet receives its own SQLite database, separate from the supervisor’s database. - Multiple facets can exist within one Durable Object, each identified by a name and subject to storage limits. ## Example Architecture - An `AppRunner` Durable Object receives incoming requests. - It obtains a facet named `"app"` through `this.ctx.facets.get(...)`. - When the facet starts, the runner: - Loads the Dynamic Worker - Retrieves its exported application class - Instantiates it as the facet - Requests are then forwarded to the dynamically loaded application. - The sample application maintains a request counter using Durable Object storage. Durable Object Facets provide a practical foundation for AI-generated applications that need persistent state without sacrificing isolation or platform governance. They are especially suited to personal or small “vibe-coded” apps, where each application can receive its own storage while the host platform retains control over resource usage and operational policies.

durable-objectsdatabase-designcloudflarepostgresql+3

cloudflareFeb 3, 2026

Improve global upload performance with R2 Local Uploads (opens in new tab)

R2 Local Uploads improves global upload performance by first writing object data near the client, then asynchronously copying it to the bucket’s region. Objects become immediately available and remain strongly consistent during replication. Cloudflare reports up to a 75% reduction in upload request duration for cross-region uploads. ## Faster Global Uploads - Local Uploads targets `PutObject` and `UploadPart` requests made far from the bucket’s location. - Synthetic tests showed median upload TTLB dropping from about 2 seconds to 500 milliseconds. - Tests used 5 MB objects uploaded from Western North America to an Asia-Pacific bucket at roughly 20 requests per second. - The feature is available in open beta and can be enabled in the Cloudflare Dashboard or with: ```bash npx wrangler r2 bucket local-uploads enable [BUCKET] ``` ## The Cross-Region Distance Problem - R2 requests enter through a globally distributed Gateway Worker, which handles authentication and routing. - Object metadata is managed by a distributed Durable Object Metadata Service. - Encrypted object data is stored in R2’s distributed storage infrastructure. - Without Local Uploads, streamed data must travel to the bucket’s region before the upload can complete. - Long-distance transfers can increase latency and introduce upload variability or reliability issues. ## How Local Uploads Works - If the client and bucket are in the same region, R2 uses its normal storage flow. - If they are in different regions: - Data is initially written to storage near the client. - Metadata is published in the bucket’s region. - The object becomes readable as soon as the local write completes. - Background replication later copies the data to the bucket’s primary region. - There is no read-unavailability window while replication is in progress. - Local Uploads is unavailable for jurisdiction-restricted buckets, including EU and FedRAMP buckets. ## When to Use It - Applications have users or devices distributed across multiple regions. - Upload speed and reliability are important. - You want faster writes without moving the bucket’s primary location. - R2’s Metrics page can help identify regional request patterns through the “Request Distribution by Region” graph. ## Replication Architecture - R2 represents the background copy operation as a replication task. - Cloudflare Queues process these tasks asynchronously. - Queues provide: - Rate control for replication. - Automatic retries. - Dead-letter queue support for failures. - Sharding across multiple queues for each storage region. - When publishing object metadata, R2 atomically: - Stores the object metadata. - Creates a pending-replica key describing unfinished replication work. - Creates a timestamp-based replication marker that determines when the task enters a queue. - The pending-replica record includes the replication plan, source and destination locations, mode, priority, and whether the source can be deleted after successful replication. Local Uploads is a strong fit for globally distributed upload-heavy workloads. Enable it when cross-region write latency matters, while keeping in mind the restriction on jurisdiction-constrained buckets.

durable-objectscloudflare-workerscloudflare-r2object-storage+4

cloudflareJan 27, 2026

Building a serverless, post-quantum Matrix homeserver (opens in new tab)

The post describes a proof-of-concept Matrix homeserver ported from Synapse to Cloudflare Workers. It replaces traditional VPS, PostgreSQL, Redis, and filesystem infrastructure with Workers, Durable Objects, D1, KV, and R2, reducing operational overhead and allowing costs to fall near zero when idle. The design also provides post-quantum TLS automatically while preserving Matrix’s end-to-end encryption, though the homeserver still exposes metadata. ## From Synapse to Cloudflare Workers - Traditional Synapse deployments depend on: - PostgreSQL for persistent state - Redis for caching - Filesystem storage for media - VPS infrastructure and operational maintenance - The proof of concept reimplemented core Matrix functionality in TypeScript with Hono, including: - Event authorization - Room state resolution - Cryptographic verification - Cloudflare services replace the traditional components: - Durable Objects provide strongly consistent, atomic coordination. - D1 replaces PostgreSQL. - KV replaces Redis. - R2 replaces filesystem-based media storage. ## Benefits of a Serverless Homeserver - Deployment becomes a single `wrangler deploy` command. - Cloudflare provides TLS termination, load balancing, DDoS protection, and global distribution. - Request-based pricing means the homeserver can cost almost nothing during periods of inactivity. - Workers execute close to users in more than 300 locations, reducing latency for globally distributed communities. - Built-in security features reduce the need to configure firewalls, rate limiting, WAF rules, and IP reputation systems manually. ## Post-Quantum TLS and Matrix Encryption - Cloudflare’s TLS 1.3 connections use hybrid `X25519MLKEM768`. - This combines: - X25519, a classical elliptic-curve algorithm - ML-KEM, a lattice-based post-quantum algorithm standardized by NIST - The hybrid design requires both cryptographic systems to be broken before the connection is compromised. - Traditional deployments would need to upgrade cryptographic libraries, configure cipher suites, test client compatibility, and monitor negotiation failures. - Workers provide this protection automatically through Cloudflare’s infrastructure. ## How Messages Are Protected - Matrix clients encrypt messages locally using Megolm before sending them. - The encrypted Megolm payload is then transported over TLS using post-quantum hybrid key agreement. - The Worker terminates TLS but receives only ciphertext, which it stores and routes without seeing plaintext. - Recipients download the ciphertext over another protected TLS connection and decrypt it locally. - This creates two independent encryption layers: - TLS protects data in transit. - Megolm end-to-end encryption protects message contents from the homeserver and infrastructure providers. ## Metadata and Privacy Limits - The homeserver operator can still observe metadata, including: - Room membership - Room existence - Message timing - Other routing and account information - Message contents remain inaccessible because they are encrypted before reaching the server. - Encrypted-room media is also encrypted client-side, and private keys remain on user devices. ## Storage Architecture - The design assigns each storage primitive to the consistency model it supports best. - D1 stores durable, queryable Matrix data, including users, rooms, events, and device keys across more than 25 tables. - Durable Objects handle real-time coordination and the strong consistency needed for Matrix state resolution. - KV provides cache-like storage, while R2 handles media and filesystem-style objects. The project demonstrates that a Matrix homeserver can be made substantially easier to operate with serverless infrastructure while gaining globally distributed execution and automatic post-quantum transport security. It remains a personal proof of concept, so production deployments should evaluate feature completeness, scalability, compatibility, and the privacy implications of relying on Cloudflare.

durable-objectstypescriptcloudflare-workersserverless+4