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.

sqlitellmcloudflare-workersdurable-objects+3

cloudflareAug 6, 2026

Introducing Kitesurf: The agent-first browser that runs in V8 isolates on Cloudflare Workers (opens in new tab)

Cloudflare argues that AI agents need a browser optimized for machine tasks rather than human browsing. Chromium provides far more functionality than agents require while consuming too much memory and compute, limiting accessibility and scalability. The company therefore built Kitesurf, a lightweight browser running entirely on Workers and designed for agentic workloads. ## Why Cloudflare Built a New Browser - Cloudflare had repeatedly considered building a browser but previously found the technical investment difficult to justify. - Recent advances in its Developer Platform changed the equation: - Mature WebAssembly support in Workers - Dynamic workers - SQLite-based Durable Objects - Worker-to-worker RPC and service bindings - Improved Node.js compatibility and higher platform limits - Growing demand for AI browser automation exposed Chromium’s limitations: - High CPU and memory consumption - Expensive dedicated browser instances - Poor scalability for large numbers of agents ## Designing for Agents Instead of Humans - Agents prioritize: - Low token counts - Large context windows - Scalability and performance - Low operating costs - Structured, machine-readable content - They do not need many human-oriented features, such as: - Tabs, themes, extensions, and device synchronization - Pixel-perfect rendering - Smooth 60-frame-per-second scrolling - AI browser security requires a different threat model, with prompt injection and tool safety treated as central concerns. - Kitesurf became the result: a browser available in beta through Cloudflare’s Browser Run product. ## From Prototype to Product - The project began with inspiration from Obscura, a lightweight Rust headless engine for AI automation. - Cloudflare used an AI agent to attempt a port to Workers. - The first prototype was weak, but a detailed plan and explicit success criteria allowed the agent to iterate effectively. - The promising proof of concept led the team to develop Kitesurf further. ## Testing as a Foundation - Cloudflare relied heavily on automated testing to accelerate development without sacrificing quality. - Web Platform Tests (WPT) provided standards-based criteria for implementing browser features. - Engineers curated feature assignments and sequencing so AI agents could work toward measurable goals. - Because WPT does not fully capture real-world website behavior, Cloudflare added: - Multistep Puppeteer integration tests - Comparisons against Chromium - Visual regression checks at every interaction step - This combination tested both standards conformance and practical rendering behavior. ## Rust and WebAssembly - Kitesurf uses Rust wherever possible and compiles directly to WebAssembly with `wasm-bindgen`. - This avoids the bulk and performance costs associated with Emscripten’s emulation layers and mocked dependencies. - The approach allows browser components to run closer to native performance inside Workers. ## Resilience Through Exception Handling - Since browsers must process unreliable and potentially hostile web content, failures must not terminate entire sessions. - Kitesurf follows a strict rule: - Errors degrade to a blank frame or missing element - Faults are caught at component boundaries - Safe empty defaults are used - Diagnostic information is logged - This makes individual rendering failures survivable rather than allowing malformed input to crash the browser. ## Isolation and Statelessness - Every page load is treated as untrusted input. - Sessions begin fresh, and components receive only the resources they require. - Workers provide isolation boundaries, but Kitesurf also enforces isolation within the application itself to prevent data leakage between pages. - Components are kept stateless wherever possible: - Failed components can simply be recreated - Work can be scaled horizontally and run in parallel - Burst-based workloads avoid the cost of maintaining idle instances - Recovery can consist of restarting a component and replaying a request Kitesurf’s central recommendation is to build browsers around the needs of their users—in this case, AI agents. By sacrificing human-focused features and emphasizing efficiency, structured output, isolation, resilience, and scale, Cloudflare aims to make browser automation practical for a much broader range of agentic applications.

sqliteai-agentcloudflare-workersrust+4

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.

sqliteobservabilitycloudflare-workersdurable-objects+4

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.

sqlitecloudflare-workersdurable-objectswebsockets+4

cloudflareMay 1, 2026

Introducing Dynamic Workflows: durable execution that follows the tenant (opens in new tab)

