---
title: Changelogs
image: https://developers.cloudflare.com/cf-twitter-card.png
---

> Documentation Index  
> Fetch the complete documentation index at: https://developers.cloudflare.com/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://developers.cloudflare.com/changelog/rss/index.xml) [ View RSS feeds ](https://developers.cloudflare.com/fundamentals/new-features/available-rss-feeds/) 

All products

![hero image](https://developers.cloudflare.com/_astro/hero.CVYJHPAd_26AMqX.svg) 

Jun 08, 2026
1. ### [R2 SQL now supports UNION, INTERSECT, EXCEPT, and SELECT DISTINCT](https://developers.cloudflare.com/changelog/post/2026-06-05-union-intersect-except-select-distinct/)  
[ R2 SQL ](https://developers.cloudflare.com/r2-sql/)  
[R2 SQL](https://developers.cloudflare.com/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://developers.cloudflare.com/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  
```
-- Find zones that had either firewall blocks OR high-risk requestsSELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'UNIONSELECT zone_id FROM my_namespace.http_requests WHERE risk_score > 0.8  
```  
```
-- Find zones with both firewall blocks AND high trafficSELECT zone_id FROM my_namespace.firewall_events WHERE action = 'block'INTERSECTSELECT zone_id FROM my_namespace.http_requestsGROUP BY zone_idHAVING COUNT(*) > 10000  
```  
```
-- Find enterprise zones that have not been compactedSELECT zone_id FROM my_namespace.zones WHERE plan = 'enterprise'EXCEPTSELECT zone_id FROM my_namespace.compaction_history  
```  
#### Select distinct  
Eliminate duplicate rows from query results:  
```  
SELECT DISTINCT region, departmentFROM my_namespace.sales_dataWHERE total_amount > 1000ORDER BY region, departmentLIMIT 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://developers.cloudflare.com/r2-sql/sql-reference/). For performance guidance, refer to [Limitations and best practices](https://developers.cloudflare.com/r2-sql/reference/limitations-best-practices/).

Jun 08, 2026
1. ### [Post-meeting transcriptions are now Generally Available in RealtimeKit](https://developers.cloudflare.com/changelog/post/2026-06-08-realtimekit-post-meeting-transcription-ga/)  
[ Realtime ](https://developers.cloudflare.com/realtime/)  
[RealtimeKit](https://developers.cloudflare.com/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://developers.cloudflare.com/realtime/sfu/calls-vs-sfus/).  
[Post-meeting transcription](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/workers-ai/) using [Whisper Large v3 Turbo](https://developers.cloudflare.com/workers-ai/models/whisper-large-v3-turbo/). RealtimeKit handles transcription processing and can return transcript and summary files through [webhooks](https://developers.cloudflare.com/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://developers.cloudflare.com/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`:  
Terminal window  
```  
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://developers.cloudflare.com/realtime/realtimekit/webhooks/), or fetch them later for a specific session with the [REST API](https://developers.cloudflare.com/realtime/realtimekit/ai/summary/#rest-api).  
To receive results as soon as they are ready, configure the `meeting.transcript` and `meeting.summary` webhook events:  
Terminal window  
```  
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://developers.cloudflare.com/api/resources/realtime%5Fkit/subresources/sessions/methods/get%5Fsession%5Ftranscripts/) or [summary](https://developers.cloudflare.com/api/resources/realtime%5Fkit/subresources/sessions/methods/get%5Fsession%5Fsummary/) endpoint for the session:  
Terminal window  
```  
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://developers.cloudflare.com/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:  
Terminal window  
```  
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://developers.cloudflare.com/realtime/realtimekit/ai/transcription/#output-formats), [automatic language detection and Whisper language codes](https://developers.cloudflare.com/realtime/realtimekit/ai/transcription/#post-meeting-supported-languages). RealtimeKit also supports [real-time transcription](https://developers.cloudflare.com/realtime/realtimekit/ai/transcription/#real-time-transcription) with [Deepgram Nova-3](https://developers.cloudflare.com/workers-ai/models/nova-3/) for live captions, in-meeting accessibility, and real-time note-taking.  
Learn more in the [RealtimeKit transcription docs](https://developers.cloudflare.com/realtime/realtimekit/ai/transcription/) and [summary docs](https://developers.cloudflare.com/realtime/realtimekit/ai/summary/).

Jun 08, 2026
1. ### [Create WAF rules directly from Threat Events saved views](https://developers.cloudflare.com/changelog/post/2026-06-08-create-waf-rules-from-threat-events/)  
[ Security Center ](https://developers.cloudflare.com/security-center/)  
Cloudforce One users can now turn [Threat Events indicators](https://developers.cloudflare.com/security-center/cloudforce-one/#analyze-threat-events) into active defense. With this update, users can instantly generate a WAF rule that matches the dynamic list of IP addresses returned by any of their **Saved Views**.  
#### Why this matters  
Threat intelligence is most effective when it is immediately actionable. Previously, blocking threat actors required manually extracting indicators from threat events and copying them into your firewall rules. This new integration bridges the gap between threat discovery and threat mitigation:

  * When you identify an active threat pattern - such as an ongoing campaign targeting a specific industry, or using a known indicator type - you can pivot from investigation to mitigation in a single click.
  * Instead of writing complex, static IP rules, this functionality allows you to leverage the specific filtering logic you have already defined and saved within your Threat Events ecosystem.
  * Automating the generation of the WAF rule expression from your threat views eliminates manual copying errors, ensuring that the right malicious infrastructure is blocked instantly.  
#### How to use it  
You can implement these rules through both the dashboard UI and via the API / Terraform.  
Go to **Cloudflare Dashboard** \> **Application Security** \> **Threat Intelligence** \> **Manage Views**, select your desired view, and select **Create WAF Rule**.  
This will automatically pre-populate the [WAF rule builder](https://developers.cloudflare.com/firewall/cf-dashboard/create-edit-delete-rules/) with the matching threat event IP indicators.  
You can also automate this workflow by utilizing the [**WAF Rule Builder API**](https://developers.cloudflare.com/firewall/api/cf-firewall-rules/) alongside your [Threat Events saved views endpoints](https://developers.cloudflare.com/firewall/api/cf-firewall-rules/).

Jun 08, 2026
1. ### [Introducing Threat Actor Profiles in Threat Events](https://developers.cloudflare.com/changelog/post/2026-06-08-threat-actor-profiles/)  
[ Security Center ](https://developers.cloudflare.com/security-center/)  

**TL;DR:** We’ve launched **Threat Actor Profiles** directly inside the Threat Events dashboard. You can now immediately pivot from a generic alert or blocked event to a profile that unmasks the "Who, Why, and How" behind a threat event.  
#### Why this matters  
Security teams often suffer from a visibility gap. When an attack is blocked, it's difficult to know if it was a random automated bot or a sophisticated advanced persistent threat (APT) campaign specifically targeting your industry. Finding out usually means leaving your security dashboard to hunt through external OSINT feeds or static, out-of-date threat reports. Threat Actor Profiles solve this by sharing Cloudforce One’s deep adversary research directly inside your workflow:

  * Cloudflare sees the traffic in real-time across approximately 20% of the web. This means actor profiles display active malicious infrastructure the moment it touches our global edge.
  * Every profile provides clear strategic and tactical modules including alternative aliases, origin tracking, historical threat event volume, and MITRE ATT&CK mapping detailing the adversary's technical methods.
  * You can search the dedicated threat actor directory or click an actor's name inside any threat event to view all details and related events to the specific threat actor.  
#### How to use it  
Adversary tracking is now available in the Cloudflare Dashbboard and ready to be included in your daily investigation workflow:

  * Click on the **Threat Actor** name in the Threat Events table to open their full identity profile and review their aliases and attack stats.
  * Navigate to **Cloudflare Dashboard > Application Security > Threat Intelligence** to explore the new **Threat Actors** tab. Here, you can browse a card-based directory of all established entities tracked by Cloudforce One.  
Learn more in the [Cloudforce One documentation ↗](https://developers.cloudflare.com/security-center/cloudforce-one/#identify-the-adversary).

Jun 05, 2026
1. ### [Rollback support now available in Workflows](https://developers.cloudflare.com/changelog/post/2026-06-05-saga-rollbacks/)  
[ Workflows ](https://developers.cloudflare.com/workflows/)  
[Workflows](https://developers.cloudflare.com/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-4711)
  * [  TypeScript ](#tab-panel-4712)  
JavaScript  
```  
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  
```  
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://developers.cloudflare.com/workflows/build/workers-api/#rollback-options) to learn more.

Jun 05, 2026
1. ### [Control AI costs with spend limits](https://developers.cloudflare.com/changelog/post/2026-06-05-spend-limits/)  
[ AI Gateway ](https://developers.cloudflare.com/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://developers.cloudflare.com/ai-gateway/features/unified-billing/) and [BYOK](https://developers.cloudflare.com/ai-gateway/configuration/bring-your-own-keys/) requests for models with known pricing.  
For more details, refer to the [Spend limits documentation](https://developers.cloudflare.com/ai-gateway/features/spend-limits/).

Jun 05, 2026
1. ### [Finer-grained chart granularity on Cloudflare Radar for longer time ranges](https://developers.cloudflare.com/changelog/post/2026-06-05-radar-traffic-chart-granularity/)  
[ Radar ](https://developers.cloudflare.com/radar/)  
[**Radar**](https://developers.cloudflare.com/radar/) now provides finer-grained traffic charts for longer time ranges. Previously, selecting a 1-3 month view on HTTP and NetFlows charts defaulted to weekly aggregation, which was too coarse to surface meaningful trends. Views longer than 3 months defaulted to monthly aggregation, returning as few as 7 data points for a 6-month range.  
The new defaults are:

  * **1-3 months**: daily granularity (7x more data points)
  * **Longer than 3 months** (HTTP and NetFlows): weekly granularity (4x more data points)  
For example, a 12-week traffic view previously showed weekly data:  
![Traffic trends chart with weekly granularity for a 12-week view](https://developers.cloudflare.com/_astro/traffic-granularity-12w-before.OlJmS6Ts_1UjtFK.webp)  
The same view now shows daily data:  
![Traffic trends chart with daily granularity for a 12-week view](https://developers.cloudflare.com/_astro/traffic-granularity-12w-after.DL8mxwQ3_ZMfTlA.webp)  
Similarly, a 1-year HTTP traffic view that previously showed just 12 monthly data points now provides 52 weekly data points.  
Visit [Cloudflare Radar ↗](https://radar.cloudflare.com/?dateRange=12w#traffic-trends) to explore the new granular views.

Jun 05, 2026
1. ### [Filter Workers' public Internet traffic using Gateway policies](https://developers.cloudflare.com/changelog/post/2026-06-05-gateway-egress/)  
[ Gateway ](https://developers.cloudflare.com/cloudflare-one/traffic-policies/)[ Cloudflare Mesh ](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/)[ Workers VPC ](https://developers.cloudflare.com/workers-vpc/)  
Workers using a [VPC Network](https://developers.cloudflare.com/workers-vpc/configuration/vpc-networks/) binding with `network_id: "cf1:network"` now egress to public Internet destinations through [Cloudflare Gateway](https://developers.cloudflare.com/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://developers.cloudflare.com/workers/)  
  Calls `env.EGRESS.fetch()`
  2. [VPC binding](https://developers.cloudflare.com/workers-vpc/) ↓
  3. [Cloudflare Mesh](https://developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-mesh/)  
  Bind via [cf1:network](https://developers.cloudflare.com/workers-vpc/configuration/vpc-networks/)
  4. ↓
  5. [Cloudflare Gateway](https://developers.cloudflare.com/cloudflare-one/traffic-policies/)  
  Policies applied:  
  [ DNS ](https://developers.cloudflare.com/cloudflare-one/traffic-policies/dns-policies/)[ HTTP ](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/)[ Network ](https://developers.cloudflare.com/cloudflare-one/traffic-policies/network-policies/)
  6. ↓
  7. ↗ Public Internet  
  Any public hostname or IP  
[ Gateway logs DNS HTTP Network ](https://developers.cloudflare.com/cloudflare-one/insights/logs/dashboard-logs/gateway-logs/)  
What you get by default:

  * **Visibility.** Worker egress shows up in Gateway [DNS](https://developers.cloudflare.com/cloudflare-one/traffic-policies/dns-policies/), [HTTP](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/), and [Network](https://developers.cloudflare.com/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-4699)
  * [  wrangler.toml ](#tab-panel-4700)  
JSONC  
```  
{  "vpc_networks": [    {      "binding": "EGRESS",      "network_id": "cf1:network",      "remote": true,    },  ],}  
```  
TOML  
```  
[[vpc_networks]]binding = "EGRESS"network_id = "cf1:network"remote = true  
```

  * [  JavaScript ](#tab-panel-4703)
  * [  TypeScript ](#tab-panel-4704)  
JavaScript  
```  
// Egress to a public destination — subject to your Gateway policies and loggedconst response = await env.EGRESS.fetch("https://api.example.com/data");  
```  
TypeScript  
```  
// Egress to a public destination — subject to your Gateway policies and loggedconst response = await env.EGRESS.fetch("https://api.example.com/data");  
```  
For configuration options, refer to [VPC Networks](https://developers.cloudflare.com/workers-vpc/configuration/vpc-networks/). For policy authoring, refer to [Cloudflare Gateway traffic policies](https://developers.cloudflare.com/cloudflare-one/traffic-policies/).

Jun 04, 2026
1. ### [Share identity providers across accounts with IdP federation](https://developers.cloudflare.com/changelog/post/2026-06-04-idp-federation/)  
[ Access ](https://developers.cloudflare.com/cloudflare-one/access-controls/policies/)  
Cloudflare Access now supports [IdP federation](https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/idp-federation/), which allows organizations to share a single identity provider across multiple Cloudflare accounts.  
Instead of configuring the same IdP (for example, Okta or Entra ID) separately in every account, you configure it once in a source account and share it with the other accounts in your organization. Each recipient account gets a read-only IdP connection that routes authentication back to the source account through a bridge — a hidden application in the source account that brokers the cross-account login. End users sign in with their existing IdP credentials, and each account's Access policies evaluate the resulting identity just like any other IdP login.  
Key capabilities:

  * **One IdP, many accounts** — Configure your IdP once and share it with all accounts in your organization.
  * **Lifecycle management** — As accounts join or leave your Cloudflare organization, their IdP connections are provisioned and removed automatically — no manual cleanup required.
  * **Immutable recipient connections** — IdP connections in recipient accounts cannot be accidentally modified or deleted.  
To get started, refer to [IdP federation](https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/idp-federation/).

Jun 04, 2026
1. ### [Billable usage and budget alerts now in product sidebars](https://developers.cloudflare.com/changelog/post/2026-06-04-billable-usage-product-sidebar/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)[ Workers ](https://developers.cloudflare.com/workers/)[ D1 ](https://developers.cloudflare.com/d1/)[ R2 ](https://developers.cloudflare.com/r2/)[ KV ](https://developers.cloudflare.com/kv/)[ Queues ](https://developers.cloudflare.com/queues/)[ Vectorize ](https://developers.cloudflare.com/vectorize/)[ Durable Objects ](https://developers.cloudflare.com/durable-objects/)[ Containers ](https://developers.cloudflare.com/containers/)  
Pay-as-you-go customers can now view billable usage and create [budget alerts](https://developers.cloudflare.com/changelog/post/2026-04-13-billable-usage-dashboard-and-budget-alerts/) directly from the product overview pages for [Workers & Pages](https://developers.cloudflare.com/workers/), [D1](https://developers.cloudflare.com/d1/), [R2](https://developers.cloudflare.com/r2/), [Workers KV](https://developers.cloudflare.com/kv/), [Queues](https://developers.cloudflare.com/queues/), [Vectorize](https://developers.cloudflare.com/vectorize/), [Durable Objects](https://developers.cloudflare.com/durable-objects/), and [Containers](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/_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://developers.cloudflare.com/billing/).

Jun 04, 2026
1. ### [Pipeline binding configuration field renamed to stream](https://developers.cloudflare.com/changelog/post/2026-05-27-pipeline-binding-stream-field/)  
[ Pipelines ](https://developers.cloudflare.com/pipelines/)[ Workers ](https://developers.cloudflare.com/workers/)  
The `pipeline` field inside the `pipelines` binding configuration in your [Wrangler configuration file](https://developers.cloudflare.com/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-4701)
  * [  wrangler.toml ](#tab-panel-4702)  
JSONC  
```  
{  "$schema": "./node_modules/wrangler/config-schema.json",  "pipelines": [    {      "binding": "MY_PIPELINE",      "pipeline": "<STREAM_ID>"    }  ]}  
```  
TOML  
```  
[[pipelines]]binding = "MY_PIPELINE"pipeline = "<STREAM_ID>"  
```

**After:**

  * [  wrangler.jsonc ](#tab-panel-4705)
  * [  wrangler.toml ](#tab-panel-4706)  
JSONC  
```  
{  "$schema": "./node_modules/wrangler/config-schema.json",  "pipelines": [    {      "binding": "MY_PIPELINE",      "stream": "<STREAM_ID>"    }  ]}  
```  
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://developers.cloudflare.com/pipelines/streams/writing-to-streams/#configure-pipeline-binding).

Jun 03, 2026
1. ### [SAML assertion encryption for identity providers](https://developers.cloudflare.com/changelog/post/2026-06-03-saml-assertion-encryption/)  
[ Access ](https://developers.cloudflare.com/cloudflare-one/access-controls/policies/)  
Cloudflare Access now supports SAML assertion encryption for identity provider integrations. When turned on, your identity provider encrypts SAML assertions using a Cloudflare-managed certificate before sending them through the user's browser. Only Access can decrypt these assertions, protecting sensitive identity data even after TLS termination.  
Without encryption, SAML assertions are transmitted in plaintext and could be visible to browser extensions or client-side malware.  
![SAML encryption toggle in the identity provider configuration](https://developers.cloudflare.com/_astro/saml-encryption.J5jmiYv8_ZkhXFT.webp)  
SAML encryption includes built-in certificate lifecycle management:

  * **Automatic certificate generation**: Access generates an encryption certificate when you turn on SAML encryption for an identity provider.
  * **Certificate rotation**: Rotate certificates without downtime. The previous certificate remains valid until expiration, giving you time to update your IdP.
  * **PEM export**: Copy the certificate in PEM format for manual upload to your IdP, or point your IdP to the SAML metadata endpoint for automatic retrieval.  
To get started, refer to [Encrypt SAML assertions](https://developers.cloudflare.com/cloudflare-one/integrations/identity-providers/generic-saml/#encrypt-saml-assertions).

Jun 03, 2026
1. ### [Introducing self-managed OAuth clients](https://developers.cloudflare.com/changelog/post/2026-06-03-public-oauth-clients/)  
[ Cloudflare Fundamentals ](https://developers.cloudflare.com/fundamentals/)  
Today we are launching self-managed OAuth, enabling developers to build third-party applications that integrate with Cloudflare via OAuth. This provides a more secure, user-friendly, and manageable alternative to API tokens.  
OAuth lets third-party applications act on behalf of a user to access their Cloudflare account. For example, after a user grants consent, Wrangler can deploy Workers into that account.  
#### What is new  
Cloudflare Developers can now create and manage their own OAuth applications to integrate with Cloudflare.  
#### Create an application  
To create an application, go to **Manage account** \> **OAuth clients** in your account on the Cloudflare dashboard.  
[ Go to **OAuth clients** ](https://dash.cloudflare.com/?to=/:account/oauth-clients)  
#### Select limited scopes  
If you have used an API token to call Cloudflare APIs, OAuth client scopes will look familiar. Select only the scopes your application needs during application creation, and include that scope list when sending users to Cloudflare for consent.  
Users can review the requested scopes before they consent.  
#### Apps for both private and public use  
Applications start with `private` visibility. Private applications can only be used by members of the account where the application was created.  
To make an application available to any Cloudflare user, complete the prerequisites for `public` visibility.  
For more information, refer to [client visibility](https://developers.cloudflare.com/fundamentals/oauth/create-an-oauth-client/#private-and-public-clients).  
#### Client domain verification  
Before an application can be made public, you must verify the client domain. Domain verification helps users confirm that the application owner controls the domain shown on the consent page.  
After verification, users see a verified badge on the consent page.  
For more information, refer to [domain verification](https://developers.cloudflare.com/fundamentals/oauth/create-an-oauth-client/#client-url-domain-ownership-verification).  
#### Learn more  
For more information, refer to [OAuth clients](https://developers.cloudflare.com/fundamentals/oauth/).

Jun 03, 2026
1. ### [New Workers bulk secrets API endpoint](https://developers.cloudflare.com/changelog/post/2026-06-03-bulk-secrets-api/)  
[ Workers ](https://developers.cloudflare.com/workers/)  
You can now create, update, or delete multiple secrets for your Worker in a single request using the [bulk secrets endpoint](https://developers.cloudflare.com/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`:  
```  
{  "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://developers.cloudflare.com/workers/wrangler/commands/workers/#secret-bulk):  
Terminal window  
```  
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 02, 2026
1. ### [Schedule Workflow instances directly from your Workflow binding](https://developers.cloudflare.com/changelog/post/2026-06-02-cron-workflows/)  
[ Workflows ](https://developers.cloudflare.com/workflows/)[ Workers ](https://developers.cloudflare.com/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  
```  
{  "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  
```  
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://developers.cloudflare.com/workflows/build/trigger-workflows/).

Jun 02, 2026
1. ### [Agents SDK v0.14.0: Agent Skills, messengers, scheduled tasks, Workflows, and hardened chat recovery](https://developers.cloudflare.com/changelog/post/2026-06-02-agents-sdk-v0140/)  
[ Agents ](https://developers.cloudflare.com/agents/)[ Workers ](https://developers.cloudflare.com/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-4707)
  * [  TypeScript ](#tab-panel-4708)  
JavaScript  
```  
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  
```  
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-4717)
  * [  TypeScript ](#tab-panel-4718)  
JavaScript  
```  
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  
```  
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-4715)
  * [  TypeScript ](#tab-panel-4716)  
JavaScript  
```  
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  
```  
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-4719)
  * [  TypeScript ](#tab-panel-4720)  
JavaScript  
```  
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  
```  
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://developers.cloudflare.com/agents/runtime/) and [Chat agents documentation](https://developers.cloudflare.com/agents/communication-channels/chat/chat-agents/) for more information.

Jun 02, 2026
1. ### [Cisco IOS XE](https://developers.cloudflare.com/changelog/post/2026-06-02-cisco-ios-xe/)  
[ Cloudflare WAN ](https://developers.cloudflare.com/cloudflare-wan/)[ Cloudflare One ](https://developers.cloudflare.com/cloudflare-one/)  
The Cisco IOS XE third-party integration guide for Cloudflare WAN has been updated to include:

  * Post Quantum Cryptography (PQC)
  * Policy-Based Routing (PBR)
  * IP Service Level Agreement (IP SLA)  
This link will take you directly to the updated [Cisco IOS XE](https://developers.cloudflare.com/cloudflare-wan/configuration/third-party/cisco-ios-xe/) guide.

Jun 01, 2026
1. ### [New Turnstile Events Logpush dataset in Cloudflare Logs](https://developers.cloudflare.com/changelog/post/2026-06-01-log-fields-updated/)  
[ Logs ](https://developers.cloudflare.com/logs/)  
Cloudflare has updated [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/):  
#### New datasets

  * **Turnstile Events**: A new dataset with fields including `ASN`, `Action`, `BrowserMajor`, `BrowserName`, `ClientIP`, `CountryCode`, `EventType`, `Hostname`, `OSMajor`, `OSName`, `Sitekey`, `Timestamp`, and `UserAgent`.  
For the complete field definitions for each dataset, refer to [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/).

May 29, 2026
1. ### [Cloudflare One Client for macOS (version 2026.5.1155.1)](https://developers.cloudflare.com/changelog/post/2026-05-29-warp-macos-beta/)  
[ Cloudflare One Client ](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/)  
A new Beta release for the macOS Cloudflare One Client is now available on the [beta releases downloads page](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/download/beta-releases/).  
This release introduces the new Cloudflare One Client UI for macOS! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

  * Right click context menu to access the most common client actions quickly
  * Built-in captive portal login experience

**Additional Changes and improvements**

  * The client now applies DNS search suffixes configured in your [device profile](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/device-profiles) / [network policy](https://developers.cloudflare.com/cloudflare-one/traffic-policies/network-policies). Administrators can push a list of DNS search domains that the client appends to single-label queries, alongside any system-configured suffixes. See [DNS search suffixes](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/settings/#dns-search-suffixes) for details.
  * Administrators can now control which virtual networks (VNETs) are available to which users via WARP device profile settings in the Zero Trust dashboard. Previously, every VNET in the organization was visible to every device; you can now scope the VNET picker per profile so users only see the networks relevant to them. See [VNET availability](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/settings/#vnet-availability) for details.
  * Added a local-file signal source for Emergency Disconnect. In addition to the existing HTTPS polling mechanism, administrators can now configure WARP to monitor for a file on disk; the presence of the file triggers an emergency disconnect even if both Cloudflare and your own infrastructure are unreachable. Either signal being asserted triggers disconnect; both must be cleared for normal operation to resume.
  * Added new warp-cli debug commands for interactive connection diagnosis. See [Extra debug logging](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/troubleshooting/diagnostic-logs/#extra-debug-logging) for details.
  * The local DNS proxy now supports DNSSEC passthrough. DNSSEC-signed responses are forwarded to the application intact (including DO/AD bits and RRSIG records), so applications that validate DNSSEC locally — including resolvers and the dig/drill tooling — work correctly through the client.
  * Added a new MDM format for organization-wide settings, including a cleaner way to configure the compliance environment (e.g. FedRAMP). The previous per-configuration approach still works, but the new format is now recommended. See the updated [Cloudflare One MDM documentation](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/deployment/mdm-deployment/parameters/#organization%5Fconfigs) for details.
  * Client Certificate device-posture checks now support template variables (e.g. `${serial_number}`, `${device_uuid}`) in the Subject Alternative Name field, matching what the documentation has always claimed. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.
  * Fixed the in-client captive-portal browser rendering a blank "Success" page on some airline Wi-Fi networks (United inflight Wi-Fi was the reported case). The browser now reliably loads the airline's real portal page so users can complete sign-in from inside the client instead of having to open a separate browser.
  * Fixed an issue in proxy mode where hostnames containing underscores (e.g. ai\_app.com) were rejected, breaking apps that depend on such hostnames (notably ChatGPT sandbox apps). The local proxy now accepts underscore-containing hostnames in CONNECT requests.

**Known issues**

  * Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.
  * Split tunnel list configuration is not available in the new UI. Management of split tunnel entries is currently only possible via `warp-cli tunnel ip` and `warp-cli tunnel host`. UI support will be added in a future release.

May 29, 2026
1. ### [Cloudflare One Client for Windows (version 2026.5.1155.1)](https://developers.cloudflare.com/changelog/post/2026-05-29-warp-windows-beta/)  
[ Cloudflare One Client ](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/)  
A new Beta release for the Windows Cloudflare One Client is now available on the [beta releases downloads page](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/download/beta-releases/).  
This release introduces the new Cloudflare One Client UI for Windows! You can expect a cleaner and more intuitive design as well as easier access to common actions and information. Here are some of the many things we have found our users appreciate:

  * Right click context menu to access the most common client actions quickly
  * Built-in captive portal login experience

**Additional Changes and improvements**

  * The client now applies DNS search suffixes configured in your [device profile](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/device-profiles) / [network policy](https://developers.cloudflare.com/cloudflare-one/traffic-policies/network-policies). Administrators can push a list of DNS search domains that the client appends to single-label queries, alongside any system-configured suffixes. See [DNS search suffixes](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/settings/#dns-search-suffixes) for details.
  * Administrators can now control which virtual networks (VNETs) are available to which users via WARP device profile settings in the Zero Trust dashboard. Previously, every VNET in the organization was visible to every device; you can now scope the VNET picker per profile so users only see the networks relevant to them. See [VNET availability](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/configure/settings/#vnet-availability) for details.
  * Added mandatory authentication. When enabled via MDM, the Cloudflare One Client blocks all Internet traffic from the moment the machine boots until the user authenticates, closing the visibility gap on newly deployed devices and during re-authentication. See the [announcement blog](https://blog.cloudflare.com/mandatory-authentication-mfa/) and [documentation](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/deployment/mdm-deployment/windows-no-auth-no-internet/) for details.
  * Added a local-file signal source for Emergency Disconnect. In addition to the existing HTTPS polling mechanism, administrators can now configure WARP to monitor for a file on disk; the presence of the file triggers an emergency disconnect even if both Cloudflare and your own infrastructure are unreachable. Either signal being asserted triggers disconnect; both must be cleared for normal operation to resume.
  * Added new warp-cli debug commands for interactive connection diagnosis. See [Extra debug logging](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/troubleshooting/diagnostic-logs/#extra-debug-logging) for details.
  * The local DNS proxy now supports DNSSEC passthrough. DNSSEC-signed responses are forwarded to the application intact (including DO/AD bits and RRSIG records), so applications that validate DNSSEC locally — including resolvers and the dig/drill tooling — work correctly through the client.
  * Added a new MDM format for organization-wide settings, including a cleaner way to configure the compliance environment (e.g. FedRAMP). The previous per-configuration approach still works, but the new format is now recommended. See the updated [Cloudflare One MDM documentation](https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/deployment/mdm-deployment/parameters/#organization%5Fconfigs) for details.
  * Client Certificate device-posture checks now support template variables (e.g. `${serial_number}`, `${device_uuid}`) in the Subject Alternative Name field, matching what the documentation has always claimed. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.
  * The UseWebView2 registry value (HKLM\\SOFTWARE\\Cloudflare\\CloudflareWARP\\UseWebView2 = y) is once again honored by the new GUI for authentication, so administrators who prefer the embedded WebView2 browser for sign-in can opt back in. This setting was effectively ignored in the previous release; the default browser was always used. This key is now also honored for re-authentications.
  * Fixed a crash in the authentication browser when navigating to a site that prompts for browser permissions (microphone, camera, notifications, etc.). The same fix had previously landed for the captive-portal browser; this extends it to the auth browser.
  * Fixed an issue in proxy mode where hostnames containing underscores (e.g. ai\_app.com) were rejected, breaking apps that depend on such hostnames (notably ChatGPT sandbox apps). The local proxy now accepts underscore-containing hostnames in CONNECT requests.

**Known issues**

  * An error indicating that Microsoft Edge can't read and write to its data directory may be displayed during captive portal login; this error is benign and can be dismissed.
  * Registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.
  * Split tunnel list configuration is not available in the new UI. Management of Split Tunnel entries is currently only possible via `warp-cli tunnel ip` and `warp-cli tunnel host`. UI support will be added in a future release.
  * Windows ARM may prompt the user to close running applications while trying to install this version. Simply click “Ok” with the default highlighted option.
  * DNS resolution may be broken when the following conditions are all true:
    * The client is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
    * A custom DNS server address is configured on the primary network adapter.
    * The custom DNS server address on the primary network adapter is changed while the client is connected.  
      To work around this issue, please reconnect the client by selecting "disconnect" and then "connect" in the client user interface.

May 29, 2026
1. ### [Share sandbox previews through Cloudflare Tunnel](https://developers.cloudflare.com/changelog/post/2026-05-29-sandbox-named-tunnels/)  
[ Agents ](https://developers.cloudflare.com/agents/)  
[Sandboxes](https://developers.cloudflare.com/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-4713)
  * [  TypeScript ](#tab-panel-4714)  
JavaScript  
```  
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  
```  
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://developers.cloudflare.com/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-4709)
  * [  TypeScript ](#tab-panel-4710)  
JavaScript  
```  
const tunnel = await sandbox.tunnels.get(8080, { name: "my-app-preview" });console.log(tunnel.url); // → https://my-app-preview.example.com  
```  
TypeScript  
```  
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://developers.cloudflare.com/sandbox/api/tunnels/).

May 29, 2026
1. ### [D1 migrations support nested layouts via \`migrations\_pattern\`](https://developers.cloudflare.com/changelog/post/2026-06-04-migrations-pattern/)  
[ D1 ](https://developers.cloudflare.com/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  
```  
{  "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://developers.cloudflare.com/d1/reference/migrations/#nested-migration-layouts).

May 29, 2026
1. ### [Updated fields across multiple Logpush datasets in Cloudflare Logs](https://developers.cloudflare.com/changelog/post/2026-05-29-log-fields-updated/)  
[ Logs ](https://developers.cloudflare.com/logs/)  
Cloudflare has updated [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/):  
#### Updated fields in existing datasets

  * **DEX Device State Events** (added): `DeviceRegistrationProfileID`.
  * **Gateway HTTP** (added): `AddedHeaders`, `DeletedHeaders`, and `SetHeaders`.
  * **HTTP requests** (added): `MatchedRules`.  
For the complete field definitions for each dataset, refer to [Logpush datasets](https://developers.cloudflare.com/logs/logpush/logpush-job/datasets/).

May 29, 2026
1. ### [TLS bug detection in the Cloudflare Radar post-quantum checker](https://developers.cloudflare.com/changelog/post/2026-05-29-radar-pq-tls-bug-detection/)  
[ Radar ](https://developers.cloudflare.com/radar/)  
The [**Radar**](https://developers.cloudflare.com/radar/) [post-quantum TLS support checker ↗](https://radar.cloudflare.com/post-quantum#website-support) now also reports TLS bugs detected during the handshake test. When a scanned host exhibits compatibility issues, the results include details on the specific bugs detected, along with guidance on how to investigate and remediate each issue. The bugs section only appears for hosts where issues are found.  
The following TLS bugs are detected:

  * **Split ClientHello** — The connection fails with a fragmented post-quantum `ClientHello` but succeeds with classical handshakes. Typically caused by middleboxes or firewalls that cannot reassemble split TLS messages.
  * **HRR Failure** — The server sends a `HelloRetryRequest` but fails to complete the handshake afterward.
  * **Unknown Keyshare** — The server cannot handle unknown key exchange algorithms and fails instead of responding with a `HelloRetryRequest` as required by the TLS 1.3 specification.  
![TLS bug detection results in the Radar post-quantum checker](https://developers.cloudflare.com/_astro/pq-tls-bug-detection.BrmsVMno_ZIsLXh.webp)  
Bug detection data is available through the existing [/post\_quantum/tls/support](https://developers.cloudflare.com/api/resources/radar/subresources/post%5Fquantum/subresources/tls/methods/support/) endpoint.  
Visit the [Post-Quantum Encryption ↗](https://radar.cloudflare.com/post-quantum#website-support) page to test a host.

May 29, 2026
1. ### [Cloudflare's Realtime WebSocket adapter now auto-reconnects and buffers WebRTC media](https://developers.cloudflare.com/changelog/post/2026-05-29-websocket-adapter-auto-reconnect/)  
[ Realtime ](https://developers.cloudflare.com/realtime/)  
[Cloudflare Realtime SFU](https://developers.cloudflare.com/realtime/sfu/) is a [WebRTC Selective Forwarding Unit that runs on Cloudflare's global network](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/durable-objects/), [Workers](https://developers.cloudflare.com/workers/), [Containers](https://developers.cloudflare.com/containers/), or external services, without running a WebRTC client themselves.  
The [WebSocket adapter](https://developers.cloudflare.com/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://developers.cloudflare.com/realtime/sfu/media-transport-adapters/websocket-adapter/#media-formats).  
#### What changed  
When you use the WebSocket adapter in [Stream mode (egress)](https://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/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://developers.cloudflare.com/realtime/sfu/media-transport-adapters/websocket-adapter/)
  * [Automatic reconnection for streaming](https://developers.cloudflare.com/realtime/sfu/media-transport-adapters/websocket-adapter/#automatic-reconnection-for-streaming)
  * [Get started with Realtime SFU](https://developers.cloudflare.com/realtime/sfu/get-started/)
  * [Realtime SFU example architecture](https://developers.cloudflare.com/realtime/sfu/example-architecture/)
  * [Realtime vs Regular SFUs](https://developers.cloudflare.com/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://developers.cloudflare.com/changelog/3/#page","headline":"Changelogs | Cloudflare Docs","url":"https://developers.cloudflare.com/changelog/3/","inLanguage":"en","image":"https://developers.cloudflare.com/cf-twitter-card.png","publisher":{"@type":"Organization","name":"Cloudflare","url":"https://www.cloudflare.com/"},"isPartOf":{"@type":"WebSite","@id":"https://developers.cloudflare.com/#website","name":"Cloudflare Docs","url":"https://developers.cloudflare.com/"}}
```