---
title: Developer platform Changelog
image: https://edgetunnel-b2h.pages.dev/cf-twitter-card.png
---

> Documentation Index  
> Fetch the complete documentation index at: https://edgetunnel-b2h.pages.dev/changelog/llms.txt  
> Use this file to discover all available pages before exploring further. 

[Skip to content](#%5Ftop) 

# Changelog

New updates and improvements at Cloudflare.

[ Subscribe to RSS ](https://edgetunnel-b2h.pages.dev/changelog/rss/index.xml) [ View RSS feeds ](https://edgetunnel-b2h.pages.dev/fundamentals/new-features/available-rss-feeds/) 

Developer platform

![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) 

Jun 12, 2026
1. ### [View the user agent of requests in AI Gateway logs](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-12-user-agent-logging/)  
[ AI Gateway ](https://edgetunnel-b2h.pages.dev/ai-gateway/)  
AI Gateway logs now capture the user agent of the client that made each request, making it easier to identify which SDK, library, or application sent the traffic flowing through your gateway. For example, you can tell apart requests coming from `openai-python` versus a custom application or a Cloudflare Worker.  
The user agent appears alongside the other details in each log entry, and you can filter logs by user agent (equals, does not equal, or contains) in the dashboard.  
For more information, refer to [Logging](https://edgetunnel-b2h.pages.dev/ai-gateway/observability/logging/).

Jun 12, 2026
1. ### [Filter Durable Objects metrics by object ID or name](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-12-durable-objects-metrics-filter-by-id-name/)  
[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now filter the **Metrics** tab for a Durable Objects namespace by an individual Durable Object's [ID](https://edgetunnel-b2h.pages.dev/durable-objects/api/id/) or [name](https://edgetunnel-b2h.pages.dev/durable-objects/api/id/#name) in the Cloudflare dashboard. Previously, metrics charts only showed aggregate, namespace-level data, making it difficult to isolate the behavior of a specific object.  
[ Go to **Durable Objects** ](https://dash.cloudflare.com/?to=/:account/workers/durable-objects) ![The Durable Objects Metrics tab filtered to a single object by ID, showing per-object requests and errors by invocation status.](https://edgetunnel-b2h.pages.dev/_astro/durable-objects-metrics-dashboard.BFZTyhWU_Z2e46Sb.webp)  
Start typing an ID or name into the filter and select a match from the autocomplete dropdown. The autocomplete only shows objects with invocations during the selected time range, so an object that does not appear has not been invoked in that window. This does not necessarily mean the object has been deleted. Every chart on the page updates to reflect only the selected object. This makes it easier to identify and investigate a single Durable Object when debugging a high-traffic object, an error spike, or unexpected storage usage. Clear the filter to return to namespace-level metrics.  
Metrics are powered by the [GraphQL Analytics API](https://edgetunnel-b2h.pages.dev/analytics/graphql-api/), so standard analytics behavior such as ingestion delay and [sampling](https://edgetunnel-b2h.pages.dev/analytics/faq/graphql-api-inconsistent-results/) applies.  
For more information, refer to [Metrics and analytics](https://edgetunnel-b2h.pages.dev/durable-objects/observability/metrics-and-analytics/).

Jun 12, 2026
1. ### [Terraform v5.20.0 now available](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-12-terraform-v5200-provider/)  
[ Terraform ](https://edgetunnel-b2h.pages.dev/terraform/)  
Cloudflare's Terraform v5 Provider makes it easy for developers to manage their Cloudflare infrastructure using a configuration as code approach. It releases every [2-3 weeks ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/5774) to ensure that you can always manage the latest features in the platform. This week, we launched Terraform v5.20.0, which adds 24 new resources, bumps the underlying Go SDK to cloudflare-go v7, and includes a range of bug fixes and state upgraders based on community feedback.  
#### New resources

  * **cloudflare\_ai\_search\_namespace:** Manage AI Search namespaces
  * **cloudflare\_custom\_csr:** Manage custom certificate signing requests
  * **cloudflare\_dls\_prefix\_binding:** Manage DLS regional service prefix bindings
  * **cloudflare\_flagship\_app:** Manage Flagship feature flag apps
  * **cloudflare\_flagship\_flag:** Manage Flagship feature flags
  * **cloudflare\_google\_tag\_gateway:** Manage Google Tag Gateway
  * **cloudflare\_load\_balancer\_monitor\_group:** Manage load balancer monitor groups
  * **cloudflare\_oauth\_client:** Manage IAM OAuth clients
  * **cloudflare\_origin\_cloud\_region:** Manage origin cloud regions (v2 endpoints)
  * **cloudflare\_secrets\_store:** Manage Secrets Store instances
  * **cloudflare\_secrets\_store\_secret:** Manage Secrets Store secrets
  * **cloudflare\_share:** Manage resource shares
  * **cloudflare\_share\_recipient:** Manage share recipients
  * **cloudflare\_share\_resource:** Manage shared resources
  * **cloudflare\_zero\_trust\_device\_deployment\_groups:** Manage Zero Trust device deployment groups
  * **cloudflare\_zero\_trust\_dlp\_data\_class:** Manage DLP data classes
  * **cloudflare\_zero\_trust\_dlp\_data\_tag:** Manage DLP data tags
  * **cloudflare\_zero\_trust\_dlp\_data\_tag\_category:** Manage DLP data tag categories
  * **cloudflare\_zero\_trust\_dlp\_sensitivity\_group:** Manage DLP sensitivity groups
  * **cloudflare\_zero\_trust\_dlp\_sensitivity\_level:** Manage DLP sensitivity levels
  * **cloudflare\_zero\_trust\_dlp\_sensitivity\_level\_order:** Manage DLP sensitivity level ordering
  * **cloudflare\_zero\_trust\_resource\_library\_application:** Manage Zero Trust resource library applications
  * **cloudflare\_zero\_trust\_resource\_library\_category:** Manage Zero Trust resource library categories
  * **cloudflare\_zero\_trust\_tunnel\_warp\_connector\_config:** Manage WARP connector tunnel configurations  
#### Features

  * **cache:** add create (POST) method for smart\_tiered\_cache
  * **cache:** update OPCR config to v2 endpoints
  * **dlp:** promote classification Stainless config to main
  * **dlp:** add custom prompt topics endpoint
  * **email\_security\_block\_sender:** state upgrader for v4 to v5 migration
  * **email\_security\_impersonation\_registry:** state upgrader for v4 to v5 migration
  * **email\_security\_trusted\_domains:** state upgrader for v4 to v5 migration
  * **snippets:** add Terraform `id_property` annotations for snippet and snippet\_rules
  * bump Go SDK to cloudflare-go v7  
#### Bug fixes

  * **account\_member:** missing upgrade path from v5.0–v5.15
  * **authenticated\_origin\_pulls\_settings:** nil pointer panic
  * **bot\_management:** restore `content_bots_protection` handling in model.go
  * **dns\_record:** prevent FQDN normalization from swallowing name shortening changes
  * **list:** nullify empty nested objects to prevent inconsistent result after apply
  * **load\_balancer\_pool:** accept early-v5 object-shape state at schema\_version=0
  * **load\_balancer\_pool:** add `UseStateForUnknown` for `load_shedding` attribute to prevent drift
  * **r2\_custom\_domain:** restore degraded-response handling in resource.go
  * **regional\_hostname:** update cloudflare-go imports from v6 to v7
  * **secrets\_store:** fix model/schema parity and guard acceptance tests
  * **spectrum\_application:** accept early-v5 object-shape state at schema\_version=0
  * **worker:** preserve `observability.traces.propagation_policy` across reads
  * **worker:** add `propagation_policy` to observability defaults
  * **worker\_version:** restore handwritten D1 `database_id` handling
  * **workers\_custom\_domain:** missing `CertId` field in state migration
  * **workers\_script:** restore annotations Read workaround stripped by codegen
  * **zero\_trust\_access\_identity\_provider:** change `read_only` from computed to optional
  * **zero\_trust\_access\_identity\_provider:** add `UseStateForUnknown` to SAML-only config fields
  * **zero\_trust\_access\_identity\_provider:** use `UseNonNullStateForUnknown` on scim\_config fields
  * **zero\_trust\_access\_policy:** populate `account_id` when migrating zone-scoped v4 state
  * **zero\_trust\_access\_policy:** missing `common_names` transform in migration
  * gracefully handle nil pointer dereference when config has `attributes_flat` during migration
  * set initial schema version to 500 for all new resources  
#### Refactors  
Extracted `MoveState` nil guard into shared helper  
#### For more information

  * [Terraform Provider ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs)
  * [Version 5 Migration Guide ↗](https://registry.terraform.io/providers/cloudflare/cloudflare/latest/docs/guides/version-5-migration)
  * [Documentation on using Terraform with Cloudflare](https://edgetunnel-b2h.pages.dev/terraform/)
  * [List of stabilized resources ↗](https://github.com/cloudflare/terraform-provider-cloudflare/issues/6237)

Jun 12, 2026
1. ### [Moonshot AI Kimi K2.7 Code now available on Workers AI](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-12-kimi-k2-7-code-workers-ai/)  
[ Workers AI ](https://edgetunnel-b2h.pages.dev/workers-ai/)  
[@cf/moonshotai/kimi-k2.7-code](https://edgetunnel-b2h.pages.dev/workers-ai/models/kimi-k2.7-code/) is now available on Workers AI. Kimi K2.7 Code is a code-optimized variant of the Kimi K2 family, built on a Mixture-of-Experts architecture with 1T total parameters and 32B active per token.  
#### Improved coding and agent performance  
K2.7 Code delivers meaningful gains over K2.6 on coding and agentic benchmarks:

  * **+21.8%** on Kimi Code Bench v2
  * **+11.0%** on Program Bench
  * **+31.5%** on MLS Bench Lite  
#### Reasoning efficiency  
K2.7 Code uses 30% fewer reasoning tokens compared to K2.6, reducing overthinking and lowering inference cost for reasoning-heavy workloads.  
#### 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 improved instruction following and higher end-to-end coding task success rates
  * **Vision inputs** for processing images alongside text
  * **Thinking mode** with configurable reasoning depth via `chat_template_kwargs.thinking`
  * **Multi-turn tool calling** for building agents that invoke tools across multiple conversation turns
  * **Structured outputs** with JSON schema support  
#### Differences from Kimi K2.6  
If you are migrating from Kimi K2.6, note the following:

  * K2.7 Code is optimized for coding tasks with improved benchmark performance and reasoning efficiency
  * Cached input token pricing is $0.19 per M tokens (vs $0.16 for K2.6)
  * API usage is identical — no parameter changes required  
#### Get started  
Use Kimi K2.7 Code through the [Workers AI binding](https://edgetunnel-b2h.pages.dev/workers-ai/configuration/bindings/) (`env.AI.run()`), the REST API at `/ai/run`, or the OpenAI-compatible endpoint at `/v1/chat/completions`. You can also use [AI Gateway](https://edgetunnel-b2h.pages.dev/ai-gateway/) with any of these endpoints.  
For more information, refer to the [Kimi K2.7 Code model page](https://edgetunnel-b2h.pages.dev/workers-ai/models/kimi-k2.7-code/) and [pricing](https://edgetunnel-b2h.pages.dev/workers-ai/platform/pricing/).

Jun 11, 2026
1. ### [New formats parameter for the Browser Run /snapshot endpoint](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-11-browser-run-snapshot-formats/)  
[ Browser Run ](https://edgetunnel-b2h.pages.dev/browser-run/)  
[Browser Run](https://edgetunnel-b2h.pages.dev/browser-run/)'s [/snapshot endpoint](https://edgetunnel-b2h.pages.dev/browser-run/quick-actions/snapshot/) now supports a `formats` parameter that lets you return multiple page formats in a single API call. Previously, `/snapshot` returned only HTML content and a screenshot. You can now also include Markdown and the accessibility tree in the same response.  
These formats are particularly useful for AI agent workflows:

  * Markdown provides a token-efficient representation of page content that LLMs can process directly, without parsing HTML markup.
  * The accessibility tree provides a structured representation of a page's elements, including roles, labels, and hierarchy, helping LLMs understand page structure and navigate its contents.  
The following example returns a screenshot, Markdown, and the accessibility tree in one call:

  * [ curl ](#tab-panel-3384)
  * [ TypeScript SDK ](#tab-panel-3385)
  * [ Workers Bindings ](#tab-panel-3386)  
```bash  
curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-rendering/snapshot' \
  -H 'Authorization: Bearer <apiToken>' \
  -H 'Content-Type: application/json' \
  -d '{  
    "url": "https://example.com/",  
    "formats": ["screenshot", "markdown", "accessibilityTree"]  
  }'  
```

**TypeScript**  
```typescript  
import Cloudflare from "cloudflare";  
const client = new Cloudflare({  
  apiToken: process.env["CLOUDFLARE_API_TOKEN"],  
});  
const snapshot = await client.browserRendering.snapshot.create({  
  account_id: process.env["CLOUDFLARE_ACCOUNT_ID"],  
  url: "https://example.com/",  
  formats: ["screenshot", "markdown", "accessibilityTree"],  
});  
console.log(snapshot.markdown);  
console.log(snapshot.accessibilityTree);  
```

**TypeScript**  
```typescript  
interface Env {  
  BROWSER: BrowserRun;  
}  
export default {  
  async fetch(request, env): Promise<Response> {  
    return await env.BROWSER.quickAction("snapshot", {  
      url: "https://example.com/",  
      formats: ["screenshot", "markdown", "accessibilityTree"],  
    });  
  },  
} satisfies ExportedHandler<Env>;  
```  
You must request at least two formats. If you only need one, use the respective single-format endpoint such as [/screenshot](https://edgetunnel-b2h.pages.dev/browser-run/quick-actions/screenshot-endpoint/) or [/markdown](https://edgetunnel-b2h.pages.dev/browser-run/quick-actions/markdown-endpoint/).  
Refer to the [/snapshot documentation](https://edgetunnel-b2h.pages.dev/browser-run/quick-actions/snapshot/) for the full list of accepted values.

Jun 11, 2026
1. ### [Track Dynamic Workers usage from the dashboard and GraphQL API](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-11-dynamic-workers-count/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
![Dynamic Workers usage on the Workers overview page](https://edgetunnel-b2h.pages.dev/_astro/dynamic-workers-count.BcGsgQ0m_ZBdT2X.webp)  
Customers can now view the number of [Dynamic Workers](https://edgetunnel-b2h.pages.dev/dynamic-workers/) invoked during their billing period from the Workers overview page in the Cloudflare dashboard.  
This count reflects the number of Dynamic Workers that Cloudflare would bill for during the selected billing period. Dynamic Workers usage data only goes back to June 1, 2026.  
You can also query this count through the [GraphQL Analytics API](https://edgetunnel-b2h.pages.dev/analytics/graphql-api/) by using `workersInvocationsByOwnerAndScriptGroups` and selecting `distinctDynamicWorkerCount`:  
```graphql  
query getDynamicWorkersCount(  
  $accountTag: string!  
  $filter: AccountWorkersInvocationsByOwnerAndScriptGroupsFilter_InputObject  
) {  
  viewer {  
    accounts(filter: { accountTag: $accountTag }) {  
      workersInvocationsByOwnerAndScriptGroups(limit: 10000, filter: $filter) {  
        uniq {  
          distinctDynamicWorkerCount  
        }  
      }  
    }  
  }  
}  
```  
Use variables to set the account and billing-period date range:  
```json  
{  
  "accountTag": "<ACCOUNT_ID>",  
  "filter": {  
    "date_geq": "2026-06-01",  
    "date_leq": "2026-06-30"  
  }  
}  
```  
For more information, refer to [Dynamic Workers pricing](https://edgetunnel-b2h.pages.dev/dynamic-workers/pricing/).

Jun 10, 2026
1. ### [Manage AI Search namespaces with Wrangler CLI](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-ai-search-namespace-wrangler-commands/)  
[ AI Search ](https://edgetunnel-b2h.pages.dev/ai-search/)  
[AI Search](https://edgetunnel-b2h.pages.dev/ai-search/) now supports namespace-level Wrangler commands, making it easier to manage [namespaces](https://edgetunnel-b2h.pages.dev/ai-search/concepts/namespaces/) from your terminal, scripts, and agent workflows.  
The following commands are available:

| Command                             | Description                      |
| ----------------------------------- | -------------------------------- |
| wrangler ai-search namespace list   | List AI Search namespaces        |
| wrangler ai-search namespace create | Create a new AI Search namespace |
| wrangler ai-search namespace get    | Get details for a namespace      |
| wrangler ai-search namespace update | Update a namespace description   |
| wrangler ai-search namespace delete | Delete an AI Search namespace    |  
Create a namespace for a new application or tenant directly from the CLI:  
```sh  
wrangler ai-search namespace create docs-production --description "Production documentation search"  
```  
List namespaces with pagination or filter by name or description:  
```sh  
wrangler ai-search namespace list --search docs --page 1 --per-page 10  
```  
Use `--json` with `list`, `create`, `get`, and `update` to return structured output that automation and AI agents can parse directly.  
Instance-level commands also now support a `--namespace` flag, so you can interact with instances inside a specific namespace from the CLI:  
```sh  
wrangler ai-search list --namespace docs-production  
```  
For full usage details, refer to the [AI Search Wrangler commands documentation](https://edgetunnel-b2h.pages.dev/ai-search/wrangler-commands/).

Jun 10, 2026
1. ### [Flagship API reference now available](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-api-reference/)  
[ Flagship ](https://edgetunnel-b2h.pages.dev/flagship/)  
The **[Flagship API reference](https://edgetunnel-b2h.pages.dev/api/resources/flagship/)** is now available. You can use the Cloudflare API to create and update apps, and to create, update, delete, and list feature flags without using the dashboard.  
For example, create a new boolean flag with the API:  
```bash  
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/flagship/apps/$APP_ID/flags \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -d '{  
    "key": "new-checkout",  
    "enabled": true,  
    "default_variation": "off",  
    "variations": {  
      "off": false,  
      "on": true  
    },  
    "rules": []  
  }'  
```  
To create an API token, go to [Account API Tokens ↗](https://dash.cloudflare.com/?to=/:account/api-tokens) in the Cloudflare dashboard and search for Flagship.  
The API reference includes endpoints for Flagship apps, flags, changelog entries, and flag evaluation. Agents can also use the [Flagship reference in the Cloudflare skill ↗](https://github.com/cloudflare/skills/tree/main/skills/cloudflare/references/flagship) to create and manage Flagship resources.  
Refer to the [Flagship documentation](https://edgetunnel-b2h.pages.dev/flagship/) to learn more about evaluating feature flags from your applications.

Jun 10, 2026
1. ### [Manage hosted images with the Images binding](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-hosted-images-binding/)  
[ Cloudflare Images ](https://edgetunnel-b2h.pages.dev/images/)  
Use the Images binding to upload, list, retrieve, update, and delete images stored in Images directly from your Worker without managing API tokens or making HTTP requests.  
The `env.IMAGES.hosted` namespace supports the following storage and management operations:

  * [.upload(image, options)](https://edgetunnel-b2h.pages.dev/images/storage/binding/#uploadimage-options) — Upload a new image to your account.
  * [.list(options)](https://edgetunnel-b2h.pages.dev/images/storage/binding/#listoptions) — List images with pagination.
  * [.image(imageId).details()](https://edgetunnel-b2h.pages.dev/images/storage/binding/#imageimageiddetails) — Get image metadata.
  * [.image(imageId).bytes()](https://edgetunnel-b2h.pages.dev/images/storage/binding/#imageimageidbytes) — Stream the original image bytes.
  * [.image(imageId).update(options)](https://edgetunnel-b2h.pages.dev/images/storage/binding/#imageimageidupdateoptions) — Update metadata or access controls.
  * [.image(imageId).delete()](https://edgetunnel-b2h.pages.dev/images/storage/binding/#imageimageiddelete) — Delete an image.  
For example, you can upload an image from a request body and return its metadata:

**TypeScript**  
```ts  
const image = await env.IMAGES.hosted.upload(request.body, {  
  filename: "upload.jpg",  
  metadata: { source: "worker" },  
});  
return Response.json(image);  
```  
Or retrieve and serve the original bytes of a hosted image:

**TypeScript**  
```ts  
const bytes = await env.IMAGES.hosted.image("IMAGE_ID").bytes();  
return new Response(bytes);  
```  
For more information, refer to the [Images binding](https://edgetunnel-b2h.pages.dev/images/storage/binding/).

Jun 09, 2026
1. ### [Deprecating Sandbox SDK features](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-09-deprecating-sandbox-sdk-features/)  
[ Sandbox SDK ](https://edgetunnel-b2h.pages.dev/sandbox/)  
Today we are announcing the deprecation of several features from the Sandbox SDK. The SDK has grown and matured substantially since it first launched. As agent workflows have developed, we have shipped many new features and experiments so developers can easily integrate secure, isolated code execution into their workflows.  
We want the SDK to continue providing a stable foundation for agentic workflows while we iterate quickly on the codebase. These deprecated features have either been superseded by newer capabilities or seen low adoption. They will remain in the codebase until July 9, 2026, after which they will no longer be present in future Sandbox SDK versions.  
#### HTTP and WebSocket transports  
In April 2026, we released the new RPC transport and deprecated the WebSocket transport. This setting governs how the sandbox container talks to the Workers ecosystem. The RPC transport removes the limitations of both the HTTP and WebSocket transports. As of June 9, 2026, it is the recommended default. HTTP and WebSocket transports will no longer be present in Sandbox SDK versions released after July 9, 2026.  
To migrate before July 9, 2026, update the `SANDBOX_TRANSPORT` variable to `rpc` or set the `transport` option when calling `getSandbox()`. For more information, refer to the [transport configuration documentation](https://edgetunnel-b2h.pages.dev/sandbox/configuration/transport/).  
#### Desktop  
The desktop feature landed as a technical demonstration of what can be done with the Sandbox SDK — controlling a full browser environment from within a sandbox. With [Cloudflare Browser Run](https://edgetunnel-b2h.pages.dev/browser-run/) now available, this feature saw very little use. We have removed it in `0.10.2`.  
#### Expose ports  
We recently released support for Cloudflare Tunnel in the Sandbox SDK. This provides a robust API for exposing services running in your sandbox to the public internet. It fixes issues many were facing with local development and deployment to `workers.dev` domains. To migrate from `exposePort()` to tunnels, refer to the [tunnels API documentation](https://edgetunnel-b2h.pages.dev/sandbox/api/tunnels/) and the [expose services guide](https://edgetunnel-b2h.pages.dev/sandbox/guides/expose-services/).  
#### Default sessions  
By default, the `exec()` method in the Sandbox SDK maintains a default session across all calls, so a `cd` in one call is honored in the next. This convenience helped developers writing `exec` statements by hand, but confused agents and caused hard-to-trace bugs. As of `0.10.3`, we have introduced the [enableDefaultSession](https://edgetunnel-b2h.pages.dev/sandbox/configuration/sandbox-options/) flag on the `getSandbox()` interface to turn this off. Default sessions as a concept — and the flag — will be removed in an upcoming release.  
We recommend setting `enableDefaultSession: false` today and using the [sandbox.createSession() API](https://edgetunnel-b2h.pages.dev/sandbox/api/sessions/) when you need the previous behavior.  
#### Other changes  
We are also consolidating all APIs that buffer data to support streaming by default. This includes [readFile, writeFile](https://edgetunnel-b2h.pages.dev/sandbox/api/files/), and [exec](https://edgetunnel-b2h.pages.dev/sandbox/api/commands/). The stream equivalents will be removed.  
We are exploring moving non-core features like the [code interpreter](https://edgetunnel-b2h.pages.dev/sandbox/guides/code-execution/), [terminal](https://edgetunnel-b2h.pages.dev/sandbox/api/terminal/), and [git APIs](https://edgetunnel-b2h.pages.dev/sandbox/guides/git-workflows/) into helpers. These features will retain their existing APIs, so migration should be simple.  
#### Next steps  
If you use any of these features, refer to the [2026 deprecation migration guide](https://edgetunnel-b2h.pages.dev/sandbox/guides/2026-deprecation/). We also provide an [agent skill](https://edgetunnel-b2h.pages.dev/sandbox/guides/2026-deprecation/SKILL.md) to help with the migration.  
For any questions, ask in the [Cloudflare Developers Discord ↗](https://discord.gg/cloudflaredev).

Jun 08, 2026
1. ### [Authenticated SMTP submission now available in beta](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-08-smtp-submission/)  
[ Email Service ](https://edgetunnel-b2h.pages.dev/email-service/)  
You can now send emails through **Cloudflare Email Service** using authenticated [SMTP submission](https://edgetunnel-b2h.pages.dev/email-service/api/send-emails/smtp/) on `smtp.mx.cloudflare.net:465`. SMTP joins the [REST API](https://edgetunnel-b2h.pages.dev/email-service/api/send-emails/rest-api/) and the [Workers binding](https://edgetunnel-b2h.pages.dev/email-service/api/send-emails/workers-api/) as a third way to send transactional email — useful for existing applications that already speak SMTP and language-native SMTP libraries (Nodemailer, `smtplib`, PHPMailer, JavaMail).

| Setting  | Value                                                                             |
| -------- | --------------------------------------------------------------------------------- |
| Host     | smtp.mx.cloudflare.net                                                            |
| Port     | 465 (implicit TLS)                                                                |
| AUTH     | PLAIN or LOGIN                                                                    |
| Username | api\_token                                                                        |
| Password | A Cloudflare API token (account-owned or user-owned) with **Email Sending: Edit** |  
Submissions enter the same delivery pipeline as the REST API and Workers binding: identical [limits](https://edgetunnel-b2h.pages.dev/email-service/platform/limits/), automatic DKIM and ARC signing, and shared dashboard logs.  
Send your first email with a single command:  
```sh  
curl --ssl-reqd \
  --url "smtps://smtp.mx.cloudflare.net:465" \
  --user "api_token:<API_TOKEN>" \
  --mail-from "welcome@yourdomain.com" \
  --mail-rcpt "user@example.com" \
  --upload-file mail.txt  
```  
Refer to the [SMTP reference](https://edgetunnel-b2h.pages.dev/email-service/api/send-emails/smtp/) for authentication details, response codes, and language-specific examples.

Jun 08, 2026
1. ### [R2 SQL now supports UNION, INTERSECT, EXCEPT, and SELECT DISTINCT](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-05-union-intersect-except-select-distinct/)  
[ R2 SQL ](https://edgetunnel-b2h.pages.dev/r2-sql/)  
[R2 SQL](https://edgetunnel-b2h.pages.dev/r2-sql/) now supports set operations (`UNION`, `INTERSECT`, `EXCEPT`) and `SELECT DISTINCT`, expanding the range of analytical queries you can run directly on [Apache Iceberg ↗](https://iceberg.apache.org/) tables in [R2 Data Catalog](https://edgetunnel-b2h.pages.dev/r2/data-catalog/).  
#### Set operations  
Combine the results of multiple `SELECT` statements:

  * **`UNION`** — returns all rows from both queries, removing duplicates
  * **`UNION ALL`** — returns all rows from both queries, including duplicates
  * **`INTERSECT`** — returns only rows that appear in both queries
  * **`EXCEPT`** — returns rows from the first query that do not appear in the second  
```sql
-- Find zones that had either firewall blocks OR high-risk requests  
SELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'  
UNION  
SELECT zone_id FROM my_namespace.http_requests WHERE risk_score > 0.8  
```  
```sql
-- Find zones with both firewall blocks AND high traffic  
SELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'  
INTERSECT  
SELECT zone_id FROM my_namespace.http_requests  
GROUP BY zone_id  
HAVING COUNT(*) > 10000  
```  
```sql
-- Find enterprise zones that have not been compacted  
SELECT zone_id FROM my_namespace.zones WHERE plan = 'enterprise'  
EXCEPT  
SELECT zone_id FROM my_namespace.compaction_history  
```  
#### Select distinct  
Eliminate duplicate rows from query results:  
```sql  
SELECT DISTINCT region, department  
FROM my_namespace.sales_data  
WHERE total_amount > 1000  
ORDER BY region, department  
LIMIT 100  
```  
For large datasets where approximate results are acceptable, `approx_distinct()` remains a faster alternative for counting unique values.  
For the full syntax reference, refer to the [SQL reference](https://edgetunnel-b2h.pages.dev/r2-sql/sql-reference/). For performance guidance, refer to [Limitations and best practices](https://edgetunnel-b2h.pages.dev/r2-sql/reference/limitations-best-practices/).

Jun 08, 2026
1. ### [Post-meeting transcriptions are now Generally Available in RealtimeKit](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-08-realtimekit-post-meeting-transcription-ga/)  
[ Realtime ](https://edgetunnel-b2h.pages.dev/realtime/)  
[RealtimeKit](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/) lets you build products where people meet over live audio and video — such as HealthTech, EdTech, proctoring, and other real-time platforms — on Cloudflare's [global WebRTC infrastructure](https://edgetunnel-b2h.pages.dev/realtime/sfu/calls-vs-sfus/).  
[Post-meeting transcription](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/transcription/#post-meeting-transcription) is now Generally Available, so completed RealtimeKit meetings can automatically produce full transcript files after they end. Those transcripts can also power [AI-generated summaries](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/summary/) for meeting notes, review workflows, and follow-up tasks after the transcript is available.  
Post-meeting transcription is a managed service powered by [Workers AI](https://edgetunnel-b2h.pages.dev/workers-ai/) using [Whisper Large v3 Turbo](https://edgetunnel-b2h.pages.dev/workers-ai/models/whisper-large-v3-turbo/). RealtimeKit handles transcription processing and can return transcript and summary files through [webhooks](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/webhooks/) or the REST API, so you do not need to run your own transcription infrastructure.  
#### Generate transcripts and summaries  
To generate a transcript after a meeting ends, set `transcribe_on_end: true` when [creating a meeting](https://edgetunnel-b2h.pages.dev/api/resources/realtime%5Fkit/subresources/meetings/methods/create/). To also generate an AI summary automatically after the transcript is available, set `summarize_on_end: true`:  
```bash  
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/meetings" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{  
    "title": "Weekly product review",  
    "transcribe_on_end": true,  
    "summarize_on_end": true,  
    "ai_config": {  
      "transcription": {  
        "language": "en"  
      },  
      "summarization": {  
        "word_limit": 500,  
        "text_format": "markdown",  
        "summary_type": "team_meeting"  
      }  
    }  
  }'  
```  
#### Consume results  
When RealtimeKit finishes processing a meeting, it creates download URLs for the transcript and, if `summarize_on_end` is set, the summary. You can receive those URLs automatically with [webhooks](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/webhooks/), or fetch them later for a specific session with the [REST API](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/summary/#rest-api).  
To receive results as soon as they are ready, configure the `meeting.transcript` and `meeting.summary` webhook events:  
```bash  
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/webhooks" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{  
    "name": "AI results webhook",  
    "url": "https://example.com/webhook",  
    "events": ["meeting.transcript", "meeting.summary"],  
    "enabled": true  
  }'  
```  
To fetch results later, call the [transcript](https://edgetunnel-b2h.pages.dev/api/resources/realtime%5Fkit/subresources/sessions/methods/get%5Fsession%5Ftranscripts/) or [summary](https://edgetunnel-b2h.pages.dev/api/resources/realtime%5Fkit/subresources/sessions/methods/get%5Fsession%5Fsummary/) endpoint for the session:  
```bash  
curl -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/transcript" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"  
curl -X GET "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/summary" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"  
```  
Use the [Generate summary of transcripts for the session](https://edgetunnel-b2h.pages.dev/api/resources/realtime%5Fkit/subresources/sessions/methods/generate%5Fsummary%5Fof%5Ftranscripts/) API only if `summarize_on_end` was not set and you want to generate a summary manually after the transcript is available:  
```bash  
curl -X POST "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/realtime/kit/$APP_ID/sessions/$SESSION_ID/summary" \
  -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"  
```  
Post-meeting transcription supports [CSV, JSON, SRT, and VTT transcript outputs](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/transcription/#output-formats), [automatic language detection and Whisper language codes](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/transcription/#post-meeting-supported-languages). RealtimeKit also supports [real-time transcription](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/transcription/#real-time-transcription) with [Deepgram Nova-3](https://edgetunnel-b2h.pages.dev/workers-ai/models/nova-3/) for live captions, in-meeting accessibility, and real-time note-taking.  
Learn more in the [RealtimeKit transcription docs](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/transcription/) and [summary docs](https://edgetunnel-b2h.pages.dev/realtime/realtimekit/ai/summary/).

Jun 05, 2026
1. ### [Rollback support now available in Workflows](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-05-saga-rollbacks/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)  
[Workflows](https://edgetunnel-b2h.pages.dev/workflows/) now supports saga-style rollbacks, allowing you to add compensating logic to each `step.do()` in case of downstream failures. If the instance fails, the rollback handlers will execute in reverse `step-start` order.  
This is useful for multi-step operations that touch external systems, such as inventory reservations, payment authorization, ticket creation, or infrastructure provisioning. Instead of writing all cleanup logic in a top-level `catch`, you can keep each compensating action next to the step it undoes.  
Rollback handlers support their own retry and timeout configuration, and Workflows now exposes rollback outcomes in instance status responses. Workflows analytics also emits rollback lifecycle events, making it easier to distinguish a forward execution failure from a rollback failure when debugging production workflows.

  * [  JavaScript ](#tab-panel-3399)
  * [  TypeScript ](#tab-panel-3400)

**JavaScript**  
```js  
await step.do(  
  "provision resource",  
  async () => {  
    const resource = await provisionResource();  
    return { resourceId: resource.id };  
  },  
  {  
    rollback: async ({ output }) => {  
      const { resourceId } = output;  
      await deleteResource(resourceId);  
    },  
    rollbackConfig: {  
      retries: { limit: 3, delay: "15 seconds", backoff: "linear" },  
      timeout: "2 minutes",  
    },  
  },  
);  
```

**TypeScript**  
```ts  
await step.do(  
  "provision resource",  
  async () => {  
    const resource = await provisionResource();  
    return { resourceId: resource.id };  
  },  
  {  
    rollback: async ({ output }) => {  
      const { resourceId } = output as { resourceId: string };  
      await deleteResource(resourceId);  
    },  
    rollbackConfig: {  
      retries: { limit: 3, delay: "15 seconds", backoff: "linear" },  
      timeout: "2 minutes",  
    },  
  },  
);  
```  
Refer to [rollback options](https://edgetunnel-b2h.pages.dev/workflows/build/workers-api/#rollback-options) to learn more.

Jun 05, 2026
1. ### [Control AI costs with spend limits](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-05-spend-limits/)  
[ AI Gateway ](https://edgetunnel-b2h.pages.dev/ai-gateway/)  
AI Gateway now supports spend limits — cost-based budgets that track cumulative dollar spend and block requests when the budget is exceeded. Unlike rate limiting, which caps the number of requests, spend limits track actual cost based on token usage and model pricing.  
You can scope limits by model, provider, or custom metadata dimensions. For example, give each user a $200/day budget, cap total gateway spend at $10,000/day, or limit a specific model to $50/day per user. Each rule uses a configurable time window with fixed or sliding enforcement.  
Spend limits work with both [Unified Billing](https://edgetunnel-b2h.pages.dev/ai-gateway/features/unified-billing/) and [BYOK](https://edgetunnel-b2h.pages.dev/ai-gateway/configuration/bring-your-own-keys/) requests for models with known pricing.  
For more details, refer to the [Spend limits documentation](https://edgetunnel-b2h.pages.dev/ai-gateway/features/spend-limits/).

Jun 05, 2026
1. ### [Filter Workers' public Internet traffic using Gateway policies](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-05-gateway-egress/)  
[ Gateway ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/)[ Cloudflare Mesh ](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/)[ Workers VPC ](https://edgetunnel-b2h.pages.dev/workers-vpc/)  
Workers using a [VPC Network](https://edgetunnel-b2h.pages.dev/workers-vpc/configuration/vpc-networks/) binding with `network_id: "cf1:network"` now egress to public Internet destinations through [Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/). This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

  1. [Worker](https://edgetunnel-b2h.pages.dev/workers/)  
  Calls `env.EGRESS.fetch()`
  2. [VPC binding](https://edgetunnel-b2h.pages.dev/workers-vpc/) ↓
  3. [Cloudflare Mesh](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-mesh/)  
  Bind via [cf1:network](https://edgetunnel-b2h.pages.dev/workers-vpc/configuration/vpc-networks/)
  4. ↓
  5. [Cloudflare Gateway](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/)  
  Policies applied:  
  [ DNS ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/dns-policies/)[ HTTP ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/http-policies/)[ Network ](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/network-policies/)
  6. ↓
  7. ↗ Public Internet  
  Any public hostname or IP  
[ Gateway logs DNS HTTP Network ](https://edgetunnel-b2h.pages.dev/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/)  
What you get by default:

  * **Visibility.** Worker egress shows up in Gateway [DNS](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/dns-policies/), [HTTP](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/http-policies/), and [Network](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/network-policies/) logs alongside your other traffic, so you can audit what your Workers are calling and when.
  * **Enforcement.** Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.

  * [  wrangler.jsonc ](#tab-panel-3387)
  * [  wrangler.toml ](#tab-panel-3388)

**JSONC**  
```jsonc  
{  
  "vpc_networks": [  
    {  
      "binding": "EGRESS",  
      "network_id": "cf1:network",  
      "remote": true,  
    },  
  ],  
}  
```

**TOML**  
```toml  
[[vpc_networks]]  
binding = "EGRESS"  
network_id = "cf1:network"  
remote = true  
```

  * [  JavaScript ](#tab-panel-3391)
  * [  TypeScript ](#tab-panel-3392)

**JavaScript**  
```js  
// Egress to a public destination — subject to your Gateway policies and logged  
const response = await env.EGRESS.fetch("https://api.example.com/data");  
```

**TypeScript**  
```ts  
// Egress to a public destination — subject to your Gateway policies and logged  
const response = await env.EGRESS.fetch("https://api.example.com/data");  
```  
For configuration options, refer to [VPC Networks](https://edgetunnel-b2h.pages.dev/workers-vpc/configuration/vpc-networks/). For policy authoring, refer to [Cloudflare Gateway traffic policies](https://edgetunnel-b2h.pages.dev/cloudflare-one/traffic-policies/).

Jun 04, 2026
1. ### [Billable usage and budget alerts now in product sidebars](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-04-billable-usage-product-sidebar/)  
[ Cloudflare Fundamentals ](https://edgetunnel-b2h.pages.dev/fundamentals/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)[ R2 ](https://edgetunnel-b2h.pages.dev/r2/)[ KV ](https://edgetunnel-b2h.pages.dev/kv/)[ Queues ](https://edgetunnel-b2h.pages.dev/queues/)[ Vectorize ](https://edgetunnel-b2h.pages.dev/vectorize/)[ Durable Objects ](https://edgetunnel-b2h.pages.dev/durable-objects/)[ Containers ](https://edgetunnel-b2h.pages.dev/containers/)  
Pay-as-you-go customers can now view billable usage and create [budget alerts](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-13-billable-usage-dashboard-and-budget-alerts/) directly from the product overview pages for [Workers & Pages](https://edgetunnel-b2h.pages.dev/workers/), [D1](https://edgetunnel-b2h.pages.dev/d1/), [R2](https://edgetunnel-b2h.pages.dev/r2/), [Workers KV](https://edgetunnel-b2h.pages.dev/kv/), [Queues](https://edgetunnel-b2h.pages.dev/queues/), [Vectorize](https://edgetunnel-b2h.pages.dev/vectorize/), [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/), and [Containers](https://edgetunnel-b2h.pages.dev/containers/). A new sidebar widget shows current-period spend and the billing cycle date range, alongside a button to create a budget alert.  
The widget pulls from the same data as the [Billable Usage dashboard](https://edgetunnel-b2h.pages.dev/changelog/post/2026-04-13-billable-usage-dashboard-and-budget-alerts/) and aligns to your billing cycle (or the current day on Free plans), so the numbers match your invoice. Enterprise contract accounts are not yet supported.  
![Billable usage widget in the Durable Objects product sidebar showing current-period spend and a breakdown by service](https://edgetunnel-b2h.pages.dev/_astro/2026-06-04-billable-usage-product-sidebar.BUuIokn__ZAx1o6.webp)  
Selecting **Create budget alert** opens the budget alert flow inline so you can set a dollar threshold in the same place you are reviewing usage. Budget alerts apply to your total account-level spend across all products, not just the product page you create them from.  
For more information, refer to the [Usage-based billing documentation](https://edgetunnel-b2h.pages.dev/billing/).

Jun 04, 2026
1. ### [Pipeline binding configuration field renamed to stream](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-27-pipeline-binding-stream-field/)  
[ Pipelines ](https://edgetunnel-b2h.pages.dev/pipelines/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The `pipeline` field inside the `pipelines` binding configuration in your [Wrangler configuration file](https://edgetunnel-b2h.pages.dev/workers/wrangler/configuration/) has been renamed to `stream`. The old field is deprecated but still accepted.  
Update your configuration to use `stream` to avoid the deprecation warning.

**Before (deprecated):**

  * [  wrangler.jsonc ](#tab-panel-3389)
  * [  wrangler.toml ](#tab-panel-3390)

**JSONC**  
```jsonc  
{  
  "$schema": "./node_modules/wrangler/config-schema.json",  
  "pipelines": [  
    {  
      "binding": "MY_PIPELINE",  
      "pipeline": "<STREAM_ID>"  
    }  
  ]  
}  
```

**TOML**  
```toml  
[[pipelines]]  
binding = "MY_PIPELINE"  
pipeline = "<STREAM_ID>"  
```

**After:**

  * [  wrangler.jsonc ](#tab-panel-3393)
  * [  wrangler.toml ](#tab-panel-3394)

**JSONC**  
```jsonc  
{  
  "$schema": "./node_modules/wrangler/config-schema.json",  
  "pipelines": [  
    {  
      "binding": "MY_PIPELINE",  
      "stream": "<STREAM_ID>"  
    }  
  ]  
}  
```

**TOML**  
```toml  
[[pipelines]]  
binding = "MY_PIPELINE"  
stream = "<STREAM_ID>"  
```  
No other changes are required. The binding name, TypeScript types, and runtime API (`env.MY_PIPELINE.send(...)`) remain the same.  
For more information on configuring pipeline bindings, refer to [Writing to streams](https://edgetunnel-b2h.pages.dev/pipelines/streams/writing-to-streams/#configure-pipeline-binding).

Jun 03, 2026
1. ### [New Workers bulk secrets API endpoint](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-03-bulk-secrets-api/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now create, update, or delete multiple secrets for your Worker in a single request using the [bulk secrets endpoint](https://edgetunnel-b2h.pages.dev/api/resources/workers/subresources/scripts/subresources/secrets/methods/bulk%5Fupdate/).

  * Include a secret with a value to create or update.
  * Set a secret to `null` to delete.
  * Secrets not included in the request are left unchanged.  
The following example creates `API_KEY`, updates the already existing `DB_PASSWORD`, and deletes `OLD_SECRET`:  
```json  
{  
  "secrets": {  
    "API_KEY": { "type": "secret_text", "name": "API_KEY", "text": "my-api-key" },  
    "DB_PASSWORD": { "type": "secret_text", "name": "DB_PASSWORD", "text": "my-db-password" },  
    "OLD_SECRET": null  
  }  
}  
```  
You can do the same from the command line using [wrangler secret bulk](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/workers/#secret-bulk):  
```sh  
npx wrangler secret bulk < secrets.json  
```  
To delete a key, set its value to `null` in the JSON file. Deletion is not supported with `.env` files.  
Each request supports up to **100 total operations** (creates, updates, and deletes combined).

Jun 03, 2026
1. ### [Store Wrangler's OAuth credentials in your OS keychain](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-03-wrangler-keyring-credential-storage/)  
[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
[Wrangler](https://edgetunnel-b2h.pages.dev/workers/wrangler/) can now store the OAuth credentials returned by `wrangler login` in an [AES-256-GCM ↗](https://en.wikipedia.org/wiki/Galois/Counter%5FMode)\-encrypted file, with the encryption key held in your operating system keychain. The default behavior is unchanged — credentials still live in a plaintext TOML file unless you opt in.  
To opt in, run:  
```sh  
npx wrangler login --use-keyring  
```  
The choice is persisted across Wrangler invocations. Opt back out with `npx wrangler login --no-use-keyring`, or override the preference for a single command with the `CLOUDFLARE_AUTH_USE_KEYRING` environment variable.  
`wrangler whoami` now reports where credentials are stored:  
```sh  
🔐 Credentials are stored in: Encrypted file (~/.config/.wrangler/config/default.enc) with key in macOS Keychain (service=wrangler, account=default)  
```  
Per-platform backends:

  * **macOS** uses the built-in Keychain via `/usr/bin/security`.
  * **Linux** uses [libsecret ↗](https://wiki.gnome.org/Projects/Libsecret) via the `secret-tool` CLI from the `libsecret-tools` package.
  * **Windows** uses Credential Manager via [@napi-rs/keyring ↗](https://www.npmjs.com/package/@napi-rs/keyring), installed on-demand the first time you opt in.  
Refer to [Storing OAuth credentials in the OS keychain](https://edgetunnel-b2h.pages.dev/workers/wrangler/commands/general/#storing-oauth-credentials-in-the-os-keychain) for the full details, including the migration behavior on opt-in/opt-out and the `CLOUDFLARE_AUTH_USE_KEYRING` environment variable.

Jun 02, 2026
1. ### [Schedule Workflow instances directly from your Workflow binding](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-02-cron-workflows/)  
[ Workflows ](https://edgetunnel-b2h.pages.dev/workflows/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
You can now attach cron schedules directly to a Workflow binding in `wrangler.jsonc`. Each scheduled run creates a new Workflow instance automatically, so you do not need to define a separate Worker with a `scheduled` handler just to trigger your Workflow on an interval.  
For example, you can configure hourly, every-15-minute, or weekday schedules on the same Workflow:

**JSONC**  
```jsonc  
{  
  "workflows": [  
    {  
      "name": "my-scheduled-workflow",  
      "binding": "MY_WORKFLOW",  
      "class_name": "MyScheduledWorkflow",  
      "schedules": ["0 * * * *", "*/15 * * * *", "0 9 * * MON-FRI"],  
    },  
  ],  
}  
```  
Cron workloads get all the same benefits of Workflows with built-in retries, multi-step durable execution, and configurable timeouts of Workflows.

**TypeScript**  
```ts  
import {  
  WorkflowEntrypoint,  
  WorkflowEvent,  
  WorkflowStep,  
} from "cloudflare:workers";  
// Runs automatically on each cron schedule defined for the MY_WORKFLOW binding in wrangler.jsonc.  
export class MyScheduledWorkflow extends WorkflowEntrypoint<Env> {  
  async run(event: WorkflowEvent, step: WorkflowStep) {  
    const data = await step.do("fetch source data", async () => {  
      return await fetchSourceData();  
    });  
    // If this step fails, only this step is retried with the custom logic below  
    await step.do(  
      "process and store results",  
      {  
        retries: { limit: 5, delay: "30 seconds", backoff: "exponential" },  
        timeout: "10 minutes",  
      },  
      async () => {  
        await processAndStore(data);  
      },  
    );  
  }  
}  
```  
This makes it easier to build recurring, scheduled jobs such as database backups, invoice generation, report aggregation, and cleanup tasks without wiring up a separate Cron Trigger entrypoint.  
For more information, refer to [Trigger Workflows](https://edgetunnel-b2h.pages.dev/workflows/build/trigger-workflows/).

Jun 02, 2026
1. ### [Agents SDK v0.14.0: Agent Skills, messengers, scheduled tasks, Workflows, and hardened chat recovery](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-02-agents-sdk-v0140/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)[ Workers ](https://edgetunnel-b2h.pages.dev/workers/)  
The latest release of the [Agents SDK ↗](https://github.com/cloudflare/agents) adds four new ways to build with `@cloudflare/think`: on-demand Agent Skills, chat messengers (starting with Telegram), declarative scheduled tasks, and durable reasoning steps inside Workflows. This release also significantly hardens durable chat recovery, so turns reliably ride through deploys, evictions, and stalled model streams in production.  
#### Agent Skills (experimental)  
Give an agent a catalog of on-demand instructions, resources, and scripts. A skill source adds a catalog to the system prompt, and the model activates a skill only when a task matches — so a large library of capabilities does not bloat every prompt.

  * [  JavaScript ](#tab-panel-3395)
  * [  TypeScript ](#tab-panel-3396)

**JavaScript**  
```js  
import { Think, skills } from "@cloudflare/think";  
import bundledSkills from "agents:skills";  
export class SkillsAgent extends Think {  
  getSkills() {  
    return [  
      bundledSkills,  
      skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }),  
    ];  
  }  
}  
```

**TypeScript**  
```ts  
import { Think, skills } from "@cloudflare/think";  
import bundledSkills from "agents:skills";  
export class SkillsAgent extends Think<Env> {  
  getSkills() {  
    return [  
      bundledSkills,  
      skills.r2(this.env.SKILLS_BUCKET, { prefix: "skills/" }),  
    ];  
  }  
}  
```  
The `agents:skills` import bundles a local `./skills` directory through the Agents Vite plugin (one directory per skill, each with a `SKILL.md`). Skills can also load from R2 or a manifest. When skills are available, Think exposes `activate_skill`, `read_skill_resource`, and an optional `run_skill_script` tool. Skill loading is resilient: a duplicate or failing source is skipped with a warning instead of breaking the agent.  
Agent Skills are **experimental**, and script execution in particular is early. The API may change in a future release. We would love your feedback — tell us what you are building and what is missing in the [Agents repository ↗](https://github.com/cloudflare/agents/discussions).  
#### Messengers  
Connect a Think agent directly to a chat platform. Think owns the webhook route, conversation routing, durable reply fiber, and streamed delivery back to the provider. Telegram ships as the first provider.

  * [  JavaScript ](#tab-panel-3405)
  * [  TypeScript ](#tab-panel-3406)

**JavaScript**  
```js  
import { Think } from "@cloudflare/think";  
import {  
  defineMessengers,  
  ThinkMessengerStateAgent,  
} from "@cloudflare/think/messengers";  
import telegramMessenger from "@cloudflare/think/messengers/telegram";  
export { ThinkMessengerStateAgent };  
export class SupportAgent extends Think {  
  getMessengers() {  
    return defineMessengers({  
      telegram: telegramMessenger({  
        token: this.env.TELEGRAM_BOT_TOKEN,  
        userName: "support_bot",  
        secretToken: this.env.TELEGRAM_WEBHOOK_SECRET_TOKEN,  
      }),  
    });  
  }  
}  
```

**TypeScript**  
```ts  
import { Think } from "@cloudflare/think";  
import {  
  defineMessengers,  
  ThinkMessengerStateAgent,  
} from "@cloudflare/think/messengers";  
import telegramMessenger from "@cloudflare/think/messengers/telegram";  
export { ThinkMessengerStateAgent };  
export class SupportAgent extends Think<Env> {  
  getMessengers() {  
    return defineMessengers({  
      telegram: telegramMessenger({  
        token: this.env.TELEGRAM_BOT_TOKEN,  
        userName: "support_bot",  
        secretToken: this.env.TELEGRAM_WEBHOOK_SECRET_TOKEN,  
      }),  
    });  
  }  
}  
```  
Each Chat SDK thread maps to its own Think sub-agent by default, so group chats and direct messages do not share memory. Multiple bots, custom conversation routing, and custom providers are all supported.  
#### Scheduled tasks  
Declare recurring, timezone-aware prompts and handlers with a typed domain-specific language (DSL). Think reconciles the declarations on startup and re-arms the next occurrence after each run, backed by durable idempotent submissions.

  * [  JavaScript ](#tab-panel-3403)
  * [  TypeScript ](#tab-panel-3404)

**JavaScript**  
```js  
import { Think, defineScheduledTasks } from "@cloudflare/think";  
export class DigestAgent extends Think {  
  getScheduledTasks() {  
    return defineScheduledTasks({  
      weeklyCommitReport: {  
        schedule: "every week on monday at 09:00",  
        prompt:  
          "Compile my GitHub commits for the last week and summarize them.",  
      },  
      workout: {  
        schedule: "every day at 08:00 in Europe/London",  
        prompt: "Start my workout.",  
      },  
    });  
  }  
}  
```

**TypeScript**  
```ts  
import { Think, defineScheduledTasks } from "@cloudflare/think";  
export class DigestAgent extends Think<Env> {  
  getScheduledTasks() {  
    return defineScheduledTasks({  
      weeklyCommitReport: {  
        schedule: "every week on monday at 09:00",  
        prompt:  
          "Compile my GitHub commits for the last week and summarize them.",  
      },  
      workout: {  
        schedule: "every day at 08:00 in Europe/London",  
        prompt: "Start my workout.",  
      },  
    });  
  }  
}  
```  
#### Think Workflows  
Run a model-driven reasoning step inside a Cloudflare Workflow with `ThinkWorkflow` and `step.prompt()`, with durable typed structured output, long waits, and approval gates.

  * [  JavaScript ](#tab-panel-3407)
  * [  TypeScript ](#tab-panel-3408)

**JavaScript**  
```js  
import { z } from "zod";  
import { ThinkWorkflow } from "@cloudflare/think/workflows";  
const draftSchema = z.object({  
  title: z.string(),  
  summary: z.string(),  
  labels: z.array(z.string()),  
});  
export class TriageWorkflow extends ThinkWorkflow {  
  async run(event, step) {  
    const draft = await step.prompt("triage-issue", {  
      prompt: `Triage issue #${event.payload.issueNumber}`,  
      output: draftSchema,  
      timeout: "3 days",  
    });  
    await step.do("apply-labels", async () => {  
      await this.agent.applyLabels(draft.labels);  
    });  
  }  
}  
```

**TypeScript**  
```ts  
import { z } from "zod";  
import { ThinkWorkflow } from "@cloudflare/think/workflows";  
import type { ThinkWorkflowStep } from "@cloudflare/think/workflows";  
import type { AgentWorkflowEvent } from "agents/workflows";  
const draftSchema = z.object({  
  title: z.string(),  
  summary: z.string(),  
  labels: z.array(z.string()),  
});  
export class TriageWorkflow extends ThinkWorkflow<TriageAgent, Params> {  
  async run(event: AgentWorkflowEvent<Params>, step: ThinkWorkflowStep) {  
    const draft = await step.prompt("triage-issue", {  
      prompt: `Triage issue #${event.payload.issueNumber}`,  
      output: draftSchema,  
      timeout: "3 days",  
    });  
    await step.do("apply-labels", async () => {  
      await this.agent.applyLabels(draft.labels);  
    });  
  }  
}  
```  
#### Production hardening for durable chat recovery  
Durable chat turns have always been designed to survive a mid-turn deploy or Durable Object eviction. This release is a major hardening pass on that machinery for production.

  * **Better recovery during deploys.** Turns now ride through continuous deploys and evictions without losing completed work or re-running tools that already ran.
  * **A live "recovering…" signal.** `useAgentChat` exposes a new `isRecovering` flag, so a recovering turn shows progress instead of looking frozen. Most UIs render `isStreaming || isRecovering` as "busy".
  * **Stalled streams recover.** Set `chatStreamStallTimeoutMs` to route a hung provider stream into the same recovery path instead of leaving an infinite spinner.
  * **Sub-agents re-attach.** On parent recovery, an in-flight `agentTool()` child is re-attached to its result rather than abandoned and re-run, so long-running children no longer lose work under deploys.  
#### MCP transport improvements

  * **Resumable streams** — In-flight tool calls over Server-Sent Events (SSE) survive a dropped connection. Clients reconnect with `Last-Event-ID` and replay anything they missed.
  * **Readable server IDs** — `addMcpServer` accepts an optional `id`, so tools surface as readable keys (for example `tool_github_create_pull_request`) instead of opaque connection IDs.
  * **Better handling of concurrent requests** — Overlapping JSON-RPC requests are now correctly correlated to their responses across the HTTP and RPC transports.  
#### Other improvements

  * **Compaction** — A `Session`'s `tokenCounter` now also drives the compaction boundary decision ("what to compress"), not just the fire/no-fire trigger.
  * **`@cloudflare/worker-bundler`** — Adds a `virtualModules` option to `createWorker` to provide in-memory module source during bundling.
  * **Client-tool continuations** — Parallel tool results now coalesce into a single continuation, immediate resume requests attach to the pending continuation, and server-side `needsApproval` continuations resume reliably after approval.  
#### Upgrade  
To update to the latest version:  
 npm  yarn  pnpm  bun  
```  
npm i agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest  
```  
```  
yarn add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest  
```  
```  
pnpm add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest  
```  
```  
bun add agents@latest @cloudflare/think@latest @cloudflare/ai-chat@latest  
```  
Refer to the [Agents API reference](https://edgetunnel-b2h.pages.dev/agents/runtime/) and [Chat agents documentation](https://edgetunnel-b2h.pages.dev/agents/communication-channels/chat/chat-agents/) for more information.

May 29, 2026
1. ### [Share sandbox previews through Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-29-sandbox-named-tunnels/)  
[ Agents ](https://edgetunnel-b2h.pages.dev/agents/)  
[Sandboxes](https://edgetunnel-b2h.pages.dev/sandbox/) can expose a service running inside the container on a public preview URL through the `sandbox.tunnels` namespace. The SDK uses `cloudflared` inside the sandbox so you can share a running service without configuring `exposePort()` or a custom domain.  
By default, `sandbox.tunnels.get(port)` creates a [quick tunnel ↗](https://try.cloudflare.com/) on a zero-config `*.trycloudflare.com` URL — no Cloudflare account, DNS record, or custom domain required. This is perfect for quick development and for `.workers.dev` deployments.

  * [  JavaScript ](#tab-panel-3401)
  * [  TypeScript ](#tab-panel-3402)

**JavaScript**  
```js  
import { getSandbox } from "@cloudflare/sandbox";  
const sandbox = getSandbox(env.Sandbox, "my-sandbox");  
await sandbox.startProcess("python -m http.server 8080");  
const tunnel = await sandbox.tunnels.get(8080);  
console.log(tunnel.url); // → https://random-words-here.trycloudflare.com  
```

**TypeScript**  
```ts  
import { getSandbox } from "@cloudflare/sandbox";  
const sandbox = getSandbox(env.Sandbox, "my-sandbox");  
await sandbox.startProcess("python -m http.server 8080");  
const tunnel = await sandbox.tunnels.get(8080);  
console.log(tunnel.url); // → https://random-words-here.trycloudflare.com  
```  
#### Named tunnels  
For more control you can create a named tunnel through `sandbox.tunnels.get(port, { name })`. A named tunnel binds a hostname (`<name>.<your-zone>`) backed by a [Cloudflare Tunnel](https://edgetunnel-b2h.pages.dev/cloudflare-one/networks/connectors/cloudflare-tunnel/) and a CNAME record on your zone resulting in something like [https://my-app-preview.example.com ↗](https://my-app-preview.example.com).  
Unlike quick tunnels, which generate a new random URL each time, a named tunnel produces a persistent URL that survives container restarts. This makes named tunnels suitable for production use cases where you want control over the tunnel and it's origin.

  * [  JavaScript ](#tab-panel-3397)
  * [  TypeScript ](#tab-panel-3398)

**JavaScript**  
```js  
const tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });  
console.log(tunnel.url); // → https://my-app-preview.example.com  
```

**TypeScript**  
```ts  
const tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });  
console.log(tunnel.url); // → https://my-app-preview.example.com  
```  
Calling `sandbox.destroy()` tears down the Cloudflare Tunnel and the associated DNS record alongside the container, so you do not leave dangling tunnels or records behind.  
#### Upgrade  
To update to the latest version:  
 npm  yarn  pnpm  bun  
```  
npm i @cloudflare/sandbox@latest  
```  
```  
yarn add @cloudflare/sandbox@latest  
```  
```  
pnpm add @cloudflare/sandbox@latest  
```  
```  
bun add @cloudflare/sandbox@latest  
```  
For full API details, refer to the [Sandbox tunnels reference](https://edgetunnel-b2h.pages.dev/sandbox/api/tunnels/).

May 29, 2026
1. ### [D1 migrations support nested layouts via \`migrations\_pattern\`](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-04-migrations-pattern/)  
[ D1 ](https://edgetunnel-b2h.pages.dev/d1/)  
You can now point `wrangler d1 migrations apply` at a nested migrations layout — such as the one produced by [Drizzle ↗](https://orm.drizzle.team/) (`migrations/0001_init/migration.sql`) — using the new `migrations_pattern` D1 binding config:

**JSONC**  
```jsonc  
{  
  "d1_databases": [  
    {  
      "binding": "DB",  
      "database_name": "my-database",  
      "database_id": "<UUID>",  
      "migrations_dir": "migrations",  
      "migrations_pattern": "migrations/*/migration.sql",  
    },  
  ],  
}  
```  
`migrations_pattern` is a glob (relative to your Wrangler config file) used to discover migration files. It defaults to `${migrations_dir}/*.sql`, so existing projects keep working unchanged. Each migration's name is recorded in the migrations table as a path relative to `migrations_dir`.  
To learn more, visit D1's [migrations documentation](https://edgetunnel-b2h.pages.dev/d1/reference/migrations/#nested-migration-layouts).

May 29, 2026
1. ### [Cloudflare's Realtime WebSocket adapter now auto-reconnects and buffers WebRTC media](https://edgetunnel-b2h.pages.dev/changelog/post/2026-05-29-websocket-adapter-auto-reconnect/)  
[ Realtime ](https://edgetunnel-b2h.pages.dev/realtime/)  
[Cloudflare Realtime SFU](https://edgetunnel-b2h.pages.dev/realtime/sfu/) is a [WebRTC Selective Forwarding Unit that runs on Cloudflare's global network](https://edgetunnel-b2h.pages.dev/realtime/sfu/calls-vs-sfus/), so you can route live audio, video, and data between WebRTC clients around the world without managing SFU infrastructure or regions.  
When you use the [WebSocket adapter](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/) to stream WebRTC media to a WebSocket endpoint, the adapter now auto-reconnects and buffers audio and video after brief endpoint disconnects or restarts.  
#### Streaming WebRTC media to WebSocket endpoints  
Many teams also use Realtime SFU as the media layer for backend applications, such as transcription, recording, note-taking, and agentic media-processing services. These systems often need to consume live WebRTC audio or video from the SFU in backend infrastructure, including [Durable Objects](https://edgetunnel-b2h.pages.dev/durable-objects/), [Workers](https://edgetunnel-b2h.pages.dev/workers/), [Containers](https://edgetunnel-b2h.pages.dev/containers/), or external services, without running a WebRTC client themselves.  
The [WebSocket adapter](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/) bridges that gap by streaming WebRTC media from the SFU to a standard WebSocket endpoint as application-consumable payloads: [PCM audio frames and JPEG video frames](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#media-formats).  
#### What changed  
When you use the WebSocket adapter in [Stream mode (egress)](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#stream-mode-egress) to send live audio or video from the SFU to your own WebSocket endpoint, the SFU now [automatically reconnects](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#automatic-reconnection-for-streaming) after brief endpoint disconnects or restarts. This is especially helpful for long-running media pipelines where the WebSocket endpoint may briefly restart while a recording, transcription, or live analysis job is still in progress.  
Previously, a brief disconnect from your WebSocket endpoint could close the adapter and require your application to recreate it before media could resume. Now, the SFU retries the same endpoint for up to 5 seconds with no API change required. If the endpoint comes back within that window, audio and video delivery resumes automatically.  
The reconnect behavior also includes [live-first media buffering](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#media-buffering-during-reconnect), so brief interruptions reduce media loss without replaying stale video.  
#### Reconnect behavior  
During reconnect:

  * Audio uses a short bounded backlog to reduce audible loss. If the interruption lasts longer than the backlog can cover, older audio may be dropped.
  * Video resumes from the [latest available JPEG frame](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#video-jpeg) instead of replaying stale frames.
  * Recovery is best effort and does not guarantee gapless or exactly-once delivery.  
If the endpoint remains unavailable after the 5-second reconnect window, the adapter closes and must be recreated.  
#### Learn more

  * [WebSocket adapter](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/)
  * [Automatic reconnection for streaming](https://edgetunnel-b2h.pages.dev/realtime/sfu/media-transport-adapters/websocket-adapter/#automatic-reconnection-for-streaming)
  * [Get started with Realtime SFU](https://edgetunnel-b2h.pages.dev/realtime/sfu/get-started/)
  * [Realtime SFU example architecture](https://edgetunnel-b2h.pages.dev/realtime/sfu/example-architecture/)
  * [Realtime vs Regular SFUs](https://edgetunnel-b2h.pages.dev/realtime/sfu/calls-vs-sfus/)
  * [Global SFU Network Visualization ↗](https://realtime-sfu.dev-demos.workers.dev/)

```json
{"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/product-group/developer-platform/3/#page","headline":"Developer platform Changelog | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/product-group/developer-platform/3/","inLanguage":"en","image":"https://edgetunnel-b2h.pages.dev/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://edgetunnel-b2h.pages.dev/#website","name":"Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/"}}
```