Skip to content

Changelog

New updates and improvements at Cloudflare.

Magic Transit and Magic WAN health check data is fully compatible with the CMB EU setting.

Today, we are excited to announce that all Magic Transit and Magic WAN customers with CMB EU (Customer Metadata Boundary - Europe) enabled in their account will be able to access GRE, IPsec, and CNI health check and traffic volume data in the Cloudflare dashboard and via API.

This ensures that all Magic Transit and Magic WAN customers with CMB EU enabled will be able to access all Magic Transit and Magic WAN features.

Specifically, these two GraphQL endpoints are now compatible with CMB EU:

  • magicTransitTunnelHealthChecksAdaptiveGroups
  • magicTransitTunnelTrafficAdaptiveGroups

Deploy to Cloudflare buttons now support Worker environment variables, secrets, and Secrets Store secrets

Any template which uses Worker environment variables, secrets, or Secrets Store secrets can now be deployed using a Deploy to Cloudflare button.

Define environment variables and secrets store bindings in your Wrangler configuration file as normal:

{
  "name": "my-worker",
  "main": "./src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
  "vars": {
    "API_HOST": "https://example.com",
  },
	"secrets_store_secrets": [
		{
			"binding": "API_KEY",
			"store_id": "demo",
			"secret_name": "api-key"
		}
	]
}
name = "my-worker"
main = "./src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-11"

[vars]
API_HOST = "https://example.com"

[[secrets_store_secrets]]
binding = "API_KEY"
store_id = "demo"
secret_name = "api-key"

Add secrets to a .dev.vars.example or .env.example file:

.dev.vars.exampleini
COOKIE_SIGNING_KEY=my-secret # comment

And optionally, you can add a description for these bindings in your template's package.json to help users understand how to configure each value:

package.jsonjson
{
	"name": "my-worker",
	"private": true,
	"cloudflare": {
		"bindings": {
			"API_KEY": {
				"description": "Select your company's API key for connecting to the example service."
			},
			"COOKIE_SIGNING_KEY": {
				"description": "Generate a random string using `openssl rand -hex 32`."
			}
		}
	}
}

These secrets and environment variables will be presented to users in the dashboard as they deploy this template, allowing them to configure each value. Additional information about creating templates and Deploy to Cloudflare buttons can be found in our documentation.

Scam domain category introduced under Security Threats

We have introduced a new Security Threat category called Scam. Relevant domains are marked with the Scam category. Scam typically refers to fraudulent websites and schemes designed to trick victims into giving away money or personal information.

New category added

Parent ID Parent Name Category ID Category Name
21 Security Threats 191 Scam

Refer to Gateway domain categories to learn more.

Test out code changes before shipping with per-branch preview deployments for Cloudflare Workers

Now, when you connect your Cloudflare Worker to a git repository on GitHub or GitLab, each branch of your repository has its own stable preview URL, that you can use to preview code changes before merging the pull request and deploying to production.

This works the same way that Cloudflare Pages does — every time you create a pull request, you'll automatically get a shareable preview link where you can see your changes running, without affecting production. The link stays the same, even as you add commits to the same branch. These preview URLs are named after your branch and are posted as a comment to each pull request. The URL stays the same with every commit and always points to the latest version of that branch.

PR comment preview

Preview URL types

Each comment includes two preview URLs as shown above:

  • Commit Preview URL: Unique to the specific version/commit (e.g., <version-prefix>-<worker-name>.<subdomain>.workers.dev)
  • Branch Preview URL: A stable alias based on the branch name (e.g., <branch-name>-<worker-name>.<subdomain>.workers.dev)

How it works

When you create a pull request:

  • A preview alias is automatically created based on the Git branch name (e.g., <branch-name> becomes <branch-name>-<worker-name>.<subdomain>.workers.dev)
  • No configuration is needed, the alias is generated for you
  • The link stays the same even as you add commits to the same branch
  • Preview URLs are posted directly to your pull request as comments (just like they are in Cloudflare Pages)

Custom alias name

You can also assign a custom preview alias using the Wrangler CLI, by passing the --preview-alias flag when uploading a version of your Worker:

wrangler versions upload --preview-alias staging

Limitations while in beta

  • Only available on the workers.dev subdomain (custom domains not yet supported)
  • Requires Wrangler v4.21.0+
  • Preview URLs are not generated for Workers that use Durable Objects
  • Not yet supported for Workers for Platforms

Google Bard Application replaced by Gemini