Dynamic Workflows extends Cloudflare’s durable execution system to multi-tenant and dynamically generated applications. While Dynamic Workers provide isolated runtime compute, Durable Object Facets provide tenant-specific storage, and Artifacts provide versioned source control, Dynamic Workflows lets each tenant supply its own long-running workflow code. The result is durable execution that can resume the correct tenant’s workflow after failures, hibernation, or delays of days. ## The Gap Between Durable and Dynamic Execution - Cloudflare Workflows turns a `run(event, step)` function into a durable program. - Workflow steps can: - Survive isolate recycling and failures - Sleep for hours or days - Wait for external events - Resume from the exact point where execution stopped - Workflows V2 supports up to 50,000 concurrent instances and 300 new instances per second per account. - Traditional Workflows assume the workflow class is included in the deployment and statically configured in `wrangler.jsonc`. - That model breaks for: - Multi-tenant SaaS platforms - AI-generated tenant applications - Repository-specific CI/CD pipelines - Agents that create their own durable plans - In these systems, workflow code varies by tenant, agent, repository, or request, so a single statically bound class is insufficient. ## Dynamic Workflows - `@cloudflare/dynamic-workflows` is a roughly 300-line TypeScript library. - It introduces a Worker Loader that: - Loads each tenant’s code dynamically - Routes workflow creation to the appropriate tenant - Ensures later workflow execution returns to that tenant’s code - The Loader creates a dynamic Worker with: - A tenant-specific module - A `TenantWorkflow` entrypoint - A wrapped `WORKFLOWS` binding - The dynamic entrypoint is registered as the workflow class in `wrangler.jsonc`. - Tenant code remains ordinary Cloudflare Workflows code and does not need to know it is being dynamically dispatched. ## Tenant Workflow Behavior - Tenants can use the normal Workflow APIs, including: - `env.WORKFLOWS.create(...)` - Workflow IDs and `.status()` - `.pause()` - Retries and durable steps - `step.sleep('24 hours')` - `step.waitForEvent()` - A tenant can define a standard `WorkflowEntrypoint` with a `run(event, step)` method. - The library’s primary responsibility is preserving the association between a workflow instance and the tenant implementation when the workflow resumes later. ## Three-Layer Execution Model - Dynamic Workflows consists of three layers: - The Cloudflare Workflows engine - The platform’s Worker Loader - The tenant’s dynamically loaded Worker code - A request first enters the Loader, which identifies the tenant and routes execution to its dynamic code. - The workflow engine then persists the workflow state and later invokes `run(event, step)`. - The Loader resolves the correct tenant implementation when execution resumes, even after delays or failures. Dynamic Workflows provides the missing durable-execution counterpart to Cloudflare’s dynamic compute, storage, and source-control primitives. It is particularly suited to platforms where customers or agents generate workflow code at runtime while still requiring standard durable guarantees.

sqlitedatabase-designtypescriptcloudflare-workers+4

cloudflareApr 20, 2026

Building the agentic cloud: everything we launched during Agents Week 2026 (opens in new tab)

Cloudflare’s Agents Week 2026 introduced a broad set of infrastructure primitives for building and operating AI agents at scale. The company argues that agents require a new cloud model—“Cloud 2.0”—with elastic compute, built-in security, persistent state, specialized tools, and support for agent-driven web traffic. Its announcements span compute environments, identity and networking, developer tooling, inference, voice, email, and memory. ## Compute for Autonomous Agents - **Artifacts** provides Git-compatible, versioned storage for code and data. It supports tens of millions of repositories, remote forking, and access through standard Git clients. - **Cloudflare Sandboxes**, now generally available, give agents persistent isolated computers with shells, filesystems, and background processes. Environments can start on demand and resume where they left off. - **Outbound Workers for Sandboxes** act as programmable, zero-trust egress proxies. They let developers inject credentials and apply dynamic outbound security policies without exposing secrets to agent-generated code. - **Durable Object Facets** allow dynamically generated Workers to create isolated Durable Objects with their own SQLite databases, enabling stateful applications built on the fly. - **Workflows** was rearchitected to support up to 50,000 concurrent executions and a creation rate of 300, making it more suitable for durable, long-running background agents. ## Security, Identity, and Private Networking - **Cloudflare Mesh** provides private network access for users, infrastructure, Workers, and autonomous agents. Combined with Workers VPC, it enables scoped access to private databases and APIs without manually configured tunnels. - **Managed OAuth for Cloudflare Access** lets agents authenticate to internal applications on behalf of users using RFC 9728 rather than insecure shared service accounts. - New identity controls include scannable API tokens, improved OAuth visibility, and resource-scoped permissions to support least-privilege access and automated credential protection. - Cloudflare outlined an enterprise architecture for governing **MCP** deployments using Access, AI Gateway, and MCP server portals. - **Code Mode** reduces MCP token costs, while new Cloudflare Gateway rules help detect unauthorized or “Shadow MCP” usage. ## The Agent Toolbox - A new preview of the **Agents SDK**, called Project Think, aims to provide a more complete platform for agents that can reason, act, and persist. - An experimental **voice pipeline** supports real-time speech-to-text and text-to-speech over WebSockets, requiring roughly 30 lines of server-side code. - **Cloudflare Email Service** entered public beta, allowing agents to send, receive, and process email as a native communication channel. - Cloudflare’s AI platform is becoming a unified inference layer supporting models from more than 14 providers, including third-party model bindings for Workers and an expanded multimodal catalog. - Cloudflare also described a custom infrastructure stack for serving large language models efficiently on its global network. - **Unweight**, a lossless inference-time compression system, reduces model footprints by up to 22%, improving GPU memory efficiency and potentially lowering inference cost and latency. - **Agent Memory** was introduced as a managed service for giving agents persistent memory, though the provided article excerpt ends before detailing its full capabilities. Cloudflare’s announcements collectively position Workers and related services as a platform for the agentic cloud: one capable of running agents, securing their access, preserving their state, and supplying the models and communication tools they need to operate continuously at Internet scale.

