Developer Platform Updates & Release Notes

R2 SQL is Cloudflare's serverless, distributed, analytics query engine for querying Apache Iceberg ↗︎ tables stored in R2 Data Catalog.

R2 SQL now supports functions for querying JSON data stored in Apache Iceberg tables, an easier way to parse query plans with EXPLAIN FORMAT JSON, and querying tables without partition keys stored in R2 Data Catalog.

JSON functions extract and manipulate JSON values directly in SQL without client-side processing:

SELECT
  json_get_str(doc, 'name') AS name,
  json_get_int(doc, 'user', 'profile', 'level') AS level,
  json_get_bool(doc, 'active') AS is_active
FROM my_namespace.sales_data
WHERE json_contains(doc, 'email')

For a full list of available functions, refer to JSON functions.

EXPLAIN FORMAT JSON returns query execution plans as structured JSON for programmatic analysis and observability integrations:

npx wrangler r2 sql query "${WAREHOUSE}" "EXPLAIN FORMAT JSON SELECT * FROM logpush.requests LIMIT 10;"

┌──────────────────────────────────────┐
│ plan                                 │
├──────────────────────────────────────┤
│ {                                    │
│   "name": "CoalescePartitionsExec",  │ …

Logpush has traditionally been great at delivering Cloudflare logs to a variety of destinations in JSON format. While JSON is flexible and easily readable, it can be inefficient to store and query at scale.

With this release, you can now send your logs directly to Pipelines to ingest, transform, and store your logs in R2 as Parquet files or Apache Iceberg tables managed by R2 Data Catalog. This makes the data footprint more compact and more efficient at querying your logs instantly with R2 SQL or any other query engine that supports Apache Iceberg or Parquet.

Transform logs before storage

Pipelines SQL runs on each log record in-flight, so you can reshape your data before it is written. For example, you can drop noisy fields, redact sensitive values, or derive new columns:

INSERT INTO http_logs_sink
SELECT
  ClientIP,
  EdgeResponseStatus,
  to_timestamp_micros(EdgeStartTimestamp) AS event_time,
  upper(ClientRequestMethod) AS method,
  sha256(ClientIP) AS hashed_ip
FROM http_logs_stream
WHERE EdgeResponseStatus >= 400;
``` …

@cf/moonshotai/kimi-k2.6 is now available on Workers AI, in partnership with Moonshot AI for Day 0 support. Kimi K2.6 is a native multimodal agentic model from Moonshot AI that advances practical capabilities in long-horizon coding, coding-driven design, proactive autonomous execution, and swarm-based task orchestration.

Built on a Mixture-of-Experts architecture with 1T total parameters and 32B active per token, Kimi K2.6 delivers frontier-scale intelligence with efficient inference. It scores competitively against GPT-5.4 and Claude Opus 4.6 on agentic and coding benchmarks, including BrowseComp (83.2), SWE-Bench Verified (80.2), and Terminal-Bench 2.0 (66.7).

Key capabilities

• 262.1k token context window for retaining full conversation history, tool definitions, and codebases across long-running agent sessions
• Long-horizon coding with significant improvements on complex, end-to-end coding tasks across languages including Rust, Go, and Python
• Coding-driven design that transforms simple prompts and visual inputs into production-ready interfaces and full-stack workflows
• Agent swarm orchestration scaling horizontally to 300 sub-agents executing 4,000 coordinated steps for complex autonomous tasks
• Vision inputs for processing images alongside text
• Thinking mode with configurable reasoning depth …

New AI Search instances created after today will work differently. New instances come with built-in storage and a vector index, so you can upload a file, have it indexed immediately, and search it right away.

Additionally new Workers Bindings are now available to use with AI Search. The new namespace binding lets you create and manage instances at runtime, and cross-instance search API lets you query across multiple instances in one call.

Built-in storage and vector index

All new instances now comes with built-in storage which allows you to upload files directly to it using the Items API or the dashboard. No R2 buckets to set up, no external data sources to connect first.

const instance = env.AI_SEARCH.get("my-instance");

// upload and wait for indexing to complete
const item = await instance.items.uploadAndPoll("faq.md", content);

// search immediately after indexing
const results = await instance.search({
	messages: [{ role: "user", content: "onboarding guide" }],
});

Namespace binding

…

AI Search now supports hybrid search and relevance boosting, giving you more control over how results are found and ranked.

Hybrid search

Hybrid search combines vector (semantic) search with BM25 keyword search in a single query. Vector search finds chunks with similar meaning, even when the exact words differ. Keyword search matches chunks that contain your query terms exactly. When you enable hybrid search, both run in parallel and the results are fused into a single ranked list.

You can configure the tokenizer (porter for natural language, trigram for code), keyword match mode (and for precision, or for recall), and fusion method (rrf or max) per instance:

const instance = await env.AI_SEARCH.create({
	id: "my-instance",
	index_method: { vector: true, keyword: true },
	fusion_method: "rrf",
	indexing_options: { keyword_tokenizer: "porter" },
	retrieval_options: { keyword_match_mode: "and" },
});

Refer to Search modes for an overview and Hybrid search for configuration details.

Relevance boosting

…

Artifacts is now in private beta. Artifacts is Git-compatible storage built for scale: create tens of millions of repos, fork from any remote, and hand off a URL to any Git client. It provides a versioned filesystem for storing and exchanging file trees across Workers, the REST API, and any Git client, running locally or within an agent.

You can read the announcement blog ↗︎ to learn more about what Artifacts does, how it works, and how to create repositories for your agents to use.

Artifacts has three API surfaces:

• Workers bindings (for creating and managing repositories)
• REST API (for creating and managing repos from any other compute platform)
• Git protocol (for interacting with repos)

As an example: you can use the Workers binding to create a repo and read back its remote URL:

# Create a thousand, a million or ten million repos: one for every agent, for every upstream branch, or every user.
const created = await env.PROD_ARTIFACTS.create("agent-007");
const remote = (await created.repo.info())?.remote;

Or, use the REST API to create a repo inside a namespace from your agent(s) running on any platform:

curl --request POST "https://artifacts.cloudflare.net/v1/api/namespaces/some-namespace/repos" --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" --header "Content-Type: application/json" --data '{"name":"agent-007"}'
``` …

Email Sending is now in public beta. Send transactional emails directly from Workers (env.EMAIL.send()) or the REST API, with support for HTML, plain text, attachments, inline images, and custom headers. Email Sending joins Email Routing ↗︎ under the new Cloudflare Email Service — a single service for sending and receiving email on the Cloudflare developer platform.

Send an email from a Worker in a few lines of code:

src/index.jsjs

export default {
	async fetch(request, env) {
		const response = await env.EMAIL.send({
			from: "notifications@yourdomain.com",
			to: "user@example.com",
			subject: "Order confirmed",
			html: "<h1>Your order has been confirmed</h1>",
			text: "Your order has been confirmed.",
		});

		return Response.json({ messageId: response.messageId });
	},
};

src/index.tsts

export default {
	async fetch(request, env): Promise<Response> {
		const response = await env.EMAIL.send({
			from: "notifications@yourdomain.com",
			to: "user@example.com",
			subject: "Order confirmed",
			html: "<h1>Your order has been confirmed</h1>",
			text: "Your order has been confirmed.",
		});

		return Response.json({ messageId: response.messageId });
	},
} satisfies ExportedHandler<Env>;
``` …

Workflows limits have been raised to the following:

Limit

Previous

New

Concurrent instances (running in parallel)

10,000

50,000

Instance creation rate (per account)

100/second per account

300/second per account, 100/second per workflow

Queued instances per Workflow 1

1 million

2 million

These increases apply to all users on the Workers Paid plan. Refer to the Workflows limits documentation for more details.

Footnotes

1. Queued instances are instances that have been created or awoken and are waiting for a concurrency slot. ↩

We are renaming Browser Rendering to Browser Run. The name Browser Rendering never fully captured what the product does. Browser Run lets you run full browser sessions on Cloudflare's global network, drive them with code or AI, record and replay sessions, crawl pages for content, debug in real time, and let humans intervene when your agent needs help.

Along with the rename, we have increased limits for Workers Paid plans and redesigned the Browser Run dashboard.

We have 4x-ed concurrency limits for Workers Paid plan users:

• Concurrent browsers per account: 30 → 120 per account
• New browser instances: 30 per minute → 1 per second
• REST API rate limits: recently increased from 3 to 10 requests per second

Rate limits across the limits page are now expressed in per-second terms, matching how they are enforced. No action is needed to benefit from the higher limits.

The redesigned dashboard ↗︎ now shows every request in a single Runs tab, not just browser sessions but also quick actions like screenshots, PDFs, markdown, and crawls. Filter by endpoint, view target URLs, status, and duration, and expand any row for more detail. …

When browser automation fails or behaves unexpectedly, it can be hard to understand what happened. We are shipping three new features in Browser Run (formerly Browser Rendering) to help:

• Live View for real-time visibility
• Human in the Loop for human intervention
• Session Recordings for replaying sessions after they end

Live View

Live View lets you see what your agent is doing in real time. The page, DOM, console, and network requests are all visible for any active browser session. Access Live View from the Cloudflare dashboard, via the hosted UI at live.browser.run, or using native Chrome DevTools.

Human in the Loop

When your agent hits a snag like a login page or unexpected edge case, it can hand off to a human instead of failing. With Human in the Loop, a human steps into the live browser session through Live View, resolves the issue, and hands control back to the script. …

Browser Run (formerly Browser Rendering) now supports WebMCP ↗︎ (Web Model Context Protocol), a new browser API from the Google Chrome team.

The Internet was built for humans, so navigating as an AI agent today is unreliable. WebMCP lets websites expose structured tools for AI agents to discover and call directly. Instead of slow screenshot-analyze-click loops, agents can call website functions like searchFlights() or bookTicket() with typed parameters, making browser automation faster, more reliable, and less fragile.

Browser Run lab session showing WebMCP tools being discovered and executed in the Chrome DevTools console to book a hotel

With WebMCP, you can:

• Discover website tools - Use navigator.modelContextTesting.listTools() to see available actions on any WebMCP-enabled site
• Execute tools directly - Call navigator.modelContextTesting.executeTool() with typed parameters
• Handle human-in-the-loop interactions - Some tools pause for user confirmation before completing sensitive actions

WebMCP requires Chrome beta features. We have an experimental pool with browser instances running Chrome beta so you can test emerging browser features before they reach stable Chrome. To start a WebMCP session, add lab=true to your /devtools/browser request:

Agent Lee adds Write Operations and Generative UI

We are excited to announce two major capability upgrades for Agent Lee, the AI co-pilot built directly into the Cloudflare dashboard. Agent Lee is designed to understand your specific account configuration, and with this release, it moves from a passive advisor to an active assistant that can help you manage your infrastructure and visualize your data through natural language.

Take action with Write Operations

Agent Lee can now perform changes on your behalf across your Cloudflare account. Whether you need to update DNS records, modify SSL/TLS settings, or configure Workers routes, you can simply ask.

To ensure security and accuracy, every write operation requires explicit user approval. Before any change is committed, Agent Lee will present a summary of the proposed action in plain language. No action is taken until you select Confirm, and this approval requirement is enforced at the infrastructure level to prevent unauthorized changes.

Example requests:

• "Add an A record for blog.example.com pointing to 192.0.2.10."
• "Enable Always Use HTTPS on my zone."
• "Set the SSL mode for example.com to Full (strict)."

Visualize data with Generative UI

…

Privacy Proxy metrics are now queryable through Cloudflare's GraphQL Analytics API, the new default method for accessing Privacy Proxy observability data. All metrics are available through a single endpoint:

curl https://api.cloudflare.com/client/v4/graphql \
  --header "Authorization: Bearer <API_TOKEN>" \
  --header "Content-Type: application/json" \
  --data '{
    "query": "{ viewer { accounts(filter: { accountTag: $accountTag }) { privacyProxyRequestMetricsAdaptiveGroups(filter: { date_geq: $startDate, date_leq: $endDate }, limit: 10000, orderBy: [date_ASC]) { count dimensions { date } } } } }",
    "variables": {
      "accountTag": "<YOUR_ACCOUNT_TAG>",
      "startDate": "2026-04-04",
      "endDate": "2026-04-06"
    }
  }'

Available nodes

Four GraphQL nodes are now live, providing aggregate metrics across all key dimensions of your Privacy Proxy deployment:

• privacyProxyRequestMetricsAdaptiveGroups — Request volume, error rates, status codes, and proxy status breakdowns.
• privacyProxyIngressConnMetricsAdaptiveGroups — Client-to-proxy connection counts, bytes transferred, and latency percentiles.
• privacyProxyEgressConnMetricsAdaptiveGroups — Proxy-to-origin connection counts, bytes transferred, and latency percentiles.
• privacyProxyAuthMetricsAdaptiveGroups — Authentication attempt counts by method and result. …

Browser Rendering now supports wrangler browser commands, letting you create, manage, and view browser sessions directly from your terminal, streamlining your workflow. Since Wrangler handles authentication, you do not need to pass API tokens in your commands.

The following commands are available:

Command

Description

wrangler browser create

Create a new browser session

wrangler browser close

Close a session

wrangler browser list

List active sessions

wrangler browser view

View a live browser session

The create command spins up a browser instance on Cloudflare's network and returns a session URL. Once created, you can connect to the session using any CDP-compatible client like Puppeteer, Playwright, or MCP clients to automate browsing, scrape content, or debug remotely.

wrangler browser create

Use --keepAlive to set the session keep-alive duration (60-600 seconds):

wrangler browser create --keepAlive 300

The view command auto-selects when only one session exists, or prompts for selection when multiple sessions are available. …

VPC Network bindings now give your Workers access to any service in your private network without pre-registering individual hosts or ports. This complements existing VPC Service bindings, which scope each binding to a specific host and port.

You can bind to a Cloudflare Tunnel by tunnel_id to reach any service on the network where that tunnel is running, or bind to your Cloudflare Mesh network using cf1:network to reach any Mesh node, client device, or subnet route in your account:

{
  "vpc_networks": [
    {
      "binding": "MESH",
      "network_id": "cf1:network",
      "remote": true
    }
  ]
}

[[vpc_networks]]
binding = "MESH"
network_id = "cf1:network"
remote = true

At runtime, fetch() routes through the network to reach the service at the IP and port you specify:

const response = await env.MESH.fetch("http://10.0.1.50:8080/api/data");

For configuration options and examples, refer to VPC Networks and Connect Workers to Cloudflare Mesh.

Cloudflare Containers and Sandboxes are now generally available.

Containers let you run more workloads on the Workers platform, including resource-intensive applications, different languages, and CLI tools that need full Linux environments.

Since the initial launch of Containers, there have been significant improvements to Containers' performance, stability, and feature set. Some highlights include:

• Higher limits allow you to run thousands of containers concurrently.
• Active-CPU pricing means that you only pay for used CPU cycles.
• Easy connections to Workers and other bindings via hostnames help you extend your Containers with additional functionality.
• Docker Hub support makes it easy to use your existing images and registries.
• SSH support helps you access and debug issues in live containers. …

Outbound Workers for Sandboxes and Containers now support zero-trust credential injection, TLS interception, allow/deny lists, and dynamic per-instance egress policies. These features give platforms running agentic workloads full control over what leaves the sandbox, without exposing secrets to untrusted workloads, like user-generated code or coding agents.

Credential injection

Because outbound handlers run in the Workers runtime, outside the sandbox, they can hold secrets the sandbox never sees. A sandboxed workload can make a plain request, and credentials are transparently attached before a request is forwarded upstream.

For instance, you could run an agent in a sandbox and ensure that any requests it makes to Github are authenticated. But it will never be able to access the credentials:

export class MySandbox extends Sandbox {}

MySandbox.outboundByHost = {
	"github.com": (request: Request, env: Env, ctx: OutboundHandlerContext) => {
		const requestWithAuth = new Request(request);
		requestWithAuth.headers.set("x-auth-token", env.SECRET);
		return fetch(requestWithAuth);
	},
};

You can easily inject unique credentials for different instances by using ctx.containerId:

MySandbox.outboundByHost = {
	"my-internal-vcs.dev": async (
		request: Request,
		env: Env,
		ctx: OutboundHandlerContext,
	) => { …

Local Explorer is a browser-based interface and REST API for viewing and editing local resource data during development. It removes the need to write throwaway scripts or dig through .wrangler/state to understand what data your Worker has stored locally.

Local Explorer is available in Wrangler 4.82.1+ and the Cloudflare Vite plugin 1.32.0+. Start a local development session and press e in your terminal, or navigate to /cdn-cgi/local/explorer on your local dev server.

Supported resources

Local Explorer supports five resource types and works across multiple workers running locally:

• KV — Browse keys, view values and metadata, create, update, and delete key-value pairs.
• R2 — List objects, view metadata, upload files, and delete objects. Supports directory views and multi-select.
• D1 — Browse tables and rows, run arbitrary SQL queries, and edit schemas in a full data studio.
• Durable Objects (SQLite storage) — Browse individual object SQLite tables, run SQL queries, and edit schemas.
• Workflows — List instances, view status and step history, trigger new runs, and pause, resume, restart, or terminate instances.

OpenAPI-powered REST API

…

Browser Rendering now exposes the Chrome DevTools Protocol (CDP), the low-level protocol that powers browser automation. The growing ecosystem of CDP-based agent tools, along with existing CDP automation scripts, can now use Browser Rendering directly.

Any CDP-compatible client, including Puppeteer and Playwright, can connect from any environment, whether that is Cloudflare Workers, your local machine, or a cloud environment. All you need is your Cloudflare API key.

For any existing CDP script, switching to Browser Rendering is a one-line change:

const puppeteer = require("puppeteer-core");

const browser = await puppeteer.connect({
	browserWSEndpoint: `wss://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/browser-rendering/devtools/browser?keep_alive=600000`,
	headers: { Authorization: `Bearer ${API_TOKEN}` },
});

const page = await browser.newPage();
await page.goto("https://example.com");
console.log(await page.title());
await browser.close();

Additionally, MCP clients like Claude Desktop, Claude Code, Cursor, and OpenCode can now use Browser Rendering as their remote browser via the chrome-devtools-mcp ↗︎ package. …

The simultaneous open connections limit has been relaxed. Previously, each Worker invocation was limited to six open connections at a time for the entire lifetime of each connection, including while reading the response body. Now, a connection is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial "waiting for headers" phase simultaneously.

Before: New connections are blocked until an earlier connection fully completes

A 7th fetch is queued until an earlier connection fully completes, including reading its entire response body

After: New connections can start as soon as response headers arrive

A 7th fetch starts as soon as any earlier connection receives its response headers …