The Google Bard application (ID: 1198) has been deprecated and fully removed from the system. It has been replaced by the Gemini application (ID: 1340). Any existing Gateway policies that reference the old Google Bard application will no longer function. To ensure your policies continue to work as intended, you should update them to use the new Gemini application. We recommend replacing all instances of the deprecated Bard application with the new Gemini application in your Gateway policies. For more information about application policies, please see the Cloudflare Gateway documentation.

Audio mode for Media Transformations

We now support audio mode! Use this feature to extract audio from a source video, outputting an M4A file to use in downstream workflows like AI inference, content moderation, or transcription.

For example,

Example URLtext
https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>
https://example.com/cdn-cgi/media/mode=audio,time=3s,duration=60s/<input video with diction>

For more information, learn about Transforming Videos.

New detection entry type: Document Matching for DLP

You can now create document-based detection entries in DLP by uploading example documents. Cloudflare will encrypt your documents and create a unique fingerprint of the file. This fingerprint is then used to identify similar documents or snippets within your organization's traffic and stored files.

DLP

Key features and benefits:

  • Upload documents, forms, or templates: Easily upload .docx and .txt files (up to 10 MB) that contain sensitive information you want to protect.

  • Granular control with similarity percentage: Define a minimum similarity percentage (0-100%) that a document must meet to trigger a detection, reducing false positives.

  • Comprehensive coverage: Apply these document-based detection entries in:

    • Gateway policies: To inspect network traffic for sensitive documents as they are uploaded or shared.

    • CASB (Cloud Access Security Broker): To scan files stored in cloud applications for sensitive documents at rest.

  • Identify sensitive data: This new detection entry type is ideal for identifying sensitive data within completed forms, templates, or even small snippets of a larger document, helping you prevent data exfiltration and ensure compliance.

Once uploaded and processed, you can add this new document entry into a DLP profile and policies to enhance your data protection strategy.

Faster, more reliable UDP traffic for Cloudflare Tunnel

Your real-time applications running over Cloudflare Tunnel are now faster and more reliable. We've completely re-architected the way cloudflared proxies UDP traffic in order to isolate it from other traffic, ensuring latency-sensitive applications like private DNS are no longer slowed down by heavy TCP traffic (like file transfers) on the same Tunnel.

This is a foundational improvement to Cloudflare Tunnel, delivered automatically to all customers. There are no settings to configure — your UDP traffic is already flowing faster and more reliably.

What’s new:

  • Faster UDP performance: We've significantly reduced the latency for establishing new UDP sessions, making applications like private DNS much more responsive.
  • Greater reliability for mixed traffic: UDP packets are no longer affected by heavy TCP traffic, preventing timeouts and connection drops for your real-time services.

Learn more about running TCP or UDP applications and private networks through Cloudflare Tunnel.

New onboarding guides for Zero Trust

Use our brand new onboarding experience for Cloudflare Zero Trust. New and returning users can now engage with a Get Started tab with walkthroughs for setting up common use cases end-to-end.

Zero Trust onboarding guides

There are eight brand new onboarding guides in total:

  • Securely access a private network (sets up device client and Tunnel)
  • Device-to-device / mesh networking (sets up and connects multiple device clients)
  • Network to network connectivity (sets up and connects multiple WARP Connectors, makes reference to Magic WAN availability for Enterprise)
  • Secure web traffic (sets up device client, Gateway, pre-reqs, and initial policies)
  • Secure DNS for networks (sets up a new DNS location and Gateway policies)
  • Clientless web access (sets up Access to a web app, Tunnel, and public hostname)
  • Clientless SSH access (all the same + the web SSH experience)
  • Clientless RDP access (all the same + RDP-in-browser)

Each flow walks the user through the steps to configure the essential elements, and provides a “more details” panel with additional contextual information about what the user will accomplish at the end, along with why the steps they take are important.

Try them out now in the Zero Trust dashboard ↗︎!

Cloudy summaries for Access and Gateway Logs

Cloudy, Cloudflare's AI Agent, will now automatically summarize your Access and Gateway block logs.

In the log itself, Cloudy will summarize what occurred and why. This will be helpful for quick troubleshooting and issue correlation.

Cloudy AI summarizes a log

If you have feedback about the Cloudy summary - good or bad - you can provide that right from the summary itself.

New App Library for Zero Trust Dashboard

Cloudflare Zero Trust customers can use the App Library to get full visibility over the SaaS applications that they use in their Gateway policies, CASB integrations, and Access for SaaS applications.

App Library, found under My Team, makes information available about all Applications that can be used across the Zero Trust product suite.

Zero Trust App Library

You can use the App Library to see:

  • How Applications are defined
  • Where they are referenced in policies
  • Whether they have Access for SaaS configured
  • Review their CASB findings and integration status.