sqlitecloudflareserverlessgit+4

cloudflareApr 17, 2026

Introducing Flagship: feature flags built for the age of AI (opens in new tab)

AI-generated code is moving toward autonomous production deployment, making safety and controlled rollout essential. The post argues that feature flags provide the guardrails: agents can deploy disabled code, test it with limited cohorts, monitor results, and roll back automatically. Cloudflare’s new Flagship service is designed for this workflow, evaluating flags at the edge through Workers, KV, and Durable Objects. ## Feature Flags for Autonomous Deployment - Agents can ship code behind an off flag without affecting users. - They can enable features for themselves or small test cohorts, observe metrics, and expand or disable rollouts. - Humans define boundaries while flags limit the blast radius. - This separates not only deployment from release, but also routine shipping decisions from constant human attention. ## Problems with Feature Flags on Workers - Hardcoded flags are initially convenient because Workers deploy quickly. - Over time, flags become fragmented across teams, with no central visibility or audit trail. - Troubleshooting may require searching version history with tools such as `git blame`. - Calling an external flag service adds a network request to every user request, potentially introducing significant latency. - This undermines the advantage of running applications close to users at the edge. ## Why Local Evaluation Is Difficult on Workers - Traditional local-evaluation SDKs download rules into a long-lived process. - Worker isolates may be created and evicted between requests, requiring repeated initialization. - Serverless environments therefore need a distribution system with edge-local reads and managed synchronization. - Flagship uses Cloudflare KV to provide this distribution without persistent connections or per-request external calls. ## How Flagship Works - Flagship is built on Workers, Durable Objects, and KV, without external databases or centralized evaluation servers. - Durable Objects provide a globally unique, SQLite-backed source of truth for flag configuration and changelogs. - Changes are synchronized to KV within seconds and replicated throughout Cloudflare’s network. - Evaluations read configuration from KV at the edge and execute targeting and rollout logic inside the Worker isolate. - Both flag data and evaluation logic remain close to the request. ## Worker Binding and Typed Evaluation - Workers connect Flagship through a `wrangler.jsonc` binding containing a binding name and `app_id`. - The binding supports typed methods including: - `getBooleanValue()` - `getStringValue()` - `getNumberValue()` - `getObjectValue()` - `*Details()` methods return the value, matched variant, and selection reason. - Evaluation errors return the supplied default value. - Type mismatches throw exceptions because they indicate application bugs rather than temporary service failures. ## OpenFeature Integration - Flagship is built on OpenFeature, the CNCF standard for feature-flag evaluation. - It supports Workers as well as Node.js, Bun, Deno, and browser environments. - The service is currently available in closed beta. Flagship is positioned as an edge-native feature-flag system for safely automating deployment and rollout. For Cloudflare Workers, its direct binding avoids network round-trips while providing centralized configuration, targeting, auditability, and controlled release mechanisms.

sqlitedatabase-designcloudflare-workersedge-computing+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.

sqlitedatabase-designdurable-objectsagents-sdk+4

cloudflareApr 15, 2026

Add voice to your agent (opens in new tab)

