--- title: Changelogs 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/) All products ![hero image](https://edgetunnel-b2h.pages.dev/_astro/hero.CVYJHPAd_26AMqX.svg) 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": "", "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. ### [Account-level DNS records quota](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-10-account-level-record-quota/) [ DNS ](https://edgetunnel-b2h.pages.dev/dns/) Cloudflare now enforces DNS records quotas at the account level for Enterprise accounts. Instead of a per-zone limit, these accounts have a quota on the total number of records across all of their zones, letting you distribute records across your zones however you like — regardless of each zone's plan. Public and internal zones are counted separately, each with a default quota of 1,000,000 records. Accounts without an account-level quota are unaffected: existing per-zone quotas behave exactly as before. For more details, refer to [DNS records quota](https://edgetunnel-b2h.pages.dev/dns/manage-dns-records/#dns-records-quota). 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 10, 2026 1. ### [Automated Cease and Desist templates for Brand Protection](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-08-brand-protection-cease-and-desist-letters/) [ Security Center ](https://edgetunnel-b2h.pages.dev/security-center/) **TL;DR:** Brand Protection now features an **Automated Cease & Desist (C&D)** workflow. When you discover an infringing domain hosted outside of Cloudflare, you can instantly generate, review, and download a custom-branded, pre-filled legal notice in seconds. #### Why this matters This update introduces a major shift from pure detection to actionable enforcement, eliminating the manual burden for your Trust & Safety and Legal teams: * **Instant WHOIS and Recipient Lookup:** We automatically scrape registrar data and WHOIS contact information (such as the registrant or registrar abuse email) behind the scenes, highlighting exactly where your notice needs to be sent * **Smart Template Automation:** We pre-fill your custom-branded templates with essential metadata, including the infringing domain, registrar name, and discovery date. * **Tailored Enforcement Tones:** Choose from three default layout strategies depending on the severity of the infrastructure match: * _Exact Match:_ A formal demand for identical trademark infringements * _Similar Match:_ A standard notice optimized for typosquatting (one-character distance matches) * _Friendly Tone:_ An amicable initial outreach for potential unintentional or accidental infringements * **Full Editing Control:** Before creating the final PDF, a real-time review screen allows you to fine-tune the messaging, modify placeholders, and ensure your text aligns perfectly with internal legal standards #### How it works When reviewing a malicious domain match inside your dashboard, your enforcement path splits depending on where the attacker is located: 1. **On the Cloudflare Network:** If the domain uses Cloudflare’s network or registrar, trigger our existing integrated abuse reporting flow with one click. 2. **Hosted Elsewhere:** If the domain is hosted on an external provider, click the **Generate C&D Letter** option to launch the new document builder, pick your template, verify the auto-populated recipient data, and download your finalized PDF. You can manage your templates and enforce matches by going to the **Cloudflare Dashboard > Application Security > Brand Protection** and selecting your detected Brand Protection matches. For more information, read the [Brand Protection documentation](https://edgetunnel-b2h.pages.dev/security-center/brand-protection/). > **Note:** Cloudflare does not represent you and cannot provide you with legal advice. Only you can decide whether your rights have been infringed, whether a cease and desist letter is appropriate, and what that letter should say. 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 09, 2026 1. ### [WAF Release - 2026-06-09](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-09-waf-release/) [ WAF ](https://edgetunnel-b2h.pages.dev/waf/) This release introduces new detections for a critical SQL injection vulnerability in Drupal installations utilizing PostgreSQL (CVE-2026-9082), alongside targeted protection for an unsafe deserialization flaw in the Mirasvit Cache Warmer extension (CVE-2026-45247). Additionally, this release includes coverage for a prototype pollution vector in Axios (CVE-2026-40175) and a new generic rule designed to identify and block sophisticated SQL Injection (SQLi) bypass attempts leveraging obfuscated boolean logic. **Key Findings** * CVE-2026-9082: A database abstraction vulnerability affects Drupal sites configured with a PostgreSQL backend. Remote, unauthenticated attackers can exploit this flaw via crafted inputs to inject malicious SQL commands and access or manipulate backend data. * CVE-2026-45247: A PHP Object Injection vulnerability exists in the Mirasvit Cache Warmer extension for Magento and Adobe Commerce. This flaw stems from unsafe deserialization of untrusted user input, enabling unauthenticated attackers to execute arbitrary code on the hosting server. * CVE-2026-40175: A prototype pollution vulnerability affects the Axios HTTP client library. Attackers can exploit this to inject malicious properties into the global JavaScript object prototype, potentially causing application crashes (Denial of Service) or executing unauthorized code depending on the application structure. **Impact** Successful exploitation of these vulnerabilities could allow unauthenticated attackers to execute arbitrary code, manipulate database contents, or induce application crashes, leading to severe operational disruption or complete server compromise. These newly deployed signatures intercept these advanced malicious payloads at the edge before they can interact with vulnerable software configurations. | Ruleset | Rule ID | Legacy Rule ID | Description | Previous Action | New Action | Comments | | -------------------------- | ----------- | -------------- | ----------------------------------------------------------------- | --------------- | ---------- | ------------------------ | | Cloudflare Managed Ruleset | ...387cf935 | N/A | Axios - Prototype Pollution - CVE:CVE-2026-40175 | Log | Block | This is a new detection. | | Cloudflare Managed Ruleset | ...417eb9e0 | N/A | Drupal - PostgreSQL SQLi - CVE:CVE-2026-9082 - Body | Log | Block | This is a new detection. | | Cloudflare Managed Ruleset | ...fd3857fd | N/A | Drupal - PostgreSQL SQLi - CVE:CVE-2026-9082 - URI | Log | Block | This is a new detection. | | Cloudflare Managed Ruleset | ...aee241d2 | N/A | SQLi - Obfuscated Boolean - Body | N/A | Disabled | This is a new detection. | | Cloudflare Managed Ruleset | ...d8620070 | N/A | SQLi - Obfuscated Boolean - Headers | N/A | Disabled | This is a new detection. | | Cloudflare Managed Ruleset | ...e0be4d47 | N/A | Mirasvit Cache Warmer - PHP Object Injection - CVE:CVE-2026-45247 | N/A | Block | This is a new detection. | 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:" \ --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 08, 2026 1. ### [Create WAF rules directly from Threat Events saved views](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-08-create-waf-rules-from-threat-events/) [ Security Center ](https://edgetunnel-b2h.pages.dev/security-center/) Cloudforce One users can now turn [Threat Events indicators](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/firewall/api/cf-firewall-rules/) alongside your [Threat Events saved views endpoints](https://edgetunnel-b2h.pages.dev/firewall/api/cf-firewall-rules/). Jun 08, 2026 1. ### [Introducing Threat Actor Profiles in Threat Events](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-08-threat-actor-profiles/) [ Security Center ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/security-center/cloudforce-one/#identify-the-adversary). 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-4981) * [ TypeScript ](#tab-panel-4982) **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. ### [Finer-grained chart granularity on Cloudflare Radar for longer time ranges](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-05-radar-traffic-chart-granularity/) [ Radar ](https://edgetunnel-b2h.pages.dev/radar/) [**Radar**](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/_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://edgetunnel-b2h.pages.dev/_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://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-4973) * [ wrangler.toml ](#tab-panel-4974) **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-4977) * [ TypeScript ](#tab-panel-4978) **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. ### [Share identity providers across accounts with IdP federation](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-04-idp-federation/) [ Access ](https://edgetunnel-b2h.pages.dev/cloudflare-one/access-controls/policies/) Cloudflare Access now supports [IdP federation](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/idp-federation/). 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-4975) * [ wrangler.toml ](#tab-panel-4976) **JSONC** ```jsonc { "$schema": "./node_modules/wrangler/config-schema.json", "pipelines": [ { "binding": "MY_PIPELINE", "pipeline": "" } ] } ``` **TOML** ```toml [[pipelines]] binding = "MY_PIPELINE" pipeline = "" ``` **After:** * [ wrangler.jsonc ](#tab-panel-4979) * [ wrangler.toml ](#tab-panel-4980) **JSONC** ```jsonc { "$schema": "./node_modules/wrangler/config-schema.json", "pipelines": [ { "binding": "MY_PIPELINE", "stream": "" } ] } ``` **TOML** ```toml [[pipelines]] binding = "MY_PIPELINE" stream = "" ``` 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. ### [SAML assertion encryption for identity providers](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-03-saml-assertion-encryption/) [ Access ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/_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://edgetunnel-b2h.pages.dev/cloudflare-one/integrations/identity-providers/generic-saml/#encrypt-saml-assertions). Jun 03, 2026 1. ### [Introducing self-managed OAuth clients](https://edgetunnel-b2h.pages.dev/changelog/post/2026-06-03-public-oauth-clients/) [ Cloudflare Fundamentals ](https://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/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://edgetunnel-b2h.pages.dev/fundamentals/oauth/create-an-oauth-client/#client-url-domain-ownership-verification). #### Learn more For more information, refer to [OAuth clients](https://edgetunnel-b2h.pages.dev/fundamentals/oauth/). 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 { 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/). ```json {"@context":"https://schema.org","@type":"BlogPosting","@id":"https://edgetunnel-b2h.pages.dev/changelog/5/#page","headline":"Changelogs | Cloudflare Docs","url":"https://edgetunnel-b2h.pages.dev/changelog/5/","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/"}} ```