Within individual Applications, you can also track their usage across your organization, and better understand user behavior.

Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs

Workers now support breakpoint debugging using VSCode's built-in JavaScript Debug Terminals ↗︎. All you have to do is open a JS debug terminal (Cmd + Shift + P and then type javascript debug) and run wrangler dev (or vite dev) from within the debug terminal. VSCode will automatically connect to your running Worker (even if you're running multiple Workers at once!) and start a debugging session.

In 2023 we announced breakpoint debugging support ↗︎ for Workers, which meant that you could easily debug your Worker code in Wrangler's built-in devtools (accessible via the [d] hotkey) as well as multiple other devtools clients, including VSCode ↗︎. For most developers, breakpoint debugging via VSCode is the most natural flow, but until now it's required manually configuring a launch.json file ↗︎, running wrangler dev, and connecting via VSCode's built-in debugger. Now it's much more seamless!

Access RDP securely from your browser — now in open beta

Browser-based RDP with Cloudflare Access is now available in open beta for all Cloudflare customers. It enables secure, remote Windows server access without VPNs or RDP clients.

With browser-based RDP, you can:

  • Control how users authenticate to internal RDP resources with single sign-on (SSO), multi-factor authentication (MFA), and granular access policies.
  • Record who is accessing which servers and when to support regulatory compliance requirements and to gain greater visibility in the event of a security event.
  • Eliminate the need to install and manage software on user devices. You will only need a web browser.
  • Reduce your attack surface by keeping your RDP servers off the public Internet and protecting them from common threats like credential stuffing or brute-force attacks.
Example of a browsed-based RDP Access application

To get started, see Connect to RDP in a browser.

Enhanced support for static assets with the Cloudflare Vite plugin

You can now use any of Vite's static asset handling ↗︎ features in your Worker as well as in your frontend. These include importing assets as URLs, importing as strings and importing from the public directory as well as inlining assets.

Additionally, assets imported as URLs in your Worker are now automatically moved to the client build output.

Here is an example that fetches an imported asset using the assets binding and modifies the response.

// Import the asset URL
// This returns the resolved path in development and production
import myImage from "./my-image.png";

export default {
	async fetch(request, env) {
		// Fetch the asset using the binding
		const response = await env.ASSETS.fetch(new URL(myImage, request.url));
		// Create a new `Response` object that can be modified
		const modifiedResponse = new Response(response.body, response);
		// Add an additional header
		modifiedResponse.headers.append("my-header", "imported-asset");

		// Return the modified response
		return modifiedResponse;
	},
};

Refer to Static Assets in the Cloudflare Vite plugin docs for more info.

Cloudflare One Agent for Android (version 2.4.2)

A new GA release for the Android Cloudflare One Agent is now available in the Google Play Store ↗︎. This release contains improvements and new exciting features, including post-quantum cryptography. By tunneling your corporate network traffic over Cloudflare, you can now gain the immediate protection of post-quantum cryptography ↗︎ without needing to upgrade any of your individual corporate applications or systems.

Changes and improvements

  • QLogs are now disabled by default and can be enabled in the app by turning on Enable qlogs under Settings > Advanced > Diagnostics > Debug Logs. The QLog setting from previous releases will no longer be respected.
  • DNS over HTTPS traffic is now included in the WARP tunnel by default.
  • The WARP client now applies post-quantum cryptography ↗︎ end-to-end on enabled devices accessing resources behind a Cloudflare Tunnel. This feature can be enabled by MDM.
  • Fixed an issue that caused WARP connection failures on ChromeOS devices.

Cloudflare One Agent for iOS (version 1.11)

A new GA release for the iOS Cloudflare One Agent is now available in the iOS App Store ↗︎. This release contains improvements and new exciting features, including post-quantum cryptography. By tunneling your corporate network traffic over Cloudflare, you can now gain the immediate protection of post-quantum cryptography ↗︎ without needing to upgrade any of your individual corporate applications or systems.

Changes and improvements

  • QLogs are now disabled by default and can be enabled in the app by turning on Enable qlogs under Settings > Advanced > Diagnostics > Debug Logs. The QLog setting from previous releases will no longer be respected.
  • DNS over HTTPS traffic is now included in the WARP tunnel by default.
  • The WARP client now applies post-quantum cryptography ↗︎ end-to-end on enabled devices accessing resources behind a Cloudflare Tunnel. This feature can be enabled by MDM.

Remote bindings (beta) now works with Next.js — connect to remote resources (D1, KV, R2, etc.) during local development