Cloudflare’s experimental `@cloudflare/voice` package adds real-time voice to existing Agents SDK applications without requiring a separate voice framework. Voice interactions use the same Durable Object, WebSocket connection, tools, and SQLite-backed history as text interactions. The package provides ready-made STT and TTS integrations while keeping provider interfaces open for alternative speech, telephony, and transport systems. ## Voice Support for Existing Agents - `withVoice(Agent)` enables full conversational voice agents. - `withVoiceInput(Agent)` supports speech-to-text-only features such as dictation and voice search. - React applications can use `useVoiceAgent` and `useVoiceInput`. - Framework-independent clients can use `VoiceClient`. - Built-in Workers AI providers include: - Deepgram Flux for continuous speech-to-text - Deepgram Nova 3 for speech-to-text - Deepgram Aura for text-to-speech - Developers can get started without external API keys. ## Minimal Server and Client Setup - A voice agent extends a class created with `withVoice(Agent)`. - The server configures a transcriber and TTS provider, then implements `onTurn()`. - `onTurn()` receives the user’s transcript and returns the agent’s response. - React clients can display: - Connection status - Interim and finalized transcripts - Conversation messages - Start, end, and mute controls - Non-React applications can connect through `@cloudflare/voice/client`. ## How the Voice Pipeline Works - The browser captures 16 kHz mono PCM microphone audio. - Audio streams over the agent’s existing WebSocket connection. - A continuous STT session remains active for the duration of the call. - The speech-to-text model detects completed utterances and produces stable transcripts. - Each transcript is passed to `onTurn()` for application or LLM logic. - The response is synthesized into audio and streamed back to the client. - Streamed responses can be sentence-chunked so audio begins playing before the full response is complete. - User and agent messages are persisted in the Durable Object’s SQLite database, surviving reconnections and deployments. ## Extensible Provider Architecture - The package is designed not to lock developers into one fixed voice stack. - Small provider interfaces allow speech, telephony, and transport providers to build integrations. - Developers can mix and match components based on their application’s requirements. - Voice therefore becomes another interaction mode for the same stateful agent rather than a separate application architecture. Cloudflare’s approach is best suited to developers who already use the Agents SDK and want to add conversational voice while preserving existing state, tools, persistence, and connection patterns. Since the package is experimental, teams should evaluate provider support and API stability before relying on it in production.

sqlitedatabase-designreactspeech-to-text+3

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.

sqlitedatabase-designdurable-objectsscalability+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.

sqlitedatabase-designcloudflarepostgresql+3

cloudflareMar 3, 2026

Evolving Cloudflare’s Threat Intelligence Platform: actionable, scalable, and ETL-less (opens in new tab)

Cloudflare’s Threat Intelligence Platform (TIP) is designed to turn massive volumes of security telemetry into actionable intelligence without relying on traditional ETL pipelines. Its sharded, SQLite-backed architecture uses Durable Objects and edge-based GraphQL to provide near-real-time analysis across millions of events. By combining automated telemetry with analyst investigations, the platform aims to help security teams understand threats and block them proactively. ## Motivation for Building the Platform - Cloudflare began developing the TIP after launching Cloudforce One in 2022 and discovering that existing tools could not adequately track adversary infrastructure. - The platform models the full threat lifecycle, connecting: - Threat actors to malware - Cases to indicators - Events to broader campaigns - It is designed for: - Multiple datasets and tenants - Group-based and tenant-to-tenant sharing - Extensibility and edge-scale performance - Visual analysis and automated response - Cloudflare Workers allow the platform to evolve with the runtime and support features such as Smart Placement, higher CPU limits, and Hyperdrive. ## Beyond the SIEM - The TIP complements rather than replaces a SIEM: - SIEMs focus on real-time log aggregation and alerting. - The TIP provides long-term retention, specialized threat schemas, and historical context. - Analysts can enrich alerts with: - Indicator history - Known threat-actor associations - Campaign relationships - Risk scores and intelligence context - Findings from analysts feed new indicators of compromise back into the platform. - This feedback loop keeps intelligence current and helps organizations move from reactive investigation to proactive defense. ## Sharded Storage Without ETL Bottlenecks - Cloudflare distributes Threat Events across many logical shards instead of using one centralized database. - Each shard is a Durable Object with a private SQLite database, providing transactional consistency and avoiding a single database bottleneck. - Cloudflare Queues handle asynchronous ingestion, helping absorb high-volume attack spikes. - R2 stores data for long-term retention, while SQLite maintains a hot index for fast access. - Because data is available directly in the platform’s operational store, complex ETL pipelines and synchronization delays are avoided. ## Parallel Queries at the Edge - GraphQL runs in the same Worker-based system that powers the Threat Events platform, keeping data live from ingestion through querying. - Queries are fanned out to relevant Durable Objects in parallel rather than executed against one large table. - The platform first verifies permissions and excludes shards that cannot contain matching events, such as shards outside the requested date range. - Results from multiple shards are aggregated with `Promise.all`, enabling low-latency searches across global datasets. - Smart Placement positions query Workers near the Durable Objects they access, reducing tail latency. Cloudflare’s approach combines edge-native storage, parallel execution, and analyst-driven enrichment to make threat intelligence both scalable and actionable. The practical goal is a unified system that explains not only what is malicious, but also why it matters and how to automatically prevent it.

sqlitedatabase-designcloudflare-workersgraphql+4