We recently announced ↗︎ our public beta for remote bindings, which allow you to connect to deployed resources running on your Cloudflare account (like R2 buckets or D1 databases) while running a local development session.

Now, you can use remote bindings with your Next.js applications through the @opennextjs/cloudflare adaptor ↗︎ by enabling the experimental feature in your next.config.ts:

- initOpenNextCloudflareForDev();
+ initOpenNextCloudflareForDev({
+  experimental: { remoteBindings: true }
+ });

Then, all you have to do is specify which bindings you want connected to the deployed resource on your Cloudflare account via the experimental_remote flag in your binding definition:

{
	"r2_buckets": [
		{
			"bucket_name": "testing-bucket",
			"binding": "MY_BUCKET",
			"experimental_remote": true,
		},
	],
}
[[r2_buckets]]
bucket_name = "testing-bucket"
binding = "MY_BUCKET"
experimental_remote = true

You can then run next dev to start a local development session (or start a preview with opennextjs-cloudflare preview), and all requests to env.MY_BUCKET will be proxied to the remote testing-bucket — rather than the default local binding simulations.

Remote bindings & ISR

Remote bindings are also used during the build process, which comes with significant benefits for pages using Incremental Static Regeneration (ISR) ↗︎. During the build step for an ISR page, your server executes the page's code just as it would for normal user requests. If a page needs data to display (like fetching user info from KV), those requests are actually made. The server then uses this fetched data to render the final HTML.

Data fetching is a critical part of this process, as the finished HTML is only as good as the data it was built with. If the build process can't fetch real data, you end up with a pre-rendered page that's empty or incomplete.

With remote bindings support in OpenNext, your pre-rendered pages are built with real data from the start. The build process uses any configured remote bindings, and any data fetching occurs against the deployed resources on your Cloudflare account.

Want to learn more? Get started with remote bindings and OpenNext ↗︎.

Have feedback? Join the discussion in our beta announcement ↗︎ to share feedback or report any issues.

Run and connect Workers in separate dev commands with the Cloudflare Vite plugin

Workers can now talk to each other across separate dev commands using service bindings and tail consumers, whether started with vite dev or wrangler dev.

Simply start each Worker in its own terminal:

# Terminal 1
vite dev

# Terminal 2
wrangler dev

This is useful when different teams maintain different Workers, or when each Worker has its own build setup or tooling.

Check out the Developing with multiple Workers guide to learn more about the different approaches and when to use each one.

Data Security Analytics in the Zero Trust dashboard

Zero Trust now includes Data security analytics, providing you with unprecedented visibility into your organization sensitive data.

The new dashboard includes:

  • Sensitive Data Movement Over Time:

    • See patterns and trends in how sensitive data moves across your environment. This helps understand where data is flowing and identify common paths.
  • Sensitive Data at Rest in SaaS & Cloud:

    • View an inventory of sensitive data stored within your corporate SaaS applications (for example, Google Drive, Microsoft 365) and cloud accounts (such as AWS S3).
  • DLP Policy Activity:

    • Identify which of your Data Loss Prevention (DLP) policies are being triggered most often.
    • See which specific users are responsible for triggering DLP policies.
Data Security Analytics

To access the new dashboard, log in to Cloudflare One ↗︎ and go to Insights on the sidebar.

Increased blob size limits in Workers Analytics Engine

We’ve increased the total allowed size of blob fields on data points written to Workers Analytics Engine from 5 KB to 16 KB.

This change gives you more flexibility when logging rich observability data — such as base64-encoded payloads, AI inference traces, or custom metadata — without hitting request size limits.

You can find full details on limits for queries, filters, payloads, and more here in the Workers Analytics Engine limits documentation.

export default {
	async fetch(request, env) {
		env.analyticsDataset.writeDataPoint({
			// The sum of all of the blob's sizes can now be 16 KB
			blobs: [
				// The URL of the request to the Worker
				request.url,
				// Some metadata about your application you'd like to store
				JSON.stringify(metadata),
				// The version of your Worker this datapoint was collected from
				env.versionMetadata.tag,
			],
			indexes: ["sample-index"],
		});
	},
};
worker.tsts
export default {
	async fetch(request, env) {
		env.analyticsDataset.writeDataPoint({
			// The sum of all of the blob's sizes can now be 16 KB
			blobs: [
				// The URL of the request to the Worker
				request.url,
				// Some metadata about your application you'd like to store
				JSON.stringify(metadata),
				// The version of your Worker this datapoint was collected from
				env.versionMetadata.tag,
			],
			indexes: ["sample-index"],
		});
	}
};