Cloudflare changelogs

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.2100.0)

Wed, 07 Oct 2026 17:01:53 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This release includes the following highlights:

Traffic to split tunnel excluded resources is no longer briefly blocked while the client is connecting or reconnecting. The client now keeps its learned split tunnel configuration across reconnects.
Support for routing non-RFC 1918 local IPv4 networks through the tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Faster connects and lower memory use. The hosts file is now read once and shared across the client’s DNS resolvers instead of being reloaded by each one.

Additional changes and improvements

Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Individual DNS-over-HTTPS queries now time out instead of hanging when the upstream server stops responding.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Added an MDM setting to prefer IPv4 when resolving hostnames in proxy mode. The setting is off by default.
Fixed the client reconnecting while Emergency Disconnect was active after switching organizations or re-registering.
Fixed the client being unable to connect after an upgrade when its stored registration credentials no longer matched its configuration.
Fixed the client service restarting unexpectedly when it was slow to respond, such as after waking from sleep.
Fixed Extra Logging failing to capture packets across all interfaces.
Fixed an issue that could prevent remote diagnostics from completing.
Fixed DNS connectivity checks failing on IPv6-only networks.
Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report “No network” after a successful manual disconnect.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2100.0)

Wed, 07 Oct 2026 17:01:52 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This release includes the following highlights:

Traffic to split tunnel excluded resources is no longer briefly blocked while the client is connecting or reconnecting. The client now keeps its learned split tunnel configuration across tunnel reconnections.
Support for routing non-RFC 1918 local IPv4 networks through the tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved connection reliability on devices with very large hosts files. The client now detects a large hosts file, allows more time for its initial DNS check, and shows a banner letting the user know that connecting may take longer.
Faster tunnel reconnections and lower memory use. The hosts file is now read once and shared across the client’s DNS resolvers instead of being reloaded by each one.
A service recovery mechanism, backed by a Windows scheduled task, now starts the client service on system unlock if it is not already running. This is enabled by default.

Additional changes and improvements

Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Individual DNS-over-HTTPS queries now time out instead of hanging when the upstream server stops responding.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Added an MDM setting to prefer IPv4 when resolving hostnames in proxy mode. The setting is off by default.
The client no longer requires the Windows WLAN AutoConfig service to be running.
Fixed the client reconnecting while Emergency Disconnect was active after switching organizations or re-registering.
Fixed the client being unable to connect after an upgrade when its stored registration credentials no longer matched its configuration.
Fixed the client service restarting unexpectedly when it was slow to respond, such as after waking from sleep.
Fixed the client service failing to restart after an unexpected termination.
Fixed the client UI getting stuck in a connecting state after sleep and wake even though the tunnel was connected.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report “No network” after a successful manual disconnect.
Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation.
Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
Fixed the client UI crashing at startup when it could not write to the Windows registry.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

A Windows DNS client regression may cause connectivity check failures on systems containing large hosts files. While this release includes a fix to mitigate this issue, users may still experience reduced DNS performance and connectivity check failures.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.8.2100.0)

Wed, 07 Oct 2026 16:34:14 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release includes the following highlights:

Traffic to split tunnel excluded resources is no longer briefly blocked while the client is connecting or reconnecting. The client now keeps its learned split tunnel configuration across reconnects.
Support for routing non-RFC 1918 local IPv4 networks through the tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Faster tunnel reconnections and lower memory use. The hosts file is now read once and shared across the client’s DNS resolvers instead of being reloaded by each one.
Added an MDM setting to prefer IPv4 when resolving hostnames in proxy mode. The setting is off by default.

Additional changes and improvements

Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Individual DNS-over-HTTPS queries now time out instead of hanging when the upstream server stops responding.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Fixed the client reconnecting while Emergency Disconnect was active after switching organizations or re-registering.
Fixed the client being unable to connect after an upgrade when its stored registration credentials no longer matched its configuration.
Fixed the client service restarting unexpectedly when it was slow to respond, such as after waking from sleep.
Fixed the client window not appearing on first launch after a fresh install on RHEL 10.
Fixed duplicate WARP routing policy rules accumulating on reconnect.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report “No network” after a successful manual disconnect.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

When in DNS Only mode, the client may send DNS queries for names that are configured for Local Domain Fallback to the encrypted DNS server instead of falling back to the system configuration. Local Domain Fallback works as expected in other client modes.

Cloudflare Fundamentals, Cloudflare One, Gateway, Organizations - Cloudflare Organizations is generally available

Wed, 07 Oct 2026 00:00:00 GMT

Cloudflare Organizations is now generally available for Enterprise customers and MSSP/Distributor partners.

Organizations provides a top-level container for centrally managing accounts, members, analytics, and shared policies. Organization Super Administrators receive implicit access to every account in their Organization without requiring separate account memberships.

Enterprise customers can manage accounts in a single-tier Organization. MSSP/Distributor partners can use nested sub-organizations to manage customer accounts.

Organization Roles remains in beta, and current product limitations still apply.

For more information, refer to Cloudflare Organizations and current limitations.

CASB - Detect organization-specific risks with CASB custom finding types

Mon, 05 Oct 2026 00:00:00 GMT

Cloudflare CASB now supports custom finding types, giving security teams full control over the security conditions CASB detects across their SaaS and cloud integrations.

In addition to CASB's library of standard finding types, you can now write your own detection logic using Rego ↗︎, the open-source policy language from Open Policy Agent (OPA). Use custom finding types to match your organization's own thresholds and exceptions, such as flagging admin accounts without two-factor authentication, and get higher-confidence findings to act on.

Key capabilities

Write your own detection logic — Define exactly what CASB flags using Rego expressions evaluated against asset data from your connected integrations.
Target any supported provider and asset class — Scope a custom finding type to a provider (such as Google Workspace or Microsoft 365) and asset class (such as users, files, or groups), and apply it to all integrations for that provider or a selected subset.
Built-in validation — Select Validate to check your expression for syntax errors and schema issues before you create the finding type.
Inspect and duplicate standard finding types — Open any standard finding type to view its detection logic, then duplicate it as the starting point for a custom finding type.
Works with CASB policies — Use custom finding types in CASB remediation policies to send matching findings to Slack, ServiceNow, or any other webhook destination.

Get started

In Cloudflare One ↗︎, go to Cloud & SaaS findings > Findings library.
Select Create finding.
Enter a name, description, and severity.
Select a provider and asset class, then set the integration scope.
Write your Rego expression and select Validate.
Select Create finding.

CASB evaluates the custom finding type against assets as they are created or updated within the selected scope. Matching assets appear as posture finding instances under Posture Findings.

Learn more

Learn how to create and manage custom finding types in Cloudflare One.
Learn how to manage findings in Cloudflare One.
Learn how to create and manage CASB remediation policies in Cloudflare One.

CASB custom finding types are now available in Cloudflare One.

Cloudflare WAN, Magic Transit, Cloudflare One - BGP over IPsec and GRE tunnels generally available

Mon, 05 Oct 2026 00:00:00 GMT

BGP peering over IPsec and GRE tunnels is generally available for Cloudflare WAN and Magic Transit. You can use it for production workloads.

BGP peering exchanges routes dynamically between your devices and your Cloudflare virtual network routing table. You no longer need to update static routes manually as your network changes.

BGP over IPsec and GRE tunnels is available to all accounts that use Unified Routing. No enablement is required. BGP over CNI remains in closed beta.

For configuration details, refer to:

Access, Cloudflare One - New strict service token authentication setting for Access

Fri, 02 Oct 2026 00:00:00 GMT

The strict service token authentication setting applies consistent behavior to requests made with service tokens. When the setting is on for a Zero Trust organization, Access handles requests with service token headers as follows:

If authentication or authorization fails, Access always returns 401 or 403 instead of redirecting the client to the login page with 302.
Only Service Auth policies can authorize the request. Access ignores Allow policies and any CF_Authorization cookie sent with the request.
Access does not return a CF_Authorization cookie to the client after successful authentication. Subsequent requests should continue to use service token headers.
Failed requests for recognized service tokens appear in Access authentication logs.

Zero Trust organizations created on or after October 5, 2026 have strict service token authentication turned on by default and cannot turn it off. Cloudflare recommends that existing organizations turn it on as well.

Organizations created before October 5, 2026 can configure the setting in the dashboard or through the API.

In the Cloudflare dashboard ↗︎, go to Zero Trust > Access controls > Access settings.
Go to Access settings ↗
Under Manage service tokens, turn on Strict service token authentication.
In the confirmation dialog, select Enable.

To turn off strict service token authentication, turn off the setting and select Disable.

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/organizations" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"strict_service_token_auth": true
	}'

To turn off strict service token authentication, set strict_service_token_auth to false.

For behavior and configuration details, refer to Strict service token authentication.

Cloudflare Tunnel - Protect Quick Tunnels with email authentication

Fri, 02 Oct 2026 00:00:00 GMT

You can now restrict who can access a Quick Tunnel. Use the new --allowed-mail flag in cloudflared to require visitors to authenticate with a one-time PIN sent to their email before they reach your local service.

cloudflared tunnel --url http://localhost:8080 --allowed-mail alice@example.com

Previously, anyone with a trycloudflare.com URL could access the service behind it. Protected Quick Tunnels let you share a local development server, webhook receiver, or demo with specific people without creating a Cloudflare account or configuring a domain.

You can allow:

A single email address: --allowed-mail alice@example.com
Multiple email addresses, by repeating the flag or using a comma-separated list: --allowed-mail 'alice@example.com,bob@example.com'
Every address on a domain: --allowed-mail '*@example.com'

Visitors do not need a Cloudflare account. Access ends for everyone when you stop the cloudflared process.

To get started, update cloudflared to the latest version and refer to Restrict access by email.

Cloudflare One, Access - Simplified permissions for tagging targets with Access for Infrastructure

Thu, 01 Oct 2026 00:00:00 GMT

You can now tag targets using only the Zero Trust Write API token permission. Previously, tagging targets through the API required both Zero Trust Write and Tag Write permissions on the API token.

This change applies to inline target tagging through the Infrastructure Access Targets API. Tagging resources through the general Resource Tagging API still requires the Tag Admin, Tag Write, or equivalent role.

For more information, refer to Tag targets.

Workers - Web Crypto adds ML-KEM and ML-DSA support

Thu, 01 Oct 2026 00:00:00 GMT

The Workers Web Crypto API now supports ML-KEM-768, ML-KEM-1024, ML-DSA-44, ML-DSA-65, and ML-DSA-87. ML-KEM establishes shared secrets, while ML-DSA signs and verifies data.

The opt-in API also adds key encapsulation and decapsulation methods, getPublicKey(), SubtleCrypto.supports(), and JSON Web Keys (JWKs) with the AKP key type.

Turn on the webcrypto_modern_algorithms compatibility flag to use these features:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "compatibility_flags": [
    "webcrypto_modern_algorithms"
  ]
}

compatibility_flags = ["webcrypto_modern_algorithms"]

This example uses ML-KEM-768 to establish the same shared secret on both sides:

src/index.jsjs

const keyPair = await crypto.subtle.generateKey("ML-KEM-768", false, [
	"encapsulateBits",
	"decapsulateBits",
]);

if (!("publicKey" in keyPair)) {
	throw new Error("Expected an ML-KEM key pair");
}

const { sharedKey, ciphertext } = await crypto.subtle.encapsulateBits(
	"ML-KEM-768",
	keyPair.publicKey,
);

const recoveredSharedKey = await crypto.subtle.decapsulateBits(
	"ML-KEM-768",
	keyPair.privateKey,
	ciphertext,
);

src/index.tsts

const keyPair = await crypto.subtle.generateKey("ML-KEM-768", false, [
	"encapsulateBits",
	"decapsulateBits",
]);

if (!("publicKey" in keyPair)) {
	throw new Error("Expected an ML-KEM key pair");
}

const { sharedKey, ciphertext } = await crypto.subtle.encapsulateBits(
	"ML-KEM-768",
	keyPair.publicKey,
);

const recoveredSharedKey = await crypto.subtle.decapsulateBits(
	"ML-KEM-768",
	keyPair.privateKey,
	ciphertext,
);

Workers implements a subset of the evolving Modern Algorithms in the Web Cryptography API ↗︎ draft. ML-KEM-512 and the draft's other algorithms are not supported. The API may change as the draft evolves.

For current algorithm and operation support, refer to Web Crypto supported algorithms.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2033.1)

Wed, 30 Sep 2026 02:01:09 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
The client no longer requires the Windows WLAN AutoConfig service to be running.
Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
Fixed the client UI crashing at startup when it could not write to the Windows registry.
Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

For Zero Trust documentation, see: https://developers.cloudflare.com/cloudflare-one/team-and-resources/devices/cloudflare-one-client/ For Consumer documentation, see: https://developers.cloudflare.com/warp-client/

Browser Isolation, Gateway, Cloudflare One - Role-based access control for Browser Isolation policies

Wed, 30 Sep 2026 00:00:00 GMT

Isolation policies support role-based access control (RBAC). Because isolation policies are Gateway HTTP policies with the Isolate action, Gateway's account-level and resource-scoped roles apply to them directly.

Use the Zero Trust HTTP Policies Admin account-level role to grant access to all HTTP policies in the account. You can also assign a resource-scoped role to let a team member manage a specific isolation policy without exposing other Gateway resources.

Policy settings such as copy/paste, file download/upload, keyboard, and printing are part of the policy object and follow the same permissions.

For setup instructions, refer to Granular permissions for Gateway.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2028.1)

Tue, 29 Sep 2026 09:45:17 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
The client no longer requires the Windows WLAN AutoConfig service to be running.
Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
Fixed the client UI crashing at startup when it could not write to the Windows registry.
Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.2028.1)

Tue, 29 Sep 2026 09:45:16 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Fixed Extra Logging failing to capture packets across all interfaces.
Fixed an issue that could prevent remote diagnostics from completing.
Fixed DNS connectivity checks failing on IPv6-only networks.
Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Cloudflare Mesh, Cloudflare Tunnel, Cloudflare One, Gateway, Workers VPC - Identify Mesh, Workers VPC, and Cloudflare Tunnel replicas in network logs

Tue, 29 Sep 2026 00:00:00 GMT

You can now tell a person on a laptop apart from a Mesh node or an AI agent running on Workers, without matching on connector email addresses or Mesh IP ranges — and see exactly which Cloudflare Tunnel and cloudflared replica received each session.

Gateway network logs and Zero Trust Network Session Logs now identify two new kinds of traffic:

Mesh — Traffic sent from or delivered to a Cloudflare Mesh node. Previously, Mesh nodes were logged the same way as devices running the Cloudflare One Client, because Mesh nodes run the client in headless mode.
Workers VPC — Traffic sent by a Worker through a Workers VPC binding. Previously, Workers VPC sessions were not recorded in Network Session Logs.

Gateway network logs

To view these values in the dashboard, go to Zero Trust > Insights & Logs > Logs > Network logs, select Columns, and turn on Traffic Source and Traffic Destination. Both values also appear under Network query details when you open a log entry.

Network Session Logs

The zero_trust_network_sessions dataset, available through Logpush, includes the following fields:

Field	Description
`OnrampType`	How the session entered Cloudflare One. Values: `CF1_CLIENT`, `MESH`, `WORKERS_VPC`, `MAGIC`, `OTHER`.
`Offramp`	Where the session was routed. Sessions routed to a Mesh node report `MESH`.
`SourceName`	Name of the Worker that started the session. Only populated for Workers VPC sessions.
`SourceID`	Stable identifier of the Worker that started the session. Only populated for Workers VPC sessions.
`DestinationReplicaID`	The replica that served the session, such as a specific replica of a Mesh node or a `cloudflared` replica of a Cloudflare Tunnel.

For example, OnrampType = 'WORKERS_VPC' AND Offramp = 'MESH' returns every session where a Worker reached a service behind a Mesh node, and SourceName tells you which Worker it was.

See which tunnel and replica received a session

With DestinationReplicaID, you can now confirm which Cloudflare Tunnel and which cloudflared replica received traffic for a specific session. Combine it with the existing DestinationTunnelID field to trace a session to an exact tunnel replica — or Mesh node replica — when you run multiple replicas for high availability. The replica ID matches the Connector ID shown in the dashboard, so you can stream that replica's logs with cloudflared tail --connector-id.

Sessions logged before this change are not backfilled. For all available fields, refer to Zero Trust Network Session Logs.

Workers - Workers Cache — mark cached responses stale with invalidate()

Tue, 29 Sep 2026 00:00:00 GMT

Workers Cache now supports invalidate(), the soft counterpart of purge(). purge() deletes matching cached responses, so the next request is a cache miss. invalidate() keeps them but marks them stale, so the cache revalidates them with your Worker instead.

To revalidate a response, the cache sends your Worker a conditional request built from the validators stored with it — for example, If-None-Match carrying the cached ETag. If your Worker answers 304 Not Modified, the cache keeps the stored body. If your Worker answers with a full 200 response, that response replaces the cached one.

invalidate() accepts the same options as purge(): tags, pathPrefixes, or purgeEverything. It follows the same per-entrypoint scoping and resolves to the same result object. Call it as ctx.cache.invalidate(), or import cache from cloudflare:workers and call cache.invalidate().

Use invalidate() when one call covers many cached responses but only some of them changed. Your Worker needs to emit ETag or Last-Modified and answer matching conditional requests with 304. Each unchanged response then costs a validator check instead of a full regeneration:

src/index.jsjs

export default {
	async fetch(request, env, ctx) {
		if (request.method === "POST") {
			// Write the updated catalog, then mark every cached product page stale.
			await syncCatalog(env, await request.json());
			await ctx.cache.invalidate({ tags: ["products"] });
			return new Response("Synced");
		}

		const product = await getProduct(env, request);
		const etag = `"${product.revision}"`;
		const headers = {
			"Cache-Control": "public, max-age=86400",
			"Cache-Tag": "products",
			ETag: etag,
		};

		// The product has not changed since it was cached. Answer 304, and the
		// cache keeps the body it already has.
		if (request.headers.get("If-None-Match") === etag) {
			return new Response(null, { status: 304, headers });
		}

		return new Response(renderProductPage(product), { headers });
	},
};

src/index.tsts

export default {
	async fetch(request, env, ctx): Promise<Response> {
		if (request.method === "POST") {
			// Write the updated catalog, then mark every cached product page stale.
			await syncCatalog(env, await request.json());
			await ctx.cache.invalidate({ tags: ["products"] });
			return new Response("Synced");
		}

		const product = await getProduct(env, request);
		const etag = `"${product.revision}"`;
		const headers = {
			"Cache-Control": "public, max-age=86400",
			"Cache-Tag": "products",
			ETag: etag,
		};

		// The product has not changed since it was cached. Answer 304, and the
		// cache keeps the body it already has.
		if (request.headers.get("If-None-Match") === etag) {
			return new Response(null, { status: 304, headers });
		}

		return new Response(renderProductPage(product), { headers });
	},
} satisfies ExportedHandler<Env>;

For more information, refer to Invalidate cached responses.

Workers, Cloudflare CLI - Cloudflare CLI is now in beta

Mon, 28 Sep 2026 00:00:00 GMT

The Cloudflare CLI, cf, is now in beta. cf is one command-line interface for the public Cloudflare API and for Workers projects. Use it to manage zones, DNS, storage, and security settings, and to create, develop, and deploy Workers, without switching between tools.

Install cf globally, then sign in:

npm install --global cf

yarn global add cf

pnpm add --global cf

bun add --global cf

cf auth login

With cf, you can:

Manage resources across Cloudflare. More than 2,900 commands cover the public Cloudflare API, and most print their results as JSON.
Create and deploy Workers. cf init creates a project that uses cloudflare.config.ts, a typed configuration file. cf dev, cf build, and cf deploy develop, build, and deploy it.
Move from Wrangler. cf migrate converts a Wrangler configuration file to cloudflare.config.ts. You can also run cf resource commands in an existing Wrangler project without migrating it.
Work with coding agents. cf cli search finds the command for a task from a plain-language description, so an agent can find and run commands without prior knowledge of cf.

cf is in beta. Commands, configuration, and Build Output can change before the stable release.

To get started, refer to Install and sign in. To move an existing project, refer to Migrate a Wrangler project.

Cloudflare Network Firewall, Magic Transit, Cloudflare WAN - Managed Rulesets supported in Unified Routing

Fri, 25 Sep 2026 00:00:00 GMT

Cloudflare Advanced Network Firewall Managed Rulesets are now supported for accounts using Unified Routing mode.

For the full list of feature availability, refer to Check feature availability before upgrading.

Workers - Workers tracing — new getActiveSpan(), recordException(), startSpan(), and setAttributes() APIs

Fri, 25 Sep 2026 00:00:00 GMT

Custom spans in Workers now support more of the OpenTelemetry span API, so you can instrument more of your code and record errors directly on your spans.

tracing.startSpan(name) creates a span without making it the active span, and returns it. Other spans do not nest under it. Call span.end() when the operation is complete.
tracing.getActiveSpan() returns the currently active span. Use it to annotate the current span from helper functions and libraries without passing the span object through your code. Outside any custom span, it returns the invocation's root span.
span.recordException(exception) records an exception event on a span. It accepts an Error, a string, or an object with a code, name, or message.
span.setAttributes(attributes) sets multiple attributes at once. setAttribute() and setAttributes() now return the span, so you can chain calls.

src/index.jsjs

import { tracing } from "cloudflare:workers";

export default {
	async fetch(request, env) {
		const user = await authenticate(request, env);

		// Annotate the invocation's root span
		tracing.getActiveSpan()?.setAttributes({
			"user.id": user.id,
			"user.plan": user.plan,
		});

		const span = tracing.startSpan("load-profile");
		try {
			return Response.json(await loadProfile(env, user.id));
		} catch (err) {
			span.recordException(err);
			throw err;
		} finally {
			span.end();
		}
	},
};

src/index.tsts

import { tracing } from "cloudflare:workers";

export default {
	async fetch(request: Request, env: Env): Promise<Response> {
		const user = await authenticate(request, env);

		// Annotate the invocation's root span
		tracing.getActiveSpan()?.setAttributes({
			"user.id": user.id,
			"user.plan": user.plan,
		});

		const span = tracing.startSpan("load-profile");
		try {
			return Response.json(await loadProfile(env, user.id));
		} catch (err) {
			span.recordException(err as Error);
			throw err;
		} finally {
			span.end();
		}
	},
};

For more details, refer to the custom spans documentation.

Workers - See every release and gradual deployment on Workers Metrics charts

Fri, 25 Sep 2026 00:00:00 GMT

Workers Metrics charts now show every release in the selected time range, including the full progression of gradual deployments. This makes it easier to correlate changes in memory, CPU time, errors, or latency with the code that was serving traffic.

A gradual deployment appears as a single rollout across the chart, with shading that increases as more traffic moves to the new version. Hover over a rollout to see the previous and new versions, the rollout duration, and the traffic percentage configured at each step.

Use these annotations to:

Find when a regression started — See which traffic percentage was configured when errors, latency, CPU time, or wall time changed.
Compare rollout stages — Check whether a metric changed as more traffic moved to the new version.
Confirm rollbacks — Rollbacks appear as separate release events, so you can check whether metrics recovered after a rollback.

Direct deployments that send 100% of traffic to a single version still appear as individual markers. Nearby direct deployments are grouped to reduce visual clutter. Versions that are only uploaded, or only configured at 0%, do not appear on metrics charts.

To view release annotations, open the Metrics tab for your Worker ↗︎.

Access, Cloudflare One - MCP server portals are now generally available

Thu, 24 Sep 2026 00:00:00 GMT

MCP server portals are now generally available to all Cloudflare customers. A portal gives users one endpoint for approved Model Context Protocol (MCP) servers. Cloudflare Access logs tool, prompt, and resource activity.

Since the open beta, MCP server portals have added:

Gateway routing for HTTP logging and data loss prevention (DLP) scanning
Code Mode policies that control how portals reduce tool definitions and token use
Static OAuth client credentials for providers that do not support Dynamic Client Registration
Session management for reconnecting servers and changing authorizations from the portal
Service token authentication for autonomous agents and machine-to-machine access
Logpush support for exporting portal activity to external storage or a security information and event management (SIEM) system

To create a portal and connect an MCP client, refer to MCP server portals.

Gateway, Cloudflare One - Traffic Destination selector in Gateway policies

Wed, 23 Sep 2026 00:00:00 GMT

Gateway HTTP and Network policies now include a Traffic Destination selector that identifies how traffic exits Cloudflare. This allows administrators to write policies that target specific off-ramp methods - for example, applying different rules to traffic destined for the public Internet compared to traffic routed through Cloudflare Tunnel or Cloudflare WAN.

Available traffic destination values

UI name	API value	Description
Internet	`internet`	Traffic to the public Internet
Cloudflare WAN	`cloudflare_wan`	Traffic through a Cloudflare WAN connection
Cloudflare Tunnel	`cloudflare_tunnel`	Traffic to a private origin through Cloudflare Tunnel
Cloudflare One Client	`device_client`	Traffic to another device running the Cloudflare One Client
Mesh	`mesh`	Traffic through a Cloudflare Mesh node

The selector uses the net.offramp.type API field in both HTTP and Network policies.

UI name	API example
Traffic Destination	`net.offramp.type == "internet"`

For more information, refer to HTTP policies and Network policies.

Cloudflare Images - View transformation analytics in Images

Wed, 23 Sep 2026 00:00:00 GMT

You can now view account-level analytics for your Images transformation usage.

Go to Images & Stream > Transformations > Analytics to view sampled estimates of image transformation request traffic, including:

Requests by source, split between URL-based transformations and Images binding transformations
Top zones, transformation configurations, and origin hosts for URL-based requests
Top Worker scripts for Images binding requests

Use these analytics to identify the zones, configurations, origins, and Workers generating the most image transformation requests.

Cloudflare One, Cloudflare Mesh - Add Mesh participants with guided onboarding

Wed, 23 Sep 2026 00:00:00 GMT

Cloudflare Mesh now makes it faster to add and manage participants from the dashboard. Select Add participant from Networking > Mesh to deploy a Mesh node or find the information needed to connect a client device.

The updated dashboard includes the following improvements:

More Mesh node deployment options — Install a node on Linux, Kubernetes, Docker Compose, or Docker CLI. The dashboard provides requirements, commands, configuration, and links for each method. Refer to Run Mesh in Docker / Kubernetes for container deployment details.
Client device installation guidance — Access platform-specific Cloudflare One Client installers, mobile QR codes, and your Cloudflare One organization name. Use the organization name to log in from the client after installation.
Unified participant management — View Mesh nodes and enrolled client devices in one table. Search devices, filter participants by type or status, open device details, and load additional results from each participant source. If one source fails, participants from the other source remain available while you retry the request.

You must still install the Cloudflare One Client, log in to your organization, and test the connection.

For complete setup instructions, refer to Get started with Cloudflare Mesh.

Access - Automatically manage inactive Access service tokens

Tue, 22 Sep 2026 00:00:00 GMT

Cloudflare Access administrators can now automatically disable or delete inactive service tokens. Administrators can set an inactivity period from 30 to 365 days and choose what Access does when a token reaches that limit.

To be eligible for cleanup, a token must be older than the configured period, must not have successfully authenticated during that period, and must not be directly referenced by an Access policy rule. Cleanup runs gradually in the background, so eligible tokens may not be disabled or deleted immediately.

For configuration instructions, refer to Manage inactive service tokens.

Cloudflare One, Access - Private MCP server support for MCP server portals

Tue, 22 Sep 2026 00:00:00 GMT

MCP server portals can now connect to MCP servers available only on your private network. The portal uses Cloudflare Gateway to reach private hostnames and IP addresses without exposing the MCP server to the public Internet.

Connect the server network to Cloudflare with Cloudflare Tunnel, Cloudflare Mesh, or another Cloudflare One connector. Configure a private hostname or CIDR route, then turn on Route traffic through Cloudflare Gateway when you add the server. OAuth authorization server endpoints, such as the authorization and token endpoints, must be accessible on the public Internet. If Cloudflare automatically registers the OAuth client through Dynamic Client Registration (DCR), the registration endpoint must also be accessible on the public Internet.

For setup instructions, refer to Connect a private MCP server.

Workers - Workers Builds now supports Cursor Origin

Tue, 22 Sep 2026 00:00:00 GMT

Workers Builds now supports repositories hosted in Cursor Origin. Connect a Cursor Origin repository to automatically build and deploy production changes, preview non-production branches, and see build status in pull requests.

Pushes to your production branch automatically build and deploy your Worker. When you enable non-production branch builds, each branch receives a version-specific preview URL and a stable preview URL that follows the latest build.

Cloudflare posts build status and preview links to the Cursor Origin pull request and creates a check run for each triggered build.

To get started, install the Cloudflare app in Cursor ↗︎, choose the Cursor Origin repositories Cloudflare can access, and follow the prompts to configure your Worker build. For details, refer to the Cursor Origin integration.

Workers - Test every pull request in an isolated environment with Worker Previews

Tue, 22 Sep 2026 00:00:00 GMT

You can now test every change you make in an isolated, production-like environment with Worker Previews ↗︎. Each Preview runs under the same Worker with its own code, configuration, URL, and observability, isolated from production and every other Preview.

Configure each Preview

Define the variables, bindings, and settings that new Previews start with in the previews block of your Wrangler configuration file. Set secrets with Wrangler commands. You can override one Preview without changing production or other Previews.

For Durable Objects and Containers, Cloudflare automatically provisions separate namespaces, storage, apps, and instances for every Preview. State changes, sessions, memory, migrations, and concurrent tests remain scoped to that Preview. To isolate KV, D1, R2, or another account-level resource, bind the Preview to a separate resource.

Use Wrangler 4.135.0 or later to deploy a Preview:

npx wrangler preview

Or connect your repository to Workers Builds to create Previews automatically and post their URLs to pull requests.

Each Preview gets a stable URL that updates with every push, so reviewers always see the latest changes. Each deployment also gets an immutable URL, so you can compare or return to an exact version.

After you create a Preview, use the environment breadcrumb next to your Worker's name to switch between Production and every Preview:

Inspect and revise before production

Each Preview has its own logs, errors, metrics, and traces. Send traffic to its URL, inspect what happened, push a fix, and verify the next deployment before production.

Use production-like hostnames

Serve Preview URLs on workers.dev, a custom domain, or both. Custom domains let authentication providers, cookies, cross-origin resource sharing (CORS), and OAuth redirects work as they will in production. You can also protect Preview URLs with Cloudflare Access.

Configure a domain for Preview traffic from the Worker's Domains tab:

For setup instructions and current limitations, refer to the Worker Previews documentation.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.1755.1)

Mon, 21 Sep 2026 18:14:56 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Fixed Extra Logging failing to capture packets across all interfaces.
Fixed an issue that could prevent remote diagnostics from completing.
Fixed DNS connectivity checks failing on IPv6-only networks.
Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.1755.1)

Mon, 21 Sep 2026 18:14:46 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Fixed an issue that could briefly block traffic to split tunnel excluded resources while the client was connecting or reconnecting.
Improved reauthentication reliability and fixed an issue where a reauthentication could force a new registration.
Improved client reaction to the current network lowering its MTU.
Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
The client no longer requires the Windows WLAN AutoConfig service to be running.
Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
Fixed the client UI crashing at startup when it could not write to the Windows registry.
Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Workers - Give teammates access to specific Workers directly from the dashboard

Mon, 21 Sep 2026 00:00:00 GMT

You can now grant teammates scoped access to specific Workers directly from the Workers dashboard.

Go to your Worker and click Invite.

Enter the teammate's email address, choose the appropriate access level, and click Invite.

You can grant a user one of the following access levels:

Metadata Read-Only: View settings, metrics, logs, and traces without access to Worker code or the ability to make changes.
Content Read-Only: Read Worker code, settings, and observability data without the ability to modify or deploy changes.
Editor: Update and deploy a Worker without the ability to delete it.
Admin: Everything included with Editor, plus the ability to delete the Worker.

If the teammate is already an account member, they will receive access to the Worker immediately. If they are not an account member, Cloudflare will send them an invitation to join the account, and they will receive access to the Worker after accepting the invitation.

Only account members with the Super Administrator role can invite users from a Worker's dashboard.

For details about available roles and scopes, refer to the Workers roles and permissions documentation.

Cloudflare WAN, Magic Transit, Cloudflare One - Unified Routing generally available

Fri, 18 Sep 2026 00:00:00 GMT

Unified Routing is generally available for Cloudflare WAN and Magic Transit.

Unified Routing improves the integration between Cloudflare One and the standard connectivity onramps supported by Cloudflare WAN. It is capable of many new features including Automatic Return Routing, BGP and custom client subnets.

We recommend Unified Routing for all new accounts.

For details, refer to Cloudflare WAN traffic steering and Magic Transit traffic steering.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - cloudflared to deprecate 32-bit Windows and Intel-based macOS builds in 2027

Fri, 18 Sep 2026 00:00:00 GMT

Starting in 2027, Cloudflare will deprecate 32-bit Windows and Intel-based macOS builds of cloudflared. After the deprecation takes effect, Cloudflare will no longer publish new cloudflared releases for either architecture.

Windows 10, the last Windows release to support 32-bit systems, reached end of support in October 2025. Apple has also deprecated Intel-based Mac computers. macOS 26 Tahoe, released in September 2025, was the final macOS release to support Intel-based Macs. macOS 27, released in September 2026, no longer supports them.

Focusing development on currently supported architectures allows cloudflared to align with operating system support and continue receiving updates on supported platforms. For available downloads and supported platforms, refer to the Cloudflare Tunnel downloads documentation.

Workers, Durable Objects - Workers traces now automatically include JavaScript RPC session spans

Thu, 17 Sep 2026 00:00:00 GMT

Workers traces can now follow JavaScript RPC calls across Worker boundaries and into Durable Objects. Previously, a trace stopped at the caller's RPC boundary. The dashboard now shows the caller-side session and method calls alongside the callee invocation, nested calls, and callbacks into another Worker.

A session span covers the lifetime of a caller-side session and groups calls that reuse it. Individual call spans show each method invocation. Execution colors distinguish the Workers or Durable Object entrypoints involved, while arrows mark outgoing and incoming calls. Together, these details show where time was spent, which calls reused a session, and how returned stubs and callbacks fit into the request.

Enable tracing with one setting in your Wrangler configuration file:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "observability": {
    "traces": {
      "enabled": true
    }
  }
}

[observability.traces]
enabled = true

Cloudflare records these spans automatically. You do not need to change your application code or add an observability SDK.

For supported spans and attributes, refer to Spans and attributes.

Cloudflare One, Access - Access for Infrastructure now supports tagged targets and tag-based target criteria

Tue, 15 Sep 2026 00:00:00 GMT

Access for Infrastructure now integrates with Resource Tagging. You can attach key-value tags to infrastructure targets and use them in access policies.

You can manage tags on targets inline when you create or edit a target or through the central Resource Tagging API. Cloudflare keeps tags in sync across both methods.

Infrastructure applications also support a target criteria model with include, require, and exclude operators. Each operator can match targets by hostname, tag, or both.

Include matches targets that have any of the specified values.
Require matches targets that have all of the specified values.
Exclude rejects targets that have any of the specified values.

For more information, refer to Add an infrastructure application.

Workers - Grant teammates and agents access to specific Workers

Tue, 15 Sep 2026 00:00:00 GMT

You can now grant access to specific Workers and choose from four roles to control the level of access you give teammates, agents, and CI/CD workflows.

Choose from four roles to control the level of access:

Metadata Read-Only: View settings, metrics, logs, and traces without access to Worker code or the ability to make changes.
Content Read-Only: Read Worker code, settings, and observability data without the ability to modify or deploy changes.
Editor: Update and deploy a Worker without the ability to delete it.
Admin: Everything in Editor, plus the ability to delete the Worker.

Worker-level access controls are available today for all customers. You can configure them in the Cloudflare dashboard, through the API, or with Terraform.

Roles designed for how teams build

Give Metadata Read-Only to a debugging agent so it can inspect settings and observability data without seeing Worker code. Give Content Read-Only to a code review agent so it can read code without changing it. Give Editor to a CI/CD workflow so it can deploy without deleting the Worker or accessing other Workers. Admin gives a teammate or agent full control over the Worker, including the ability to delete it.

Apply these roles across all Developer Platform products, across all Workers, or to an individual Worker.

Durable Objects

You can use granular permissions to control access to Durable Objects. Durable Objects do not have their own roles or scopes. Instead, they inherit the permissions assigned to the Worker that implements them.

Learn more about granular permissions in the Durable Objects documentation.

Grant access to members and User Groups

In the Cloudflare dashboard, go to Manage Account > Members and select a member. Create a permission policy, set the scope to Individual Workers, select the Workers they need, and choose a role to grant the right level of access.

If several people on the same team or project need the same access, assign the permission policy to a User Group instead of each member individually. Everyone added to the group automatically inherits the policy.

Create a scoped API token

For an agent or CI/CD workflow, go to Manage Account > Account API Tokens and create an account-owned API token. Set the scope to Specified Workers, select the Workers the token can access, and choose a role to grant the right level of access.

For more information, refer to the Workers roles and permissions documentation.

Access - Require fresh authentication for SAML identity providers

Mon, 14 Sep 2026 00:00:00 GMT

Cloudflare Access can now request fresh authentication from a SAML identity provider for every login. Turn on Require reauthentication in the Cloudflare dashboard, or set force_authn to true through the API. Access will then set ForceAuthn to true in signed and unsigned SAML authentication requests.

This option is useful when an application requires users to reauthenticate at the identity provider instead of relying on an existing identity provider session. The default value is false.

For configuration details, refer to Require fresh authentication at the identity provider.

Data Loss Prevention - Discover where sensitive data goes before you create a Data Loss Prevention policy

Mon, 14 Sep 2026 00:00:00 GMT

Passive Detection for Cloudflare Data Loss Prevention (DLP) lets you learn from your Gateway traffic before deciding what to log or block. Discover the sensitive data types in sampled traffic, explore their destinations, and use the findings to build policies around your organization's needs.

The dashboard brings together detections from sampled HTTP request and response bodies. Select an entry to follow its detections over time, review destinations, and check policy coverage. You do not need a Gateway DLP policy to get these insights, and existing Gateway policies continue to apply.

Passive Detection is generally available. The detection entries available to your account depend on your Zero Trust plan.

To get started, refer to the Passive Detection documentation.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.1290.1)

Wed, 09 Sep 2026 18:10:27 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
Fixed Extra Logging failing to capture packets across all interfaces.
Fixed an issue that could prevent remote diagnostics from completing.
Fixed DNS connectivity checks failing on IPv6-only networks.
Fixed the client service exiting when its route-monitoring socket was closed after sleep or wake.
Fixed DNS enforcement checks making the client service unresponsive on systems with large routing tables.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.1290.1)

Wed, 09 Sep 2026 18:10:26 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Added support for routing non-RFC 1918 local IPv4 networks through the WARP tunnel when unrestricted LAN inclusion is enabled by policy or MDM.
Improved DNS reliability on networks with lower MTUs by clamping the TCP maximum segment size (MSS) for DNS-over-HTTPS connections sent through the tunnel.
Improved API reliability by retrying requests dropped when reusing pooled connections.
The client no longer requires the Windows WLAN AutoConfig service to be running.
Implemented a service recovery mechanism backed by Windows scheduler task to start WARP service on system unlock if not already started.
Fixed slow captive portal checks causing the client service to become unresponsive or restart while connecting.
Fixed a race when switching tunnel protocols during key rotation that could prevent WireGuard from connecting.
Fixed the client continuing to report 'No network' after a successful manual disconnect.
Fixed Digital Experience Monitoring (DEX) HTTP tests failing TLS validation on Windows.
Fixed the client UI crashing at startup when it could not write to the Windows registry.
Fixed latency spikes and traffic interruptions during TPM-backed API authentication when hardware-backed registration is enabled.
Fixed trailing whitespace in BIOS serial numbers causing serial-number and client-certificate device posture checks to fail.
Fixed a client UI crash that could occur when the daemon connection was reset during an IPC request.
Fixed a startup crash when date formatting data for the system locale had not yet loaded.

Known issues

None

Browser Isolation, Cloudflare One - Improved iOS tap-to-type experience for Browser Isolation

Wed, 09 Sep 2026 00:00:00 GMT

Browser Isolation has improved the tap-to-type experience for users on iOS devices.

Previously, Browser Isolation displayed a full-screen overlay with the message tap to type when users focused a text field. The prompt now appears inline over the focused text field, reducing disruption when users enter text in isolated sessions.

If the focused text field is too small to display the full prompt, Browser Isolation displays a keyboard icon in the center of the text field instead.

iOS users should tap twice to begin entering text. This update applies automatically to Browser Isolation sessions on iOS.

For more information on why this interaction is required, refer to iOS limitations.

CASB - New CASB integration for Zoom

Wed, 09 Sep 2026 00:00:00 GMT

Cloudflare CASB now integrates with Zoom. The integration connects through Cloudflare's pre-built OAuth application — no manual app setup in Zoom is required. After an initial scan, CASB continuously scans your Zoom account to surface new findings as your environment changes.

Zoom is widely used for meetings, webinars, and collaboration. Misconfigurations in account settings, meeting security controls, and recording access can expose organizations to data leakage, unauthorized access, and compliance risk. Cloudflare CASB ingests Zoom account data via API to surface security findings across these areas.

Key capabilities

Starting today, security teams can scan for security findings across the following assets:

Account settings — Detect weak password policies, unlocked security controls, and two-factor authentication gaps across your Zoom account
User accounts — Identify users not enforcing SSO, accounts with insecure host keys, unverified or inactive users, and unsafe overrides of account-level security settings
Meetings — Surface meetings without passwords or waiting rooms, meetings using Personal Meeting IDs (PMIs), and meetings with external domain hosts
Recordings — Detect publicly accessible cloud recordings, recordings without passcodes, and weak recording password configurations
Content — Identify sensitive information in meeting and recording content via DLP Profile matching

Learn more

This integration is available to all Cloudflare Zero Trust customers today. New customers can sign up and start with their first two integrations for free. Existing customers can enable the integration directly in the Cloudflare One dashboard under Cloud & SaaS findings > Integrations. The integration begins scanning immediately and surfaces findings in the dashboard within minutes.

Workers - Miniflare v5 prepares local development for the cf CLI

Tue, 08 Sep 2026 00:00:00 GMT

Miniflare v5 prepares Cloudflare local development tooling for the upcoming cf CLI.

Miniflare powers local Workers development behind wrangler dev, the Cloudflare Vite plugin, and @cloudflare/vitest-plugin. Most projects should use those tools instead of depending on Miniflare directly, and Miniflare v5 will not require any action.

The most significant change is a new configuration shape which aligns Miniflare with cloudflare.config.ts, the programmatic Cloudflare configuration format now available for testing.

Other breaking changes include:

Removed deprecated APIs and options, such as legacy alpha D1 bindings.
Removed now-unused, internal APIs like wrappedBindings
Removed Miniflare's built-in module discovery; higher-level tools like Wrangler and the Vite plugin should be providing the module graph.
Moved local-only /cdn-cgi routes under /cdn-cgi/local.
Replaced per-resource persistence options with shared persistence root options.

For a more comprehensive list, refer to Miniflare's changelog ↗︎

This work sets up a cleaner foundation for the next generation of local development tooling, including the new cf CLI.

Workers - Python 3.14 for Python Workers

Tue, 08 Sep 2026 00:00:00 GMT

Python workers now use Python 3.14 by default.

This change applies to all new Python workers using compatibility date 2026-09-08 or later.

Internally, this change updates the Pyodide runtime to 314.0.6.

Cloudflare Fundamentals, Workers - Enterprise customers can self-serve CDN upload limits up to 5 GB

Fri, 04 Sep 2026 00:00:00 GMT

Enterprise customers can now configure a zone's CDN Maximum Upload Size up to 5 GB directly from the Network page in the Cloudflare dashboard. This removes the need to contact your account team or Cloudflare Support when applications need to accept request bodies larger than 500 MB and no greater than 5 GB.

The default maximum upload size remains 500 MB. Upload limits above 5 GB still require additional configuration through your account team or Cloudflare Support.

Very large uploads may reach connection or read timeouts before reaching the configured size limit. Make sure clients and origins allow enough time to complete the transfer when increasing this setting.

Refer to Cache upload limits and Workers request body size limits for details.

Workers - Deploy larger Workers — up to 64 MiB for both free and paid plans

Fri, 04 Sep 2026 00:00:00 GMT

You can now deploy Workers with larger dependencies, heavier frameworks, and more code without hitting size limits.

When you deploy a Worker, Wrangler bundles your code and compresses it before uploading. Previously, Cloudflare checked that compressed size and rejected deploys over 3 MB (Free) or 10 MB (Paid). That limit has been removed. Cloudflare now only checks the uncompressed size of your bundle, which is 64 MiB across all plans.

To check your Worker's bundle size before deploying:

wrangler deploy --outdir bundled/ --dry-run

Total Upload: 259.61 KiB / gzip: 47.23 KiB

The Total Upload value is your uncompressed bundle size. This is what counts against the 64 MiB limit. The gzip value is shown for reference but is no longer a limit.

For more information, refer to the Worker size limits documentation.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Define custom applications for breakout and prioritized traffic from the Cloudflare One Appliance dashboard

Wed, 02 Sep 2026 00:00:00 GMT

You can now define custom applications for breakout and prioritized traffic on the Cloudflare One Appliance directly from the dashboard, without calling the API.

In Traffic Steering > Breakout traffic or Prioritized traffic, select Assign application traffic > Add to create a custom application matched by Hostnames, IP subnets, and/or the new Source subnets field, alongside Cloudflare-managed applications.
Edit or delete an existing custom application from the same panel, no API round-trip required.
Source subnets lets you match traffic by its source IP range, complementing the existing source LAN interface breakout criteria.

This complements the existing API and Terraform workflow for managing applications.

For details, refer to Breakout traffic and Prioritized traffic.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Configure DHCP options from the dashboard on Cloudflare One Appliance

Wed, 02 Sep 2026 00:00:00 GMT

You can now configure custom DHCP options directly from the dashboard when the Cloudflare One Appliance is acting as the DHCP server for a LAN.

In LAN configuration, under DHCP server options, select Add DHCP option to choose from common options for PXE / iPXE boot, VoIP phone provisioning, and vendor-specific configuration, or select Add custom option to enter your own option code, type, and value.
This complements the existing API and Terraform workflow for configuring DHCP options.

For details, refer to DHCP server options.

Cloudflare Images - New in Images: text rasterization and updates to the binding

Wed, 02 Sep 2026 00:00:00 GMT

We've added more ways to manage and manipulate images with the Images binding. Here's what's new:

Render text into an image. Output a string of text into its own image or draw it over another image.

Use the .text() method to rasterize text with the Images binding.
Style content using the font, size, and color options.
The draw array in cf.image now accepts a text key.

Manage hosted images without an API token.

Metadata filtering: Pass filter.metadata to .list() to return images by custom metadata. Match a bounded range by setting two operators in one condition, for example, priority: { gte: 2, lte: 5 }.
Server-side signing: Get a signed URL for a private image with .signedUrl().
User uploads: Create a Direct Creator Upload link with .createDirectUpload() so that a client can upload an image to your storage.

Set headers in a single call.

Pass a headers option to .response() to set headers without rebuilding the Response.
Content-Type is always taken from the optimized image and can't be overridden by a specified header.
Set Cache-Control with Workers Cache to cache your optimized image at the edge.

For more information, refer to Optimize with Workers, Draw overlays and watermarks, and Manage hosted images with Workers.

Cloudflare Tunnel, Cloudflare One, Cloudflare WAN, Cloudflare Mesh - Create multiple Cloudflare Tunnel and Cloudflare Mesh routes at once

Wed, 02 Sep 2026 00:00:00 GMT

You can now create multiple Cloudflare Tunnel and Cloudflare Mesh routes from the Routes page in a single action, instead of submitting one route at a time.

When creating a route, you can now:

Add multiple destinations at once — Enter a comma-separated list of CIDR ranges or hostnames to create several routes of the same type and connector together.
Queue up multiple routes — Select Add another to stage additional routes, including different types or connectors, before creating them all in one action.
Retry only what failed — If some routes in a batch fail (for example, an invalid CIDR), the routes that were created successfully are removed from the form automatically, so you only need to fix and resubmit the ones that failed.

The same Routes UI already supports bulk creation for Cloudflare WAN static routes, so you can add multiple WAN destinations or queue up several WAN routes before creating them together as well.

Go to Routes ↗

For setup steps, refer to Add routes.

Workers - Python Workers now support WSGI web frameworks like Django and Flask

Wed, 02 Sep 2026 00:00:00 GMT

Python web frameworks following the Web Server Gateway Interface (WSGI) ↗︎ or Asynchronous Server Gateway Interface (ASGI) ↗︎ specification can now be used in Python Workers.

Using web frameworks with Python Workers

Based on the web framework you are using, you can use either wsgi or asgi from the workers module.

WSGI frameworks

For WSGI frameworks like Django or Flask:

from workers import wsgi

from django.core.wsgi import get_wsgi_application

app = get_wsgi_application()
Default = wsgi.entrypoint(app)

The wsgi.entrypoint is equivalent to creating a WorkerEntrypoint class and using the wsgi.fetch method. If you want more control over the WorkerEntrypoint class, you can do so:

from workers import wsgi, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return await wsgi.fetch(app, request, self.env)

ASGI frameworks

For ASGI frameworks like FastAPI or Starlette:

from workers import asgi

from fastapi import FastAPI

app = FastAPI()
Default = asgi.entrypoint(app)

For more information about using individual web frameworks, refer to the packages documentation in Python Workers.

Load Balancing - Load Balancing now supports pool sets

Mon, 31 Aug 2026 00:00:00 GMT

Cloudflare Load Balancing now supports pool sets through the API. Pool sets combine geographic matching with location-specific traffic steering. One load balancer can now use different routing behavior for different locations.

Each pool set can match a Cloudflare data center, country, or region. It then supplies the candidate pools and can apply its own steering policy, pool weights, and fallback pool. Cloudflare evaluates pool sets in array order and applies the first matching pool set.

For example, this pool set uses Dynamic Latency steering for traffic from Germany:

{
	"pool_sets": [
		{
			"name": "germany-lowest-latency",
			"match": { "topology": { "countries": ["DE"] } },
			"overrides": {
				"pools": [
					"0930eec54a4c7ae6616985b79f678210",
					"c8b4f5a6d7e84910a2b3c4d5e6f70819"
				],
				"steering_policy": "dynamic_latency"
			}
		}
	]
}

Use pool sets for active-active traffic distribution, location-specific failover, and regional routing policies. For proxied traffic, a pool set can also return a fixed HTTP response instead of selecting a pool.

For configuration details and more examples, refer to Pool sets.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.7.1376.0)

Fri, 28 Aug 2026 15:42:20 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.7.1376.0)

Fri, 28 Aug 2026 15:41:51 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

Fixed a rare but critical issue where the client could fail to connect or switch organizations due to an invalid registration after switching installed client versions. Additionally, this hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.7.1377.0)

Fri, 28 Aug 2026 15:27:27 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves an issue where a small but noticeable percentage of DNS queries fail across platforms.

Workers, Durable Objects - Durable Objects can use up to ten Dynamic Workers concurrently

Fri, 28 Aug 2026 00:00:00 GMT

Durable Objects can have up to ten distinct Dynamic Workers with in-flight requests, increased from four. This limit applies across all concurrent requests to the same Durable Object because they share an input/output (I/O) context. Other Workers can have up to four distinct Dynamic Workers with in-flight requests per request.

Multiple in-flight requests to the same Dynamic Worker count as one toward this limit.

For more information, refer to Dynamic Workers limits.

Access - Access service token secrets use a scannable format

Wed, 26 Aug 2026 00:00:00 GMT

Cloudflare Access service token Client Secrets created on or after August 26, 2026, use the format cfast_[40 alphanumeric characters][8-character checksum]. The prefix and checksum make these credentials easier for secret scanning tools to identify with fewer false positives.

Existing service token secrets continue to work and do not require rotation. Both formats use the same Client ID and the same CF-Access-Client-Id and CF-Access-Client-Secret authentication headers.

For more information, refer to Service tokens.

Access - Grace periods for service token rotation

Tue, 25 Aug 2026 00:00:00 GMT

Cloudflare Access administrators can now choose a grace period when rotating a service token secret. Both secrets remain valid during the grace period, giving administrators time to update services without interrupting authentication.

The dashboard offers grace periods from one hour to 30 days. Administrators can also revoke the previous secret immediately. The API accepts an RFC 3339 expiration time for custom rotation schedules.

For configuration instructions, refer to Rotate service token secrets.

Access - Temporarily turn off Access service tokens

Tue, 25 Aug 2026 00:00:00 GMT

Cloudflare Access administrators can now temporarily turn off service tokens without deleting them. A disabled token cannot authenticate, but its configuration remains available so administrators can turn it on again later.

Turning off a token also stops any previous secret in an active rotation grace period. Use this control to contain suspected credential exposure or pause an automated service.

For configuration instructions, refer to Turn a service token on or off.

Cloudflare One, Access - MCP server portals support MCP 2026-07-28 specification

Tue, 25 Aug 2026 00:00:00 GMT

MCP server portals support the stateless MCP 2026-07-28 specification for client and upstream server connections.

The portal's /mcp endpoint automatically accepts stateless MCP 2026-07-28 requests and earlier 2025 Streamable HTTP clients. When the portal connects to an upstream Streamable HTTP server, it checks for MCP 2026-07-28 support and falls back to the 2025 handshake when needed. Client and upstream protocol selection are independent, so clients and servers can upgrade separately without portal configuration changes.

SSE connections continue to use the legacy protocol. For details, refer to MCP server portal transport and protocol compatibility.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Download the Cloudflare One Virtual Appliance for your hypervisor from the dashboard

Mon, 24 Aug 2026 00:00:00 GMT

When you register a Cloudflare One Virtual Appliance, you can now select your hypervisor and download the appliance directly from the dashboard — no need to look up asset URLs.

On the Connectors page, select Add an appliance, choose Virtual appliance, then select your hypervisor: VMware ESXi, Proxmox, or libvirt/KVM.
Download the OVA image (VMware ESXi) or the install script (Proxmox and libvirt/KVM) for the selected hypervisor.
Use View setup guide to open deployment instructions for your platform.

This complements the existing self-serve registration and license key generation in the dashboard.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Workers - Preserve exception details in console logs

Mon, 24 Aug 2026 00:00:00 GMT

Console methods now preserve exception details in your Worker's logs. When your Worker logs an exception, the corresponding log entry includes the exception name, message, and stack.

For example, your Worker can catch and log an exception:

try {
	throw new Error("Deliberately created exception");
} catch (error) {
	console.error("caught exception:", error);
}

try {
	throw new Error("Deliberately created exception");
} catch (error) {
	console.error("caught exception:", error);
}

If you use Workers Observability, your log is automatically enriched with structured error information. The following example shows how the enriched log appears in the Cloudflare dashboard:

The exception's stack trace appears directly in the log message.

If you send telemetry to a Tail Worker, the Tail Worker now receives a log entry with an errorInfo array:

{
	"message": ["Request failed:", "RangeError: Value out of range"],
	"errorInfo": [
		null,
		{
			"name": "RangeError",
			"message": "Value out of range",
			"stack": "RangeError: Value out of range\n    at ..."
		}
	],
	"level": "error",
	"timestamp": 1784851200000
}

Each errorInfo item corresponds to the console argument at the same index in message. Arguments that are not exceptions have a null entry.

CASB - Automatically remediate Microsoft 365 and Google Workspace findings with API-based CASB remediation policies

Fri, 21 Aug 2026 00:00:00 GMT

Cloudflare CASB is an API-based (agentless) tool that continuously scans your SaaS and cloud applications for security misconfigurations and data exposure. You can now use CASB remediation policies to automatically fix a finding or send a webhook the moment CASB detects it, without manual triage.

Remediate Microsoft 365 and Google Workspace findings

A policy can perform a first-party remediation action directly against the SaaS integration API. When a policy triggers, Cloudflare revokes the external sharing configuration without human intervention.

Remediation is currently supported for file-sharing findings in Microsoft 365 and Google Workspace. Support for additional finding types and integrations is coming soon. For the full list of supported finding types, refer to Run remediations in the CASB remediation policies documentation.

Send webhooks

A policy can send posture finding data to Slack, ServiceNow, or any other webhook destination. Webhook actions are supported for all posture finding types across CASB integrations.

A single policy can perform both actions: remediate a finding and send a webhook.

Get started

In Cloudflare One ↗︎, go to Cloud & SaaS findings > Policies.
Select Create a policy.
Under Basic information, enter a Policy name and, optionally, a Description.
Under Choose how you want to trigger the policy, select a Vendor, Integration, and Finding type.
Under Define what to do with findings that match your trigger, choose Run Remediation, Send webhooks, or both.
Under Status, turn on Enable policy.
Select Create policy.

Learn more

Learn how to create and manage CASB remediation policies in Cloudflare One.
Configure CASB webhooks as a policy destination.
Learn how to manage findings in Cloudflare One.

CASB remediation policies are now available in Cloudflare One.

Data Loss Prevention - Test Data Loss Prevention profiles without sending traffic through Gateway

Fri, 21 Aug 2026 00:00:00 GMT

Test scan lets you check how Data Loss Prevention (DLP) evaluates sample content before you apply a profile to production traffic. Paste text, upload a file, or upload a HAR file, then select the profiles you want to test.

Test scan sends content directly to the DLP scanner. Gateway policies are not evaluated, no traffic passes through Gateway, and no Gateway activity logs are created. Results include matched profiles, detection entries, confidence levels, match context, proximity keywords, file metadata, antivirus status, and OCR output.

Test scan is available to all Cloudflare Zero Trust customers. Profile availability depends on your Zero Trust plan.

For more details, refer to the Test scan documentation.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.7.1343.0)

Wed, 19 Aug 2026 15:58:18 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.
When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

Additional changes and improvements

Fixed a process leak in the Windows GUI that could exhaust system resources during IPC client-creation failures.
Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
Fixed an issue where Microsoft Defender would falsely flag the Cloudflare One Client installation as malicious when installing with Intune.
Made the Windows domain-joined posture check more reliable.
A DNS search domain parsing failure no longer prevents connection.
Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
Fixed missing certificate error display due to a race condition.
Fixed empty black window after transitioning from docked dual displays to undocked/internal display.

Known issues

If a user upgrades to version 2026.7.1343.0, downgrades to an earlier version, re-registers, and then upgrades back to 2026.7.1343.0, the client might fail to connect or switch organizations. To resolve this issue, run warp-cli registration delete or warp-cli registration delete-all.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.7.1343.0)

Wed, 19 Aug 2026 15:58:18 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.
When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

Additional changes and improvements

Fixed the client not allowing login to another organization when currently showing "Device not in organization."
A DNS search domain parsing failure no longer prevents connection.
Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
Fixed missing certificate error display due to a race condition.
Fixed crash when trying to connect to captive portal on Wi-Fi.
Fixed empty black window after transitioning from docked dual displays to undocked/internal display.

Known issues

None

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.7.1343.0)

Wed, 19 Aug 2026 06:14:35 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

When reauthentication is needed for any reason, the notifications are clearer and reduce the actions needed to get you back to work by redirecting to the browser for authentication instead of the app window when necessary.
When a network is blocking or otherwise not supportive of HTTP/3, the client will learn and adapt by switching the order of fallback for that network by starting with HTTP/2 first and then trying HTTP/3 if needed. This reduces delays in time to connectivity when joining older or heavily filtered networks.

Additional changes and improvements

Fixed the client not allowing login to another organization when currently showing "Device not in organization."
A DNS search domain parsing failure no longer prevents connection.
Cloud icon now correctly reflects actual connection status instead of showing disconnected while fully connected.
Fixed missing certificate error display due to a race condition.
Fixed empty black window after transitioning from docked dual displays to undocked/internal display.
Fixed hostname routes not working for Cloudflare Mesh when the IP addresses of the hostnames are local addresses.

Known issues

When in DNS Only mode, the client may send DNS queries for names that are configured for Local Domain Fallback to the encrypted DNS server instead of falling back to the system configuration. Local Domain Fallback works as expected in other client modes.

Access, Cloudflare Fundamentals - Access resource lists now support resource-scoped roles

Wed, 19 Aug 2026 00:00:00 GMT

Members with only resource-scoped Access roles can now open Access resource list pages in the Cloudflare dashboard and call list endpoints in the API. They no longer need an additional account-scoped read-only role to list resources.

The dashboard and API return only resources included in the member's permission policy scopes. Filtering applies to Access applications, policies, service tokens, and identity providers. This allows administrators to delegate specific Access resources without granting account-wide visibility. Previously, the dashboard blocked these list pages and API list requests returned 403 responses.

For members with the Cloudflare Access App Admin role, policy lists include policies attached directly to the selected application. Reusable policies appear only when the member has the Cloudflare Access Policy Admin role for those policies.

For role definitions and assignment details, refer to Resource-scoped roles and Role scopes.

Cloudflare Network Firewall, Magic Transit, Cloudflare WAN - Threat Intel Lists supported in Unified Routing

Wed, 19 Aug 2026 00:00:00 GMT

Cloudflare Advanced Network Firewall Threat Intel Lists are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Rate Limiting and Managed Rulesets - is planned.

For the full list of current beta limitations, refer to Traffic steering beta limitations.

Workers - @cloudflare/vitest-pool-workers is now @cloudflare/vitest-plugin

Wed, 19 Aug 2026 00:00:00 GMT

Version 1 of the Workers Vitest integration is published as @cloudflare/vitest-plugin ↗︎. The package was formerly named @cloudflare/vitest-pool-workers.

The Vitest configuration API is unchanged. Existing projects must update the dependency name, package imports, and TypeScript types entries.

To migrate automatically, run:

npx @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

yarn @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

pnpm @cloudflare/codemods vitest:pool-workers-to-vitest-plugin

The codemod updates your dependency, imports, and test TypeScript configuration. For manual migration steps, refer to Migrate to Vitest plugin.

For outbound request mocks in Workers tests, use the @msw/cloudflare ↗︎ integration. Refer to Mock outbound requests.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Configure origin application settings for Cloudflare Tunnel in the dashboard

Tue, 18 Aug 2026 00:00:00 GMT

You can now configure origin application settings directly in the Cloudflare dashboard when adding or editing a published application route for a Cloudflare Tunnel. These settings control how cloudflared connects to your origin server and were previously only available in the Cloudflare One dashboard or via local configuration files.

When editing a published application, expand Additional application settings to configure parameters organized into three categories:

HTTP — Set a custom HTTP Host header or disable chunked encoding.
TLS — Configure origin server name, CA pool, TLS timeout, disable TLS verification, match SNI to host, or enable HTTP/2 to origin.
Connection — Tune connect timeout, keep-alive timeout, keep-alive connections, TCP keep-alive interval, proxy type, or disable Happy Eyeballs.

Go to Tunnels ↗

For the full list of origin parameters, refer to Origin parameters.

Email security - Post-quantum key exchange for MX deployments

Mon, 17 Aug 2026 09:00:00 GMT

Cloudflare Email Security now supports post-quantum hybrid key exchange with X25519MLKEM768 on the SMTP connections we make to receive and deliver mail. Deploying Email Security in front of a provider that supports post-quantum hybrid key agreement (like Google Workspace) will create a TLS 1.3 connection using post-quantum key agreement.

Inbound MX connections and outbound delivery connections now negotiate the X25519MLKEM768 hybrid key agreement when the peer supports it, protecting SMTP traffic against harvest-now, decrypt-later ↗︎ attacks.

Support is backwards compatible and enabled automatically for all customers. Senders and receivers that do not yet advertise post-quantum key agreement continue to connect with classical key exchange.

This applies to all Email Security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Load Balancing - Load balancing analytics now filters by pool name

Mon, 17 Aug 2026 00:00:00 GMT

Load balancing analytics now filters traffic data by pool name instead of pool ID, aligning the query behavior with the pool names displayed in the filter dropdown.

Previously, the analytics pool filter queried by internal pool ID while displaying pool names in the UI dropdown. This mismatch caused filtering issues when pools shared similar names or when you expected results based on the visible pool name. Because the underlying query used a different identifier than what appeared on screen, the displayed data could be confusing or incorrect.

The pool filter now queries by the same pool name shown in the dropdown. When you select a pool from the filter, the analytics graphs and tables display data for that specific pool as you would expect. This change affects:

Requests over time, filtering the chart series to the selected pool.
Pool distribution, showing only the selected pool segment.
Top endpoints, displaying cards for origins in the selected pool.
Latency, showing latency data for the selected pool.

The Logs view and health event filtering are unchanged.

To use this, go to Traffic > Load Balancing Analytics for a zone. The same pool filter appears in the analytics view for an individual load balancer under Load Balancing at the account level.

For more information about analytics filters and metrics, refer to Load Balancing Analytics.

Workers, Access - You can now enable Access on a Worker or all Workers at once

Fri, 14 Aug 2026 00:00:00 GMT

You now have two new ways to protect your Workers with Cloudflare Access.

Protect an application across all its domains at once

Until now, if a Worker was reachable on a route, a Custom Domain, and a workers.dev URL, you had to manually add each one to an Access application and keep the list in sync whenever routes or domains changed.

Now, Access attaches the policy to the Worker itself, so every associated domain and preview URL stays protected even when its routes or domains change.

Protect all new and existing Workers by default

Make all Workers private by default, so every existing and newly created Worker requires sign-in before anyone can reach it.

If a specific Worker should remain publicly accessible, add a Worker-level bypass to exempt it.

Whether you protect a single application or all Workers at once, you can choose whether to protect preview deployments only or both previews and production, and control who can sign in by Cloudflare account membership, email address, or email domain.

For more advanced policy options, edit the policy in Zero Trust ↗︎.

View all of your Worker Access policies

You can view and manage all of your Access policies in the Access tab of the Workers & Pages section in the dashboard.

See who is accessing your Worker

When Access is enabled on your Worker, every authenticated request includes ctx.access. Call ctx.access.getIdentity() to get the user's email, name, and groups — no manual JWT validation required.

export default {
  async fetch(request, env, ctx) {
    if (!ctx.access) {
      return new Response("Access did not run", { status: 401 });
    }

    const identity = await ctx.access.getIdentity();
    return Response.json({ aud: ctx.access.aud, email: identity?.email });
  },
};

Test Access locally

You can now test Cloudflare Access locally with wrangler dev. Add a dev block to your wrangler.jsonc:

{
  "access": {
    "dev": {
      "aud": "my-app",
      "identity": { "email": "admin@example.com" }
    }
  }
}

Your Worker will receive this identity through ctx.access and ctx.access.getIdentity(), letting you test authenticated and unauthenticated flows without deploying. Remove the dev block to simulate unauthenticated requests.

API and programmatic access

You can also set up these policies through the Workers API instead of the dashboard.

Gateway - Detect and control software package downloads with package registry security

Thu, 13 Aug 2026 00:00:00 GMT

Cloudflare Gateway can now detect software package downloads and give you policy control over supply chain traffic. When a developer or CI/CD pipeline downloads a package through Gateway, the proxy identifies the registry protocol from the request URL and extracts the package ecosystem, name, version, and namespace. You can then write HTTP policies using pkg.* selectors to allow or block package downloads.

Supported ecosystems

Gateway detects package downloads for the following ecosystems:

Ecosystem	Namespace
npm	Scope (for example, `@babel`)
PyPI	--
RubyGems	--
Cargo	--
Go	Module path
Maven	Group ID
NuGet	--

Selectors

In the dashboard, select Package Ecosystem to access the package registry selectors. After selecting a single ecosystem, nested fields for package name, version, and namespace become available. Five pkg.* selectors are available for HTTP policies with the Allow and Block actions:

Selector	Description
`pkg.ecosystem`	The package ecosystem detected from the request URL.
`pkg.name`	The package name extracted from the download URL.
`pkg.version`	The package version, with support for ecosystem-aware comparison operators.
`pkg.namespace`	The package namespace, when the ecosystem supports one.
`pkg.purl`	The Package URL (PURL) ↗︎ derived from the detected coordinates. Available in the API only.

Detection is based on the registry protocol rather than the hostname, so it works the same way whether traffic goes to a public registry, a corporate proxy such as Artifactory or Nexus, or a self-hosted mirror.

Package registry security requires TLS decryption to be turned on.

For more information, refer to Package registry security.

Email security - Block emails by content with blocked content rules

Wed, 12 Aug 2026 09:00:00 GMT

Cloudflare Email security now lets administrators write their own content-based blocking rules. A new Blocked content area under Policies & rules lets you define a plaintext string or a regular expression, choose whether to scan the message subject, body, or both, and automatically block any message that matches.

Create rules using either plaintext matches or regular expressions — useful for blocking targeted phishing campaigns, known-bad phrases, or content patterns unique to your organization.
Choose the search location for each rule: subject, body, or subject and body.
Use the built-in regular expression checker to validate your pattern against sample text before saving, so you can confirm the rule matches what you expect and avoid false positives.
Matching messages are marked with a malicious disposition and prevented from reaching users' inboxes.

Blocked content rules currently only support the block action.

This feature is available for the following Email security packages:

Enterprise
Enterprise + PhishGuard

To get started, refer to Blocked content.

Cloudflare One, Access - Independent MFA supports FIDO2 for infrastructure applications

Wed, 12 Aug 2026 00:00:00 GMT

Infrastructure applications support independent multi-factor authentication (MFA) with FIDO2 keys. You can allow ssh_fido2_key, piv_key, or both in application-level and policy-level MFA settings.

Users enroll FIDO2 keys through the App Launcher and connect with the generated SSH identity. FIDO2 keys for SSH are separate from browser-based WebAuthn security keys and Personal Identity Verification (PIV) keys.

For setup instructions, refer to Enroll a FIDO2 key for infrastructure apps and Configure MFA for infrastructure applications.

Gateway, Cloudflare One - MCP protocol detection and AI Security dashboard

Wed, 12 Aug 2026 00:00:00 GMT

Cloudflare Gateway now automatically detects Model Context Protocol (MCP) ↗︎ traffic flowing through your network. MCP is the standard protocol used by AI agents to connect to external tools and data sources. Gateway identifies MCP requests by inspecting protocol-specific headers and payload characteristics.

MCP policy selector

A new Is MCP selector (experimental.is_mcp) is available in HTTP policies. Use this selector to build Gateway rules that allow, block, or isolate MCP traffic.

This selector is currently in beta and may change before general availability.

For example, the following policy blocks MCP traffic that does not arrive through an approved MCP portal:

Selector	Operator	Value	Logic	Action
Is MCP	is	True	And	Block
Traffic Source	is not	MCP portal

AI security report

A new AI security report dashboard under Insights & Logs > Dashboards provides visibility into MCP usage across your organization. The dashboard includes:

Total MCP request volume, unique users, and unique MCP servers
A timeseries chart of unique MCP servers observed over time
A summary of Gateway policies that target MCP traffic

For more information, refer to HTTP policies.

Gateway, Cloudflare One - Traffic Source selector in Gateway policies

Wed, 12 Aug 2026 00:00:00 GMT

Gateway HTTP and Network policies now include a Traffic Source selector that identifies how traffic reaches Cloudflare. This allows administrators to write policies that target specific on-ramp methods - for example, applying different rules to traffic arriving via the Cloudflare One Client compared to traffic routed through an MCP portal or a proxy endpoint.

Available traffic source values

UI name	API value	Description
Device client	`device_client`	Traffic from the Cloudflare One Client (WARP)
Mesh	`mesh`	Traffic from a Cloudflare Mesh connector
Cloudflare WAN	`cloudflare_wan`	Traffic from Cloudflare WAN (Magic WAN)
Clientless RDP	`clientless_rdp`	Traffic from a clientless RDP session
Proxy endpoint	`proxy_endpoint`	Traffic from a proxy endpoint (PAC file)
Clientless Browser Isolation	`agentless_biso`	Traffic from clientless Browser Isolation
MCP portal	`mcp_portal`	Traffic from an MCP portal

The selector uses the net.onramp.type API field in both HTTP and Network policies.

UI name	API example
Traffic Source	`net.onramp.type == "device_client"`

Browser Isolation selector

A Browser Isolation selector is also available in Network and HTTP policies. This selector identifies whether the current session is running inside Remote Browser Isolation, allowing administrators to apply different policy behavior to isolated traffic.

UI name	API example
Browser Isolation	`net.is_isolated == true`

For more information, refer to HTTP policies and Network policies.

Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh, Gateway, Cloudflare One - Hostname routing is now generally available, with a new public IP range for initial resolved IPs

Tue, 11 Aug 2026 00:00:00 GMT

Hostname routing ↗︎ is now generally available. Instead of managing static IP lists and routes, you can route traffic by hostname across multiple Cloudflare One connectors:

Cloudflare Tunnel: route a private hostname (for example, wiki.internal.local) to a private application behind your tunnel, or a public hostname (for example, bank.example.com) to egress through a specific tunnel and anchor traffic to a dedicated exit node.
Cloudflare Mesh: attract a private or public hostname's traffic to a Mesh node.

Alongside GA, the default IPv4 range used for initial resolved IPs (also called token IPs) is changing from a Carrier-Grade NAT (CGNAT) range to a public Cloudflare-owned range:

IPv4: 172.64.128.0/20
IPv6: 2606:4700:0cf1:4000::/64

This is the default range. You can configure a custom initial resolved IP range for IPv4 if it conflicts with your existing network.

Why this is changing: Starting with Chrome 142 ↗︎, Local Network Access (LNA) restrictions block background requests to CGNAT addresses (100.64.0.0/10), which included the previous initial resolved IP default (100.80.0.0/16). LNA is implemented at the Chromium engine level, so it affects all Chromium-based browsers (for example, Microsoft Edge, Brave, and Opera), not only Google Chrome. This could silently break hostname-based Gateway features for users of these browsers, and required Chrome Enterprise policy workarounds. The new default range is public Cloudflare address space, so it is not affected by this restriction.

What is affected: Initial resolved IPs are used by several features that associate a DNS query with the network connection that follows it:

Private and public hostname routing for Cloudflare Tunnel
Hostname routes for Cloudflare Mesh
Access private applications on non-HTTPS ports
Egress policy host selectors (Domain, Host, Application, and Content Categories)

You can check your account's current range, or configure a custom range, at any time from Networking > IP addresses > Address space > Custom IPs, or using the Initial Resolved IP Subnet API.

Go to Custom IPs ↗

For full instructions, refer to Configure initial resolved IPs. The IPv6 range (2606:4700:0cf1:4000::/64) is unchanged and is not affected by this restriction.

The default IPv4 range, and all Cloudflare One IPv6 ranges, are automatically routed through the Cloudflare One Client and do not require any Split Tunnel configuration. Refer to Automatically managed ranges for details.

If you were relying on a Chrome Enterprise policy workaround (such as LocalNetworkAccessRestrictionsTemporaryOptOut) while your account was still on the legacy CGNAT-based range, refer to Google Chrome restricts access to private hostnames for next steps.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.6.905.0)

Mon, 10 Aug 2026 20:28:46 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This hotfix addresses an uncommon and intermittent case on Windows devices where the device is unable to reconnect after the device is woken from sleep.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Stream live logs from Cloudflare Tunnel in the dashboard

Mon, 10 Aug 2026 00:00:00 GMT

Real-time Tunnel log streaming is now available in the Cloudflare dashboard under Networking > Tunnels. This brings the same live debugging capability previously only available in the Cloudflare One dashboard, including multi-connector aggregated streaming for high-availability deployments.

In the tunnel detail view, a new Live logs tab lets you:

Stream logs from single or multiple connectors — In highly available deployments with multiple cloudflared replicas, logs from all connectors are merged into a single stream grouped by hostname, making it easy to identify which host machine produced each log entry.
Filter by log level, event type, and HTTP method — Narrow the stream to only the events you care about (HTTP, TCP, UDP, or cloudflared internal), at any log level.

Go to Tunnels ↗

For more information, refer to Tunnel observability and Tunnel log streams.

Load Balancing - Load Balancing health notifications now resolve automatically

Fri, 07 Aug 2026 00:00:00 GMT

Load Balancing health notifications are now stateful. When a pool or endpoint becomes unhealthy, the notification opens an incident in your alerting tool as before. When that same pool or endpoint recovers, the follow-up notification is matched to the original alert and resolves that incident automatically, so you no longer have to close it by hand.

As part of this change, Load Balancing also sends a notification when a pool or endpoint returns to a healthy state, not only when it becomes unhealthy. Expect to see recovery notifications alongside the failure notifications you already receive.

This applies to your existing Load Balancing health alerts with no configuration change, and it matches the behavior already used by Health Checks notifications.

Two things to keep in mind:

A recovery notification is matched to the earlier unhealthy notification for the same pool or endpoint. Renaming an endpoint while an incident is open prevents the match, so that incident stays open until you close it.
If a health change cannot be classified as either healthy or unhealthy, the notification is still delivered, but without the state needed to open or resolve an incident.

Refer to Integrate with PagerDuty to learn more about routing Load Balancing health notifications to an incident management tool.

Cloudflare Mesh, Cloudflare One - Container image for Cloudflare Mesh

Fri, 07 Aug 2026 00:00:00 GMT

Cloudflare Mesh nodes can now run as Docker containers. The cloudflare/mesh ↗︎ image is available on Docker Hub for Docker Compose, Kubernetes, and any OCI-compatible runtime — no host-level package installation required.

The image supports amd64 and arm64 architectures and includes built-in source NAT so return traffic routes correctly without VPC route table changes.

Deployment patterns

Docker Compose — add a cloudflare-mesh service to your compose.yaml and connect your entire stack to a private network.
Kubernetes StatefulSet — deploy a standalone Mesh node with persistent registration state.
Kubernetes sidecar — add the Mesh image as a sidecar container in a Pod to connect an application to Cloudflare without application changes.
CI/CD — pull the image in a pipeline step, join the Mesh, run integration tests against private infrastructure, and tear down. The node disappears when the container exits.

For high availability, run multiple replicas with the same Mesh node token. Cloudflare operates replicas in active-passive mode with automatic failover.

Go to Mesh ↗

For setup steps, runtime configuration, and deployment examples, refer to Run Mesh in Docker / Kubernetes.

Workers - AI agents can debug Workers with local tracing

Tue, 04 Aug 2026 00:00:00 GMT

wrangler dev and vite dev automatically capture structured OpenTelemetry traces and correlated console logs during local Worker invocations.

Debug with AI agents

When the tooling detects an AI agent session, it prints a terminal hint pointing to the Local Explorer API at /cdn-cgi/local/explorer/api. The API serves an OpenAPI schema and exposes a read-only observability query endpoint for discovering telemetry, querying traces and logs, and inspecting binding state.

The agent can identify the exact failing operation, fix the code, rerun the request, and verify the result. This debug loop requires no deployment or temporary logs.

Inspect traces in Local Explorer

Humans can inspect the same traces and correlated console logs in the Local Explorer browser UI. Each trace shows spans, timing, attributes, and errors.

Automatic spans cover handler calls, outbound fetch() calls, and binding calls. Custom spans appear alongside these automatic spans.

For more details, refer to the Local Explorer documentation.

Workers - Node.js compatibility is now enabled by default

Tue, 04 Aug 2026 00:00:00 GMT

Workers now enable the nodejs_compat and nodejs_compat_v2 compatibility flags by default for compatibility dates of 2026-08-04 or later. These flags are not used for these compatibility dates because the compatibility date enables the same behavior.

This means all Node.js built-in APIs supported by the Workers runtime are available by default, including node:crypto, node:buffer, node:stream, node:net, node:dns, node:fs, node:http, and more. npm packages that depend on these APIs will work without additional configuration.

Workers using an earlier compatibility date are not affected. They can still opt in by adding nodejs_compat to compatibility_flags.

New projects do not need to add either flag. Existing projects can update their compatibility date without removing them. Wrangler, Miniflare, the Cloudflare Vite plugin, and Vitest Pool Workers ignore these redundant flags when starting the runtime.

To turn off Node.js compatibility completely, remove any nodejs_compat and nodejs_compat_v2 flags. Then add both of the following flags:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  // Set this to today's date
  "compatibility_date": "2026-10-11",
  "compatibility_flags": [
    "no_nodejs_compat",
    "no_nodejs_compat_v2"
  ]
}

# Set this to today's date
compatibility_date = "2026-10-11"
compatibility_flags = ["no_nodejs_compat", "no_nodejs_compat_v2"]

For more information, refer to the Node.js compatibility documentation.

Workers - Log in to Wrangler without a local callback server

Tue, 04 Aug 2026 00:00:00 GMT

wrangler login now supports the OAuth 2.0 Device Authorization Grant ↗︎. Pass --device to authenticate without starting a temporary callback server on localhost:8976:

npx wrangler login --device

Wrangler prints a verification URL and a short user code, opens the URL in your default browser with the code already filled in, and polls Cloudflare for an access token while you approve the request:

 ⛅️ wrangler 4.119.0
────────────────────
Attempting to login via OAuth Device Authorization Grant...
To authorize Wrangler, please visit:

  https://dash.cloudflare.com/oauth2/device

and enter the code:

  jPqK6Qvs

You have 5 minutes to approve this request.

Opening a link in your default browser: https://dash.cloudflare.com/oauth2/device?user_code=jPqK6Qvs
Successfully logged in.

The default login flow needs your browser to reach localhost:8976, which is not always possible from containers, remote SSH sessions, or GitHub Codespaces. Previously these environments required forwarding ports or fetching the callback URL with curl from a second terminal session. Because --device has no callback server, those workarounds are no longer necessary.

Since the plain verification URL and user code are both printed to the terminal, you can also approve the request from a phone or another machine. Pass --browser=false to stop Wrangler from opening a browser at all.

Available in Wrangler version 4.119.0 or later. For more information, refer to wrangler login.

Access - Control authorization cookies for multi-domain Access applications

Mon, 03 Aug 2026 00:00:00 GMT

Cloudflare Access administrators can now control whether a self-hosted application preemptively sets authorization cookies across its public hostnames.

Previously, Access automatically used eager redirects for applications with five or fewer hostnames. Applications with more than five hostnames received cookies as users visited each hostname. Administrators can now choose either behavior, regardless of the number of hostnames.

The new Eager redirect cookie setting is turned on by default for new applications. After a user signs in, Access redirects the browser through each hostname and sets a CF_Authorization cookie. This supports applications that need to make requests across hostnames before the user visits each one.

For applications with many hostnames, the redirect chain can cause sign-in loops in some browsers. Turn off the setting to issue the cookie only when a user visits each hostname.

To configure the setting, refer to Authorization cookie.

Load Balancing - See fallback pool traffic separately in load balancing analytics

Mon, 03 Aug 2026 00:00:00 GMT

Load balancing analytics now shows traffic served by your fallback pool separately from traffic routed to the same pool by normal steering.

Previously, requests were grouped by pool name alone. If the pool acting as your fallback also received traffic through your steering policy, both appeared as a single series, so it was not obvious from the graph whether Cloudflare was still making health-based routing decisions or had fallen back to the pool of last resort. Because the fallback pool ignores health, that distinction matters when you are diagnosing an outage or reviewing how much traffic was shed.

Fallback traffic is now labeled with the pool name followed by (Fallback). A pool named eu-west, for example, is shown as eu-west (Fallback). This label appears as its own entry in:

Requests over time, as a separate series in the chart.
Pool distribution, as a separate segment.
Top endpoints, as a separate card for the pool.

The Latency view and the health event Logs are unchanged.

To see this, go to Traffic > Load Balancing Analytics for a zone. The same breakdown appears in the analytics view for an individual load balancer under Load Balancing at the account level.

Refer to load balancing analytics to learn more.

Workers - Python and JavaScript Workers can now call each other via RPC

Mon, 03 Aug 2026 00:00:00 GMT

You can now call methods between Python and JavaScript Workers using Workers RPC. This works through Service bindings without extra dependencies, schema definitions, or serialization code.

Cross-language RPC calls behave like ordinary function calls. Exceptions propagate to the call site. You can pass structured cloneable types ↗︎ as parameters or return values, and Pyodide Foreign Function Interface (FFI) automatically converts types between languages.

Call a TypeScript Worker from Python

Define a method in a TypeScript Worker:

index.jsjs

import { WorkerEntrypoint } from "cloudflare:workers";

export class RpcService extends WorkerEntrypoint {
	async add(a, b) {
		return a + b;
	}
}

index.tsts

import { WorkerEntrypoint } from "cloudflare:workers";

export class RpcService extends WorkerEntrypoint {
	async add(a: number, b: number): Promise<number> {
		return a + b;
	}
}

Call it from a Python Worker through a Service binding:

from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
	async def fetch(self, request):
		rpc = self.env.RPC
		result = await rpc.add(42, 144)
		return Response.json({"result": result})

Configure the Service binding in the Python Worker's Wrangler configuration:

{
	"services": [
		{
			"binding": "RPC",
			"service": "ts-rpc-server",
			"entrypoint": "RpcService"
		}
	]
}

[[services]]
binding = "RPC"
service = "ts-rpc-server"
entrypoint = "RpcService"

Call a Python Worker from JavaScript

Define a method in a Python Worker:

from workers import WorkerEntrypoint

class Default(WorkerEntrypoint):
	async def highlight_code(self, code: str, language: str) -> dict:
		from pygments.formatters import HtmlFormatter
		from pygments import highlight
		from pygments.lexers import get_lexer_by_name

		lexer = get_lexer_by_name(language, stripall=True)
		formatter = HtmlFormatter(linenos=True, cssclass="highlight", style="monokai")
		highlighted_html = highlight(code, lexer, formatter)
		css = formatter.get_style_defs(".highlight")

		return {
			"html": highlighted_html,
			"css": css
		}

Call it from a JavaScript Worker through a Service binding:

index.jsjs

export default {
	async fetch(request, env) {
		const rpc = env.PYTHON_RPC;
		const result = await rpc.highlight_code("print(42)", "python");
		return Response.json(result);
	},
};

index.tsts

export default {
	async fetch(request, env) {
		const rpc = env.PYTHON_RPC;
		const result = await rpc.highlight_code("print(42)", "python");
		return Response.json(result);
	},
};

Configure the Service binding in the JavaScript Worker's Wrangler configuration:

{
	"services": [
		{
			"binding": "PYTHON_RPC",
			"service": "py-rpc-server"
		}
	]
}

[[services]]
binding = "PYTHON_RPC"
service = "py-rpc-server"

For more details on the announcement, read the blog post ↗︎.

For more information, refer to the Workers RPC documentation and the Python Workers overview.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.7.1210.1)

Fri, 31 Jul 2026 13:55:39 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Improved connection reliability: the client now swaps protocol order after repeated connectivity-check failures, which helps when HTTP/3 is blocked after the QUIC handshake.
Fixed issue where a certificate error could be incorrectly displayed right after the connection is established.
A DNS search domain parsing failure no longer prevents connection.
Fixed a MASQUE issue where the tunnel could stall while uploading at a high rate.
Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
Fixed the Home Screen dropdown popup not anchoring correctly.
Fixed a crash during dialog dismissal.
Increased tolerance for configurations with a large number of local domain fallback resolver IPs, so DNS resolution behaves correctly even when more fallback resolvers are configured than recommended.
Fixed a networking issue where IPv6 multicast routes were being assigned to the WARP tunnel interface.
Fixed fatal errors on UI load on Windows 10.
Fixed a crash during Windows notification initialization.
Made the Windows domain-joined posture check more reliable.
Fixed orphaned credentials left behind on multi-user uninstall.
A successful re-authentication will cause the device profile to be re-evaluated.
Improved dashboard-managed client updates by running the updater only when needed.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.7.1210.1)

Fri, 31 Jul 2026 13:55:38 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release includes the following changes and improvements:

Improved connection reliability: the client now swaps protocol order after repeated connectivity-check failures, which helps when HTTP/3 is blocked after the QUIC handshake.
Fixed issue where a certificate error could be incorrectly displayed right after the connection is established.
A DNS search domain parsing failure no longer prevents connection.
Fixed a MASQUE issue where the tunnel could stall while uploading at a high rate.
Fixed being unable to switch organizations when the client was stuck in the "Device not in organization" state.
Fixed the Home Screen dropdown popup not anchoring correctly.
Fixed a crash during dialog dismissal.
Increased tolerance for configurations with a large number of local domain fallback resolver IPs, so DNS resolution behaves correctly even when more fallback resolvers are configured than recommended.
Fixed the WARP client stealing window focus (for example, during reauth).
Fixed a client crash when connecting to a captive portal over Wi-Fi.
Fixed the system tray icon showing "disconnected" while the UI showed "connected".
A successful re-authentication will cause the device profile to be re-evaluated.
Improved dashboard-managed client updates by running the updater only when needed.

Access - Static OAuth client credentials for MCP server portals

Fri, 31 Jul 2026 00:00:00 GMT

MCP server portals can now connect to upstream MCP servers that require a pre-registered OAuth client. This supports OAuth providers that do not offer Dynamic Client Registration or have disabled it. This unlocks portal connections to major SaaS providers such as Slack and GitHub, whose MCP servers do not yet support DCR.

When adding an MCP server, administrators can enter the client ID and client secret from an OAuth application registered with the upstream provider. The configuration also supports custom OAuth endpoints, scopes, and the client_secret_post and client_secret_basic token endpoint authentication methods.

Cloudflare stores the client secret encrypted. Users still authenticate to the upstream server with their own accounts when they connect through a portal.

For setup instructions, refer to Configure manual OAuth credentials.

Stream - Rotate Stream broadcast keys for live inputs

Fri, 31 Jul 2026 00:00:00 GMT

You can now rotate the broadcast credentials for a Stream live input without changing the live input identifier.

Use key rotation when live input credentials may have been shared with the wrong audience, exposed in client code or a screenshare, or need to be refreshed as part of your security process. Rotating keys revokes the old credentials, disconnects broadcasts using stale credentials, and returns refreshed credentials in the API response.

To rotate keys for a live input, make a POST request to the rotate_keys endpoint:

curl --request POST \
https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/live_inputs/{live_input_identifier}/rotate_keys \
--header "Authorization: Bearer <API_TOKEN>"

Live input responses now also include keysRotatedAt, which indicates when the live input keys were last rotated. This field is omitted for live inputs whose keys have never been rotated.

For endpoint details, refer to Rotate keys for a live input. For usage guidance, refer to Manage live inputs.

Workers, Durable Objects - Inspect Worker startup performance with Wrangler

Fri, 31 Jul 2026 00:00:00 GMT

wrangler check startup now reports your Worker's raw and compressed bundle sizes. It also summarizes local CPU activity during startup directly in your terminal.

Large bundles and costly startup work can introduce cold-start latency, so use this command to find code and large dependencies that slow your Worker before it handles requests.

The summary includes sampled, active, garbage collection, and idle time. Wrangler continues to save a .cpuprofile file for detailed flamegraph analysis in Chrome DevTools or VS Code.

⛅️ wrangler 4.116.0
───────────────────────────────────────────────
├ Building your Worker
│ Worker Built! 🎉
│
├ Analysing
│ Startup phase analysed
│
│ Bundle: 7171.25 KiB / gzip: 2197.00 KiB
│
│ Local startup profile:
│   Profile window: 70.3 ms
│   Sampled time: 70.3 ms
│   Active: 38.5 ms (including 3.7 ms garbage collection)
│   Idle: 31.8 ms
│   Samples: 36
│
│ CPU Profile has been written to worker-startup.cpuprofile. Load it into the Chrome DevTools profiler (or directly in VSCode) to view a flamegraph.
│
│ Note that the CPU Profile was measured on your Worker running locally on your machine, which has a different CPU than when your Worker runs on Cloudflare.
│
│ As such, CPU Profile can be used to understand where time is spent at startup, but the overall startup time in the profile should not be expected to exactly match what your Worker's startup time will be when deploying to Cloudflare.

The profile runs locally, so its duration will differ from startup time on Cloudflare. For authoritative startup time, deploy your Worker or upload a version.

Available in Wrangler version 4.116.0 or later. For more information, refer to wrangler check startup.

Access - Admins can turn on Code Mode by default for MCP portal users

Thu, 30 Jul 2026 00:00:00 GMT

MCP server portals now support four Code Mode policies: Off, Opt-in, On by default, and Enforced. Admins can choose whether Code Mode is unavailable, optional, enabled by default, or required for every session.

Existing portals retain their current behavior. Portals that previously allowed Code Mode use Opt-in, while portals that did not allow Code Mode use Off. New portals also use Opt-in by default.

Clients turn on Code Mode for an Opt-in portal with ?codemode=search_and_execute. The On by default policy lets clients opt out with ?codemode=off, which avoids nested code execution when a client runs its own Code Mode implementation. The Off and Enforced policies ignore client overrides.

The Cloudflare API exposes these policies through the code_mode field:

{
	"code_mode": "default_on"
}

The supported values are off, opt_in, default_on, and enforced. The previous allow_code_mode boolean is deprecated.

For configuration details and client behavior, refer to Code Mode policies.

Workers - Node.js 24 is now the default for Workers Builds

Thu, 30 Jul 2026 00:00:00 GMT

Workers Builds now uses Node.js 24.18.0 by default. The build image preinstalls Node.js 22.23.2 and 24.18.0.

You can continue to override the default with the NODE_VERSION environment variable, an .nvmrc file, or a .node-version file. For more information, refer to Override default versions.

Cloudflare One, Gateway - Control Cloudflare Gateway DNS caching with a maximum TTL setting

Tue, 28 Jul 2026 00:00:00 GMT

You can now set a maximum time-to-live (TTL) for DNS responses returned by Gateway. When an upstream DNS record has a TTL that exceeds the configured maximum, Gateway caps it to your specified value. This ensures that DNS policy changes - such as blocking a newly identified malicious domain - take effect faster across all clients.

Traffic settings, showing a numeric input field that accepts values between 60 and 36,000 seconds" loading="lazy" decoding="async" width="2170" height="294">

The setting is available at two levels:

Account level - In Traffic Policies > Traffic Settings, under Proxy and inspection. This sets the default cap for all DNS locations.
Per-location - Each DNS location can inherit the account setting, disable the cap, or override it with a custom value.

Two new fields are also available in DNS logs: upstream_record_ttls (the original TTL from the upstream response) and applied_max_ttl (the cap Gateway applied). These appear in the DNS logs column picker and in Logpush datasets.

For more information, refer to Maximum DNS TTL.

Workers - Workers tracing — write custom spans with new startActiveSpan() and span.end() runtime APIs

Tue, 28 Jul 2026 00:00:00 GMT

The Workers runtime now provides built-in tracing.startActiveSpan() and span.end() APIs, allowing you to write custom spans for operations that last beyond a single callback — for example, instrumenting a stream pipeline where the span should stay open until the stream is fully consumed.

This augments the existing API for writing custom spans, tracing.enterSpan(), which automatically ends a span when its callback is returned. With startActiveSpan(), the span remains open after the callback returns, and you call span.end() when the work is complete:

src/index.jsjs

import { tracing } from "cloudflare:workers";

const encoder = new TextEncoder();

export default {
	fetch() {
		return tracing.startActiveSpan("stream-response", (span) => {
			let timer;

			const body = new ReadableStream({
				start(controller) {
					controller.enqueue(encoder.encode("Starting...\n"));

					timer = setTimeout(() => {
						controller.enqueue(encoder.encode("Complete.\n"));
						controller.close();

						span.setAttribute("stream.status", "complete");
						span.end();
					}, 1000);
				},

				cancel() {
					if (timer !== undefined) clearTimeout(timer);

					span.setAttribute("stream.status", "cancelled");
					span.end();
				},
			});

			return new Response(body, {
				headers: { "content-type": "text/plain" },
			});
		});
	},
};

src/index.tsts

import { tracing } from "cloudflare:workers";

const encoder = new TextEncoder();

export default {
	fetch(): Response {
		return tracing.startActiveSpan("stream-response", (span) => {
			let timer: ReturnType<typeof setTimeout> | undefined;

			const body = new ReadableStream<Uint8Array>({
				start(controller) {
					controller.enqueue(encoder.encode("Starting...\n"));

					timer = setTimeout(() => {
						controller.enqueue(encoder.encode("Complete.\n"));
						controller.close();

						span.setAttribute("stream.status", "complete");
						span.end();
					}, 1000);
				},

				cancel() {
					if (timer !== undefined) clearTimeout(timer);

					span.setAttribute("stream.status", "cancelled");
					span.end();
				},
			});

			return new Response(body, {
				headers: { "content-type": "text/plain" },
			});
		});
	},
};

For more details, refer to the custom spans documentation.

Workers - Run integration tests against your Worker's production build

Mon, 27 Jul 2026 00:00:00 GMT

Wrangler now provides createTestHarness(), an API for running integration tests against Workers built with Wrangler or the Cloudflare Vite plugin from any Node.js test runner.

The test harness starts a local Worker server with helpers for dispatching requests, resetting storage, and inspecting runtime logs.

This is useful for tests that need to:

Route requests across multiple Workers
Mock outbound fetch() requests with Node.js request mocking libraries such as MSW ↗︎
Run Playwright tests against a Worker

For example, this test starts two Workers and mocks an upstream API:

tests/vitest.test.jsjs

import { afterAll, afterEach, beforeAll, test } from "vitest";
import { http, HttpResponse } from "msw";
import { setupServer } from "msw/node";
import { createTestHarness } from "wrangler";

const network = setupServer();
const server = createTestHarness({
	workers: [
		/** Includes `"routes": ["example.com/*"]` */
		{ configPath: "./workers/web/wrangler.jsonc" },
		/** Includes `"routes": ["api.example.com/v1/*"]` */
		{ configPath: "./workers/api/wrangler.jsonc" },
	],
});

beforeAll(async () => {
	network.listen({ onUnhandledRequest: "error" });
	await server.listen();
});

afterEach(async () => {
	network.resetHandlers();
	await server.reset();
});

afterAll(async () => {
	network.close();
	await server.close();
});

test("routes requests to each Worker", async ({ expect }) => {
	// Mock the outbound fetch used to load user profiles.
	network.use(
		http.get("http://identity.example.com/profile/123", ({ params }) => {
			return HttpResponse.json({ id: 123, name: "Ada" });
		}),
	);

	const apiWorkerResponse = await server.fetch(
		"http://api.example.com/v1/users/123",
	);
	expect(await apiWorkerResponse.json()).toEqual({
		id: 123,
		name: "Ada",
	});

	const webWorkerResponse = await server.fetch("http://example.com/users/123");
	expect(await webWorkerResponse.text()).toBe("Profile: Ada");
});

tests/vitest.test.tsts

import { afterAll, afterEach, beforeAll, test } from "vitest";
import { http, HttpResponse } from "msw";
import { setupServer } from "msw/node";
import { createTestHarness } from "wrangler";

const network = setupServer();
const server = createTestHarness({
	workers: [
		/** Includes `"routes": ["example.com/*"]` */
		{ configPath: "./workers/web/wrangler.jsonc" },
		/** Includes `"routes": ["api.example.com/v1/*"]` */
		{ configPath: "./workers/api/wrangler.jsonc" },
	],
});

beforeAll(async () => {
	network.listen({ onUnhandledRequest: "error" });
	await server.listen();
});

afterEach(async () => {
	network.resetHandlers();
	await server.reset();
});

afterAll(async () => {
	network.close();
	await server.close();
});

test("routes requests to each Worker", async ({ expect }) => {
	// Mock the outbound fetch used to load user profiles.
	network.use(
		http.get("http://identity.example.com/profile/123", ({ params }) => {
			return HttpResponse.json({ id: 123, name: "Ada" });
		}),
	);

	const apiWorkerResponse = await server.fetch(
		"http://api.example.com/v1/users/123",
	);
	expect(await apiWorkerResponse.json()).toEqual({
		id: 123,
		name: "Ada",
	});

	const webWorkerResponse = await server.fetch("http://example.com/users/123");
	expect(await webWorkerResponse.text()).toBe("Profile: Ada");
});

Cloudflare now recommends createTestHarness() for integration tests instead of unstable_startWorker() or unstable_dev(). To start a development server programmatically, use the Vite createServer() ↗︎ API with the Cloudflare Vite plugin.

For more information about createTestHarness(), refer to the Integration test harness guide.

Workers, Durable Objects - Filter Durable Object logs and traces by instance ID

Fri, 24 Jul 2026 00:00:00 GMT

Workers Logs and OpenTelemetry spans for Durable Object requests include the Durable Object instance ID.

Use $workers.durableObjectId to filter logs for a specific instance. Root and child spans include the same ID in cloudflare.durable_object.id.

Use these fields to isolate a specific instance and correlate its logs and traces.

For more information, refer to Durable Objects metrics and analytics and Workers tracing spans and attributes.

Workers - Workers Builds now skips superseded queued builds

Fri, 24 Jul 2026 00:00:00 GMT

Workers Builds now automatically skips a queued build when a newer build for the same build trigger is also queued.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.6.880.0)

Tue, 21 Jul 2026 16:55:55 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This hotfix resolves a regression that caused a large increase in DNS-over-TCP queries to fallback and internal DNS servers. The client now sends fallback DNS queries over UDP first, falling back to TCP only when a response is truncated, instead of querying both protocols in parallel.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.6.880.0)

Tue, 21 Jul 2026 16:55:55 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.6.880.0)

Tue, 21 Jul 2026 16:50:41 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

Access - Browser-based login for plaintext HTTP private applications

Mon, 20 Jul 2026 00:00:00 GMT

Cloudflare Access now uses the standard browser-based login flow for private applications served over plaintext HTTP on port 80.

Previously, plaintext HTTP private apps fell back to the same session flow used for SSH, RDP, and other non-HTTP protocols: users got an Authentication required pop-up from the Cloudflare One Client, then had to select the notification to open a browser and log in. Now, users hitting an HTTP private app see the Access login page directly in the browser and receive a standard Access application token on success.

This brings the HTTP experience in line with HTTPS apps (with Gateway TLS decryption turned on). No configuration change is required. The Cloudflare One Client is still required to route traffic to the private network, but it no longer manages the Access session for HTTP apps.

Other non-HTTP protocols (SSH, RDP, arbitrary TCP/UDP) continue to use the Cloudflare One Client notification flow.

Billing, Workers - Budget alerts now on by default for Pay-as-you-go accounts

Mon, 20 Jul 2026 00:00:00 GMT

We are turning on budget alerts by default for eligible Pay-as-you-go accounts. If your account does not already have a budget alert, Cloudflare will create one for you with a $10 account-level threshold. Your default alert will enable at the turn of your next billing cycle, so it will not fire based on usage you have already incurred.

We are rolling this out in cohorts over the coming weeks, so eligible accounts may see their default alert appear at different times.

The default alert behaves exactly like an alert you would create yourself. When your cumulative usage-based spend this cycle reaches the threshold, you receive an email notification. The alert is informational only. It does not cap your usage or impact your account in any way.

Usage is processed once per day for the prior day's activity, so budget alerts fire the day after the threshold is reached rather than in real time.

Budget alerts only consider spend on usage-based products. Recurring subscription fees, such as the Workers Paid plan fee or other monthly plan charges, are not included in the threshold calculation.

You can change the threshold, add additional alerts, or remove the default alert entirely from Manage Account > Billing > Billable Usage, or from your Notifications settings. If you already configured your own budget alert, nothing changes.

Enterprise contract accounts are not in scope.

For more information, refer to the Budget alerts documentation.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Restart, reboot, or shut down a Cloudflare One Appliance from the dashboard

Fri, 17 Jul 2026 00:00:00 GMT

You can now restart, reboot, or shut down a Cloudflare One Appliance directly from the dashboard or via API.

Restart — Restart managed services. Purges temporary and (optionally) persistent state.
Reboot — Power cycle the appliance. Optionally, purge persistent state. Re-applies configuration starting from scratch.
Shutdown — Power off the appliance. Optionally, purge persistent state. The machine will be offline until manually powered on again.

In the dashboard, go to Networking > Connectors > Appliances, select an appliance, then Edit > Operations to send an operation. Via API, POST to the /accounts/{account_id}/magic/connectors/{connector_id}/interrupts endpoint.

For details, refer to Appliance operations.

Gateway - New header control options for Gateway HTTP policies

Fri, 17 Jul 2026 00:00:00 GMT

Cloudflare Gateway now supports advanced header control on Allow policies. Administrators can add, overwrite, or delete headers on matching requests using static values or dynamic variables.

Header operations

Gateway HTTP policies using the Allow action support three operations in rule_settings:

Operation	API field	Behavior
Add	`add_headers`	Appends a value to the header. Existing values are preserved.
Overwrite	`set_headers`	Replaces the header value. Creates the header if it does not exist.
Delete	`delete_headers`	Removes the header from the request.

Gateway applies operations in order: delete, then overwrite, then add.

Dynamic variables

Header values can include dynamic variables using the @{...} syntax. Gateway resolves variables at request time from identity, device, and network context.

Variable	Description
`@{identity.email}`	User email from the identity provider
`@{identity.name}`	User display name from the identity provider
`@{identity.id}`	Cloudflare identity UUID
`@{identity.groups}`	Identity provider group memberships
`@{identity.SAML}`	SAML attributes (if configured)
`@{identity.OIDC}`	OIDC claims (if configured)
`@{source.ip}`	Source IP of the connection
`@{destination.ip}`	Destination IP of the request
`@{device.id}`	Cloudflare One Client device UUID
`@{device.posture}`	Device posture check results (JSON string)

You can mix static text and dynamic variables in a single header value. For example, user-@{identity.email} resolves to user-jdoe@example.com.

For more information, refer to Custom headers.

Access, Cloudflare One - Bulk print PDFs for browser-based RDP

Thu, 16 Jul 2026 00:00:00 GMT

Users in browser-based RDP sessions can now print multiple PDF files as a single print job. Copy the files to your clipboard on the remote machine, then select Print all PDFs in the clipboard panel. The files are combined into one PDF and sent to your local printer.

Bulk print is available in Chromium-based browsers and Firefox. For more information, refer to Print PDFs for browser-based RDP.

Gateway, DNS - Internal DNS is now generally available

Wed, 15 Jul 2026 00:00:00 GMT

Internal DNS is now generally available. Internal DNS provides authoritative and recursive DNS for private networks on the same global network and control plane you already use for public DNS, Zero Trust, and application services.

Why it matters

Consolidate DNS operations. Public and private DNS run on one platform, with one API, one audit trail, and one place to set policy.
Simplify split-horizon DNS. Internal and external resolution are defined as separate views over shared zones, managed from a single control plane — so there is no drift to chase down.
Extend Zero Trust to DNS. Resolver policies decide which users and devices resolve against which view, enforced by the same Gateway that already governs the rest of your traffic.

Setting up Internal DNS takes three steps: create a zone, create a view, and define a resolver policy.

POST /zones
{
  "account": {
    "id": "<ACCOUNT_ID>"
  },
  "name": "corp.internal",
  "type": "internal"
}

Internal DNS is included with Cloudflare Gateway for Enterprise customers. To get started, refer to the Internal DNS documentation.

Workers - Platforms can now create Temporary Accounts via the Cloudflare API

Tue, 14 Jul 2026 00:00:00 GMT

Platforms can now create temporary preview accounts through the Cloudflare REST API. This lets your platform deploy a live Worker before the user signs in to Cloudflare.

With the Temporary Accounts API, coding agents, AI app builders, and other platforms can build a similar flow for generated Workers and supported resources.

Your platform can keep users in its onboarding flow while they generate, deploy, and test an application. Users do not need an existing Cloudflare account, and your platform does not need write access to one.

The API returns a claim URL that lets the user make the temporary account and its resources permanent.

Cloudflare Drop ↗︎ demonstrates this preview-and-claim pattern for static sites. Someone can upload a site, test and share it for one hour, then sign in or create an account only when they want to keep it.

This API expands the flow first introduced with wrangler deploy --temporary. Your backend now controls the provisioning and deployment experience directly:

Show Cloudflare's Terms of Service and Privacy Policy in your product, and require the user to accept them.
Request and solve a proof-of-work challenge.
Create a temporary preview account.
Deploy with the returned temporary account ID and API token.
Show the deployed Worker URL and claim URL to the user.

curl "https://api.cloudflare.com/client/v4/provisioning/previews/challenge" \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{}'

curl "https://api.cloudflare.com/client/v4/provisioning/previews" \
  -X POST \
  -H "Content-Type: application/json" \
  --data '{
    "termsOfService": "https://www.cloudflare.com/terms/",
    "privacyPolicy": "https://www.cloudflare.com/privacypolicy/",
    "acceptTermsOfService": "yes",
    "challengeToken": "<CHALLENGE_TOKEN>",
    "solution": {
      "checkpoints": "<BASE64_CHECKPOINTS>"
    }
  }'

For the complete API flow, proof-of-work requirements, supported products, and limits, refer to Claim deployments (temporary accounts). For the background and design goals behind this flow, refer to Temporary Cloudflare Accounts for AI agents ↗︎.

Data Loss Prevention - Source code detection improvements

Fri, 10 Jul 2026 00:00:00 GMT

Data Loss Prevention (DLP) source code detection now focuses on identifying whole source code file uploads and downloads. Previously, source code detection performed partial scans resulting in a higher rate of false positives. Since only whole source code files are evaluated, code embedded in other content — such as chat messages, documentation, or code samples — is no longer flagged as source code, removing a common source of false positives.

Source code detection requires a minimum of 500 characters to evaluate a file. Files below this threshold are not flagged to reduce noise. This threshold filters out small fragments that lack enough context for reliable classification.

Enable and set confidence levels to tune match sensitivity. A higher confidence level reduces false positives by requiring stronger signals that the content is truly source code. A lower confidence level catches more files at the cost of additional noise.

Source code detection applies to standalone source code files in Gateway HTTP policies. It does not detect source code embedded within other file types or payloads, such as .docx files or chat messages.

For more information, refer to Source Code predefined profiles.

Digital Experience Monitoring - Wi-Fi signal and network performance analytics for Cloudflare One Client devices

Thu, 09 Jul 2026 00:00:00 GMT

Digital Experience Monitoring (DEX) provides visibility into device, network, and application performance across your Cloudflare SASE deployment.

The Device Monitoring page now analyzes hardware and network data between a Cloudflare One Client device and Cloudflare's edge, so you can diagnose connectivity and performance issues. Previously, this data was only available in raw DEX Device State Event logs, which required you to build your own analytics to interpret it.

A summary at the top of the page shows the health of each category at a glance, using Good, Fair, and Poor labels:

Connection — connection status, Cloudflare One Client mode, and tunnel type over time
Wi-Fi signal strength — signal measured in dBm over time, with thresholds that flag a weak signal
Traffic performance — upstream and downstream performance, including network throughput on the active interface
Device health — hardware metrics such as CPU, memory, and disk

You can filter by category and adjust the time range to correlate a device's metrics with a user's reported issue.

These analytics are available to all Cloudflare One customers at no additional cost.

To learn more, refer to the DEX monitoring documentation.

Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh - Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026

Thu, 09 Jul 2026 00:00:00 GMT

On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the connections field. If you manage private network routes or read tunnel connection details through the API, cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.

Route endpoints

The CIDR-encoded route endpoints are deprecated in favor of the standard, route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes as warp_connector) — only the request shape changes.

Deprecated endpoints (removed October 5, 2026):

Create a tunnel route (CIDR Endpoint): POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
Update a tunnel route (CIDR Endpoint): PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
Delete a tunnel route (CIDR Endpoint): DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}

Replacement endpoints:

Create a tunnel route: POST /accounts/{account_id}/teamnet/routes
Update a tunnel route: PATCH /accounts/{account_id}/teamnet/routes/{route_id}
Delete a tunnel route: DELETE /accounts/{account_id}/teamnet/routes/{route_id}

What is changing

	Deprecated (CIDR-encoded path)	Replacement
Route identifier	URL-encoded CIDR in the path (`/network/{ip_network_encoded}`)	`route_id` in the path (`network` moves to the request body on create)
Create	`POST .../teamnet/routes/network/{ip_network_encoded}`	`POST .../teamnet/routes` with `network` and `tunnel_id` in the body
Update	`PATCH .../teamnet/routes/network/{ip_network_encoded}`	`PATCH .../teamnet/routes/{route_id}`
Delete	`DELETE .../teamnet/routes/network/{ip_network_encoded}`	`DELETE .../teamnet/routes/{route_id}`

Action required

Capture each route's route_id by calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint.
Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗︎.
If you manage routes with Terraform, make sure you are on a current version of the cloudflare_zero_trust_tunnel_cloudflared_route ↗︎ resource and the Cloudflare Terraform provider ↗︎.

# Before: create a route by URL-encoding the CIDR into the path
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: create a route with the network in the request body
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'

# After: update or delete a route using its route_id
curl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H 'Content-Type: application/json' \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
     -d '{"comment": "Updated comment for this route."}'

curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Cloudflare Tunnel and Cloudflare Mesh connections

Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.

This affects:

GET /accounts/{account_id}/cfd_tunnel — connections removed from each item in result
GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
GET /accounts/{account_id}/warp_connector — connections removed from each item in result
GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

Action required

Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Update any dashboards, monitoring scripts, or automation that parses connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

Why we are making these changes

Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.
A single way to identify a route. Consolidating on route_id removes the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed.
Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.

To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.

Workers - Send npm package dependency metadata with Worker uploads

Thu, 09 Jul 2026 00:00:00 GMT

Wrangler now collects npm package dependency information from your project's package.json during wrangler deploy and wrangler versions upload, and includes it in the upload metadata sent to the Cloudflare API. This data, each dependency's name, declared version range, and exact installed version, enables dependency analytics and future supply chain security features such as vulnerability alerting.

To opt out, set dependencies_instrumentation.enabled to false in your Wrangler configuration file:

{
	"dependencies_instrumentation": {
		"enabled": false
	}
}

[dependencies_instrumentation]
enabled = false

For more details, refer to Wrangler configuration.

Cloudflare One, Cloudflare WAN - IPsec downgrade protection (beta)

Wed, 08 Jul 2026 00:00:00 GMT

Cloudflare IPsec now supports the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗︎ IKEv2 extension to protect against downgrade attacks on IPsec tunnels.

IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗︎ can exploit this to bypass post-quantum key exchange by downgrading the connection to classical cryptography. The IKE_SA_INIT_FULL_TRANSCRIPT_AUTH extension addresses this by having both peers sign the entire handshake transcript during the authentication exchange, preventing an attacker from manipulating the negotiation without detection.

Key details:

Available in beta for Cloudflare WAN and Magic Transit IPsec tunnels.
Cloudflare sends the IKE_SA_INIT_FULL_TRANSCRIPT_AUTH notification unconditionally as a responder when the feature flag is enabled.
Both the initiator (your device) and responder (Cloudflare) must support the extension for downgrade protection to be effective.
This feature is currently gated by a per-account feature flag. Contact your account team to turn it on.

Refer to Downgrade protection for more details.

Cloudflare Network Firewall, Magic Transit, Cloudflare WAN - IP lists, IDS, and SIP rules supported in Unified Routing

Wed, 08 Jul 2026 00:00:00 GMT

Cloudflare Advanced Network Firewall IP lists, IDS, and SIP rules are now supported for accounts using Unified Routing mode. These features require a Cloudflare Advanced Network Firewall subscription.

Support for additional features - Threat Intel Lists, Rate Limiting, and Managed Rulesets - is planned.

For the full list of current beta limitations, refer to Traffic steering beta limitations.

Workers - Cloudflare Drop

Wed, 08 Jul 2026 00:00:00 GMT

Cloudflare Drop ↗︎ lets you deploy a static site to Cloudflare without requiring a Cloudflare account to get started.

Upload a folder or zip file of static assets (static HTML, CSS, JavaScript, images, and fonts) and get a temporary live preview that stays live for 1 hour. During that window, you can test the site, share the preview URL, or claim the deployment to keep it.

When you are ready to make the deployment permanent, click Claim to sign in or create a Cloudflare account. You can claim the site into an existing Cloudflare account or create a new account for the deployment.

After claiming the site, you can:

Add a domain: Connect an existing domain or purchase a new one for your site.
Enable observability: Monitor your site's performance and usage.
Enable Markdown for Agents: Allow AI agents to access your site's content in Markdown.
Control access: Make your site private and choose who can view it.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.6.850.0)

Tue, 07 Jul 2026 18:35:35 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This hotfix addresses a Windows authentication issue in the embedded WebView2 browser. Single sign-on could fail to use the Windows primary account, causing users to be prompted for an interactive sign-in. The embedded authentication browser now allows SSO providers to use the OS primary account when available.

Access, Cloudflare One - File transfer controls for browser-based RDP (beta)

Tue, 07 Jul 2026 00:00:00 GMT

You can now configure file transfer controls for browser-based RDP with Cloudflare Access, allowing you to restrict whether users can upload or download files between their local machine and the remote Windows server.

This feature is useful for organizations that support bring-your-own-device (BYOD) policies or third-party contractors using unmanaged devices. By restricting file transfers, you can prevent sensitive data from being moved out of the remote session to a user's personal device.

Configuration options

File transfer controls are configured per policy within your Access application, alongside existing text clipboard controls. For each policy, you can select one of the following options:

Client to remote RDP session allowed — Users can upload files from their local machine into the browser-based RDP session.
Remote RDP session to client allowed — Users can download files from the browser-based RDP session to their local machine.
Both directions allowed — Users can upload and download files between their local machine and the browser-based RDP session.
Disable copying/pasting — Users are not allowed to transfer files between their local machine and the browser-based RDP session.

By default, file transfer is denied for new policies. For existing Access applications created before this feature was available, file transfer remains denied.

How it works

To upload, drag files into the browser window or select the settings gear icon on the left side of the RDP session. To download, copy a file in the remote session and select the settings gear to download it, download multiple files as a zip, or print PDFs to a local printer.

This feature is in beta and available on all Zero Trust plans. For more information, refer to File transfer for browser-based RDP.

Browser Isolation, Cloudflare One - Browser Isolation support for authorization proxy endpoints

Tue, 07 Jul 2026 00:00:00 GMT

Browser Isolation now supports Gateway authorization proxy endpoints. You can apply HTTP Isolate policies to traffic routed through authorization proxy endpoints, the same way you can for traffic from the Cloudflare One Client.

Previously, only source IP proxy endpoints supported Browser Isolation, and only with non-identity policies. Because authorization proxy endpoints authenticate users through an identity provider, you can now apply identity-based Isolate policies to PAC file-proxied traffic without requiring the Cloudflare One Client.

To get started, create an authorization proxy endpoint and build an Isolate policy.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Self-serve registration of Cloudflare One Virtual Appliance in the dashboard

Mon, 06 Jul 2026 00:00:00 GMT

You can now register a Cloudflare One Virtual Appliance and generate its license key directly from the dashboard, without contacting your account team.

On the Connectors page, select Add an appliance and choose Virtual appliance to register a virtual appliance and generate its authentication key.
Use Regenerate authentication key from a virtual appliance connector's menu to rotate its key. The previous key is immediately and irrevocably revoked.
The authentication key is shown only once — copy and store it securely.

This complements the existing API and Terraform self-serve workflow for provisioning virtual appliances. Hardware appliances continue to use the existing account-team fulfillment workflow.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Workers - Simpler runtime types with @cloudflare/workers-types v5

Fri, 03 Jul 2026 00:00:00 GMT

We have released version 5 of @cloudflare/workers-types ↗︎. This release simplifies the package to expose only the latest runtime types.

We still recommend that you generate types for your Worker using wrangler types, but if you want to use the package directly, you can install it with your package manager of choice:

npm i -D @cloudflare/workers-types@latest

yarn add -D @cloudflare/workers-types@latest

pnpm add -D @cloudflare/workers-types@latest

bun add -d @cloudflare/workers-types@latest

The package now exposes two entrypoints:

@cloudflare/workers-types reflects the latest compatibility date, using the latest stable compatibility flags.
@cloudflare/workers-types/experimental reflects APIs behind experimental compatibility flags.

The dated entrypoints, such as @cloudflare/workers-types/2022-11-30 and @cloudflare/workers-types/2023-03-01, are removed. With runtime type generation in Wrangler v4, you can generate these with the wrangler types command to create types locked to your Worker's compatibility date.

For more information, refer to TypeScript language support.

Cloudflare Mesh, Cloudflare One - Hostname routing for Cloudflare Mesh

Thu, 02 Jul 2026 00:00:00 GMT

You can now add hostname routes to a Cloudflare Mesh node, in addition to CIDR routes.

Client device
Requests wiki.internal.local
DNS query
Cloudflare Gateway
Returns a token IP, then rewrites the destination to the real private IP.
172.64.128.0/20
Hostname route
Mesh node
Forwards traffic to the host on the local network
↓
Private host
wiki.internal.local · 10.0.0.50

Instead of managing IP ranges, you can attract traffic for a hostname to a Mesh node:

Private hostname (for example, wiki.internal.local) — reach an internal application by name, which is useful when it has an unknown or ephemeral IP. On Mesh you do not need to run a DNS server; a local hosts-file entry on the node is enough, or you can use a Gateway resolver policy for split DNS.
Public hostname (for example, www.example.com) — route that hostname's traffic through the node and egress via the node's public IP.

Go to Mesh ↗

For setup steps, prerequisites, and DNS options, refer to Hostname routes.

Workers - Work across multiple accounts with Wrangler auth profiles

Thu, 02 Jul 2026 00:00:00 GMT

Wrangler CLI now supports auth profiles: named logins that you scope to specific Cloudflare accounts and switch between automatically, based on the directory you are working in.

A profile is a named OAuth login bound to a directory. Commands run in that directory, and its subdirectories, use the matching account — so you can move between accounts without re-running wrangler login.

Use profiles to keep a separate login for each client when working at an agency, or to separate staging and production into different accounts. Pair a profile with an account_id in your Wrangler configuration file so a command cannot reach the wrong account.

# Create a profile for each account, choosing which accounts it can reach
wrangler auth create client-a
wrangler auth activate client-a ~/clients/client-a

wrangler auth create client-b
wrangler auth activate client-b ~/clients/client-b

Use the --profile flag to run a single command with a specific profile:

wrangler deploy --profile personal

In CI and other automated environments, CLOUDFLARE_API_TOKEN still takes precedence over all profiles.

For setup, the resolution order, and the full command reference, refer to Authentication profiles.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.6.836.0)

Wed, 01 Jul 2026 19:48:17 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This package is the same release as 2026.6.822.0, with a fix for our RPM package. Previously the repository served a single build to every OS version, so an install could pull a dependency that isn't available on that release. The repository now serves the correct build for each operating system version, so installs automatically pull the dependencies that version requires. Debian and Ubuntu were not affected.

If you installed version 2026.6.822.0 on an RPM-based distribution, we recommend refreshing your repository configuration:

sudo curl -fsSL https://pkg.cloudflareclient.com/cloudflare-warp-ascii.repo | sudo tee /etc/yum.repos.d/cloudflare-warp.repo
sudo dnf clean all
sudo dnf install cloudflare-warp

Access - Fix redirect URL fragment encoding for single-page applications

Wed, 01 Jul 2026 00:00:00 GMT

Access now correctly preserves URL fragment characters (/, ?, =, &, ;) when redirecting users back to an application after login. Previously, these characters were encoded with encodeURIComponent, which mangled fragment-based routes used by single-page applications (SPAs).

For example, an SPA URL like https://app.example.com/#/dashboard?tab=settings&view=advanced would previously redirect to a broken URL after login. This is now handled correctly.

If your SPA users were experiencing broken navigation after authenticating through Access, this fix resolves the issue without any configuration changes.

Access - Independent MFA for infrastructure applications

Wed, 01 Jul 2026 00:00:00 GMT

Access for Infrastructure now supports independent multi-factor authentication (MFA) for SSH connections using YubiKey PIV keys. This adds a hardware-backed second factor to SSH access, ensuring that a compromised device session alone is not sufficient to reach your servers.

With per-application and per-policy configuration, you can enforce PIV key authentication for sensitive usernames (for example, root) while applying different requirements for other usernames. You can also set an MFA session duration to control how often users must re-authenticate.

Enrollment

Users enroll their YubiKey PIV key through the App Launcher. For enrollment instructions and SSH client setup, refer to Enroll a PIV key for infrastructure apps.

Configuration

For setup instructions, refer to Enforce MFA for infrastructure applications.

Cloudflare Images - Images binding is now billed per unique transformation

Wed, 01 Jul 2026 00:00:00 GMT

The Images binding is now billed per unique transformation, matching the model already used for URL-based transformations. Repeat requests for the same combination of source image and parameters within the same calendar month are counted only once.

Previously, every call to the binding counted as a separate transformation regardless of whether the image or parameters were unique. With this change, you can call the binding on hot paths without paying for each individual request.

Calls to .info() are no longer billed.

For more information, refer to Images pricing and the Images binding documentation.

Gateway, Cloudflare One, Cloudflare Fundamentals - New permissions and roles for Gateway policies and lists

Tue, 30 Jun 2026 00:00:00 GMT

You can now assign granular, resource-scoped roles for Cloudflare Gateway firewall policies and Zero Trust lists. Administrators can delegate access to specific policy types or list management without granting account-wide or product-wide control.

What is new

When you add a member or create a permission policy, the following resource-scoped roles are now available:

Role	Description
Zero Trust Gateway Firewall Policies Admin	Can view and edit all Gateway firewall policies, including DNS, HTTP, and Network policies.
Zero Trust Gateway DNS Policies Admin	Can view and edit Gateway DNS policies.
Zero Trust Gateway HTTP Policies Admin	Can view and edit Gateway HTTP policies.
Zero Trust Gateway Network Policies Admin	Can view and edit Gateway Network policies.
Zero Trust Gateway Egress Policies Admin	Can view and edit Gateway Egress policies.
Zero Trust Gateway Resolver Policies Admin	Can view and edit Gateway Resolver policies.
Zero Trust Gateway Policies Admin	Can view and edit all Gateway policies.
Zero Trust Gateway Policies Read	Can view all Gateway policies.
Zero Trust Gateway Read Only	Can view all Gateway resources.
Zero Trust DNS Locations Admin	Can view and edit DNS locations.
Zero Trust Proxy Endpoints Admin	Can view and edit Gateway Proxy Endpoints.
Zero Trust Account Lists Admin	Can view and edit all Gateway and Access lists.
Zero Trust Account Lists Read	Can view all Gateway and Access lists.

These roles allow you to:

Grant a network engineer write access to Network policies only, without exposing DNS or HTTP policy configuration.
Allow a security analyst to view all Gateway policies in read-only mode for auditing purposes.
Delegate list management to a team that maintains block and allow lists without giving them access to policy configuration.

You can also now assign Resource-scoped roles. These roles are complementary to existing account-level roles, and allow you to grant access to a specific resource, like an individual Gateway policy or Cloudflare One list. Existing account-level roles continue to work. A member with the Cloudflare Gateway or Cloudflare Zero Trust role retains full access to all Gateway resources. This ensures backward compatibility for existing automation and API tokens.

Get started

Refer to Granular permissions for Gateway for setup instructions and supported resources.
Learn how to create permission policies that use these roles.

Workers, Durable Objects - Track memory usage for Workers and Durable Objects in the dashboard

Tue, 30 Jun 2026 00:00:00 GMT

You can now monitor how much memory your Workers and Durable Objects consume across invocations with the new Memory Usage chart in the Workers Metrics tab, broken down by P50, P90, P99, and P999 percentiles.

Memory usage measures the V8 isolate memory at the time of each invocation, subject to the 128 MB per-isolate limit — a single isolate can handle many concurrent requests and shares memory across them.

Use the Memory Usage chart to:

Track memory trends — Spot gradual increases that may indicate a memory leak before they cause Exceeded Memory errors.
Correlate with deployments — Deployment markers on the chart help you identify whether a new version introduced a memory regression.
Right-size your Worker — Understand your baseline memory footprint and how much headroom you have before hitting the 128 MB limit.

For Durable Objects, memory usage reflects the in-memory state an object holds (class properties, caches, active WebSocket connections), which persists across invocations until the object is hibernated or evicted. This state is not preserved across eviction, hibernation, or a crash, so persist anything important to storage.

To view memory usage, open the Metrics tab for your Worker ↗︎ or Durable Object namespace ↗︎. For Durable Objects, you can filter by DO ID or name to drill down into memory usage for a specific object. You can also query memory usage programmatically via the GraphQL Analytics API using the workersInvocationsAdaptive dataset — the quantiles.memoryUsageBytesP50 through quantiles.memoryUsageBytesP999 fields return percentile values in bytes.

For local memory debugging, you can also profile memory with DevTools to take heap snapshots and identify specific objects causing high memory usage.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.6.822.0)

Mon, 29 Jun 2026 20:05:45 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

The client now applies DNS search suffixes configured in your device profile / network policy. 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 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. See the announcement blog and documentation for details.
Upgraded security of device registration to be hardware-backed. Registration tokens can now be generated in the TPM (with TPM 2.0+) whenever it is available to provide stronger protection against device impersonation. See Hardware-backed registration 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 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 for details.
Added support for dashboard-managed client version deployments. Administrators can now upgrade or downgrade the client version on enrolled devices directly from the Zero Trust dashboard. See Client version assignments for details.

Additional Changes and improvements

Starting with 2026.6.822.0, the client unifies all API requests under the api.devices.cloudflare.com SNI, where previously both zero-trust-client.cloudflareclient.com and notifications.cloudflareclient.com were used. Review Cloudflare One Client with firewall to ensure systems that rely on SNI inspection do not block the API traffic. The behavior of previous client versions is unaffected.
Client Certificate device-posture checks now support template variables (e.g. ${serial_number}, ${device_uuid}) in the Subject Alternative Name field. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.
Improved accessibility by using high contrast colors and more defined color boundaries when high contrast is enabled in Windows Accessibility settings.
Path MTU Discovery (PMTUD) is now enabled by default.
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.
Fixed an issue where DNS queries would fail after the connection was idle, requiring users to retry.
Fixed a high CPU issue when the device wakes from sleep.
Users can now register with team names in any case format without errors.
New UI fixes
- Fixed an issue where users with invalid MDM configurations were returned to the onboarding screen after successful authentication.
- Added a re-auth button and banner to the home screen so users don't miss it when their session expires.
- Added clear error messaging when the Cloudflare certificate needs to be installed.
- Brought back support for pausing the tunnel when connected to user-specified Wi-Fi networks for consumer users.
- New client UI now surfaces Split tunnel configuration and Local Domain Fallback configuration.
- Added ability to configure proxy mode for consumer users.
- Added back the option to quit for consumer users.

Known issues

Single sign-on in the embedded WebView2 authentication browser may fail to use the Windows primary account, prompting for an interactive sign-in.
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.
In rare cases, a registration may hang at "Checking your organization configuration" due to IPC errors. A system reboot should resolve the error, allowing registration to proceed.
Windows ARM may prompt the user to close running applications while trying to install this version. Simply click "Ok" with the default highlighted option.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.6.822.0)

Mon, 29 Jun 2026 20:05:45 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

The client now applies DNS search suffixes configured in your device profile / network policy. 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 for details.
Upgraded security of device registration to be hardware-backed. Registration tokens can now be generated in the Secure Enclave whenever available to provide stronger protection against device impersonation. See Hardware-backed registration 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 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 for details.
Added support for dashboard-managed client version deployments. Administrators can now upgrade or downgrade the client version on enrolled devices directly from the Zero Trust dashboard. See Client version assignments for details.

Additional Changes and improvements

Starting with 2026.6.822.0, the client unifies all API requests under the api.devices.cloudflare.com SNI, where previously both zero-trust-client.cloudflareclient.com and notifications.cloudflareclient.com were used. Review Cloudflare One Client with firewall to ensure systems that rely on SNI inspection do not block the API traffic. The behavior of previous client versions is unaffected.
Client Certificate device-posture checks now support template variables (e.g. ${serial_number}, ${device_uuid}) in the Subject Alternative Name field. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.
Improved accessibility by using high contrast colors and more defined color boundaries when high contrast is enabled in the macOS Display settings.
Path MTU Discovery (PMTUD) is now enabled by default.
Fixed the in-client captive-portal browser rendering a blank "Success" page on some airline Wi-Fi networks. The browser now more consistently 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.
Fixed an issue where DNS queries would fail after the connection was idle, requiring users to retry.
Users can now register with team names in any case format without errors.
New UI fixes
- Fixed an issue where users with invalid MDM configurations were returned to the onboarding screen after successful authentication.
- Added a re-auth button and banner to the home screen so users don't miss it when their session expires.
- Added clear error messaging when the Cloudflare certificate needs to be installed.
- Brought back support for pausing the tunnel when connected to user-specified Wi-Fi networks for consumer users.
- New client UI now surfaces Split tunnel configuration and Local Domain Fallback configuration.
- Added ability to configure proxy mode for consumer users.
- Added back the option to quit for consumer users.

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.
When deploying with Microsoft Intune, the client may be repeatedly reinstalled because Intune adds the client's embedded framework bundles to its install-detection list, and those frameworks cannot be detected as installed on their own. See Repeated reinstalls on macOS with Microsoft Intune for the workaround.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.6.822.0)

Mon, 29 Jun 2026 19:21:09 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release introduces multiple features from our previous beta release into stable release, including:

The client now applies DNS search suffixes configured in your device profile / network policy. 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 for details.
Upgraded security of device registration to be hardware-backed. Registration tokens can now be generated in the TPM (with TPM 2.0+) whenever it is available to provide stronger protection against device impersonation. See Hardware-backed registration 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 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 for details.

Additional changes and improvements

Starting with 2026.6.822.0, the client unifies all API requests under the api.devices.cloudflare.com SNI, where previously both zero-trust-client.cloudflareclient.com and notifications.cloudflareclient.com were used. Review Cloudflare One Client with firewall to ensure systems that rely on SNI inspection do not block the API traffic. The behavior of previous client versions is unaffected.
Cloudflare Mesh functionality using the Cloudflare One Client is now supported on RHEL 9 and 10.
Cloudflare Mesh now supports hostname-based routing.
Client Certificate device-posture checks now support template variables (e.g. ${serial_number}, ${device_uuid}) in the Subject Alternative Name field. Previously only the Common Name field accepted variables, which broke posture rules that pinned identity to a SAN entry.
Improved accessibility by using high contrast colors and more defined color boundaries when high contrast is enabled in the system display settings.
Path MTU Discovery (PMTUD) is now enabled by default.
Fixed the in-client captive-portal browser rendering a blank "Success" page on some airline Wi-Fi networks. The browser now more consistently 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.
Fixed an issue where DNS queries would fail after the connection was idle, requiring users to retry.
Fixed an issue where some Debian releases experienced inaccurate version reporting for posture checks.
Users can now register with team names in any case format without errors.
New UI fixes
- Fixed an issue where users with invalid MDM configurations were returned to the onboarding screen after successful authentication.
- Added a re-auth button and banner to the home screen so users don't miss it when their session expires.
- Added clear error messaging when the Cloudflare certificate needs to be installed.
- Brought back support for pausing the tunnel when connected to user-specified Wi-Fi networks for consumer users.
- New client UI now surfaces Split tunnel configuration and Local Domain Fallback configuration.
- Added ability to configure proxy mode for consumer users.
- Added back the option to quit for consumer users.

For RHEL deployments, this release introduces a dependency on the Extra Packages for Enterprise Linux repository (EPEL). The EPEL repository provides packages that support the captive portal detection’s in-app browser authentication and system tray icon. See Getting started with EPEL for instructions on enabling EPEL.

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.

Workers - Workers fetch requests now support cf.vary

Sun, 28 Jun 2026 00:00:00 GMT

Workers fetch() requests now support the cf.vary request option. Use cf.vary to control how Cloudflare caches origin responses with a Vary header for a single subrequest.

src/index.jsjs

export default {
	async fetch(request) {
		return fetch(request, {
			cf: {
				vary: {
					default: { action: "bypass" },
					headers: {
						accept: {
							action: "normalize",
							media_types: ["text/html", "application/json"],
						},
						"accept-language": {
							action: "normalize",
							languages: ["en", "fr", "de"],
						},
					},
				},
			},
		});
	},
};

src/index.tsts

export default {
	async fetch(request): Promise<Response> {
		return fetch(request, {
			cf: {
				vary: {
					default: { action: "bypass" },
					headers: {
						accept: {
							action: "normalize",
							media_types: ["text/html", "application/json"],
						},
						"accept-language": {
							action: "normalize",
							languages: ["en", "fr", "de"],
						},
					},
				},
			},
		});
	},
} satisfies ExportedHandler;

For more information, refer to cf.vary.

Cloudflare One, Access - Service token support for MCP server portals

Fri, 26 Jun 2026 00:00:00 GMT

You can now connect autonomous agents and bots to an MCP server portal using an Access service token. Service token sessions can reach upstream MCP servers through the portal without a browser-based OAuth flow.

To set this up:

Add a Service Auth policy that matches your service token to the portal's Access application.
Add a Service Auth policy that matches the same token to each linked MCP server's Access application.
Turn Require user auth off (on_behalf: false) for each linked server so the portal uses the admin credential instead of a per-user OAuth grant.

The bot connects with CF-Access-Client-Id and CF-Access-Client-Secret headers and sees the tools from every linked server it is authorized for. Servers that still require per-user OAuth are excluded from service token sessions because a service token cannot complete a per-user OAuth grant.

For step-by-step setup, refer to Connect with a service token.

Durable Objects, Workers - Test Durable Object eviction with new cloudflare:test helpers

Thu, 25 Jun 2026 00:00:00 GMT

The @cloudflare/vitest-pool-workers package now includes evictDurableObject and evictAllDurableObjects test helpers, exported from cloudflare:test.

These helpers let you test how a Durable Object behaves across evictions, simulating the production lifecycle where an idle Durable Object can be evicted from memory.

For more context, refer to Lifecycle of a Durable Object.

import { evictDurableObject, evictAllDurableObjects } from "cloudflare:test";
import { env } from "cloudflare:workers";

const id = env.COUNTER.idFromName("my-counter");
const stub = env.COUNTER.get(id);

// Evict the Durable Object instance pointed to by a specific stub
await evictDurableObject(stub);

// Close WebSockets instead of hibernating them
await evictDurableObject(stub, { webSockets: "close" });

// Evict all currently-running Durable Objects in evictable namespaces
await evictAllDurableObjects();

These helpers are available in @cloudflare/vitest-pool-workers@0.16.20 and later.

Learn more in the Test APIs reference and the Testing Durable Objects guide.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.6.782.1)

Wed, 24 Jun 2026 18:35:32 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

This beta release introduces upgraded security of device registration to be hardware-backed. Registration tokens can now be generated in the Secure Enclave whenever available to provide stronger protection against device impersonation.

Additional changes and improvements

This release also introduces multiple fixes and improvements including:

Improved accessibility by using high contrast colors and more defined color boundaries when high contrast is enabled in the macOS Display settings.
Path MTU Discovery (PMTUD) is now enabled by default.
Fixed an issue where DNS queries would fail after the connection was idle, requiring users to retry.
Users can now register with team names in any case format without errors.
New UI fixes
- Fixed an issue where users with invalid MDM configurations were returned to the onboarding screen after successful authentication.
- Added a re-auth button and banner to the home screen so users don't miss it when their session expires.
- Added clear error messaging when the Cloudflare certificate needs to be installed.
- Brought back support for pausing the tunnel when connected to user-specified Wi-Fi networks for consumer users.
- New client UI now surfaces Split tunnel configuration and Local Domain Fallback configuration.
- Added ability to configure proxy mode for consumer users.
- Added back the option to quit for consumer users.

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.

Data Localization Suite - Regionalized IP Bindings for Regional Services

Tue, 23 Jun 2026 00:00:00 GMT

Regional Services now supports Regionalized IP Bindings, letting you regionalize traffic at the IP layer for prefixes you bring to Cloudflare through Bring Your Own IP (BYOIP).

Where Regional Hostnames regionalize traffic by hostname, Regionalized IP Bindings let you bind a CIDR from one of your prefixes to a region — ideal for address-map deployments and any service you address by IP rather than hostname. Cloudflare then terminates TLS and processes traffic to those addresses only within the data centers in that region.

Regionalized IP Bindings requires the Regional Services and Regional Services for BYOIP entitlements. Contact your account team to enable them.

To get started, refer to Regionalized IP Bindings.

Cloudflare Mesh, Cloudflare Tunnel, Cloudflare WAN, Cloudflare One - Manage all your routes from one page in the dashboard

Fri, 19 Jun 2026 00:00:00 GMT

The Routes page in the Cloudflare dashboard now shows the routes across all of your connectors — Cloudflare Mesh and Cloudflare Tunnel routes alongside Cloudflare WAN and Magic Transit static routes — in a single table, instead of a separate routes view per product.

From the unified Routes page you can:

Visualize your network with an interactive map that shows how your destinations flow through to your connectors — including equal-cost multi-path (ECMP) routes where the same prefix is served by several connectors. Select a node to filter the table down to the routes behind it.
See every route in one table, with its destination, type, connector, priority, and source, and filter or sort to find what you need.
Create, edit, and delete routes of any supported type without leaving the page. When adding a Cloudflare WAN or Magic Transit static route, you now pick the next hop by connector name instead of typing its IP.
Manage virtual networks from a dedicated tab.
Test a route to see which connector and next hop a destination resolves to before you commit a change.

To find it, go to Networking > Routes in the dashboard sidebar.

Go to Routes ↗

Your existing routes, APIs, and configurations are unchanged — this is a dashboard experience that brings them together in one place. Learn how to add routes and manage virtual networks.

Workers - Temporary accounts for AI agent deployments

Fri, 19 Jun 2026 00:00:00 GMT

AI agents can now deploy Workers to Cloudflare without first requiring a user to sign up, open a browser-based OAuth flow, click through the dashboard, or create an API token. When an agent tries to deploy without Cloudflare credentials, Wrangler can tell it to rerun with --temporary, then deploy the Worker to a temporary preview account.

To try this with your agent, update to Wrangler 4.102.0 or later, make sure you are logged out (wrangler logout), and then ask your agent to build something and deploy it to Cloudflare. The agent should follow Wrangler's output and deploy using the --temporary flag.

wrangler deploy --temporary

The temporary deployment stays live for 60 minutes. During that window, the agent can verify the Worker, redeploy changes, and return both the live Worker URL and claim URL. Opening the claim URL lets you sign in to or create a Cloudflare account and make the temporary account permanent.

Temporary preview accounts currently support a limited set of products, including Workers, Workers Static Assets, Workers KV, D1, Durable Objects, Hyperdrive, Queues, and SSL/TLS certificates. For supported products, limits, and claim behavior, refer to Claim deployments (temporary accounts).

For more context, refer to Temporary Cloudflare Accounts for Agents ↗︎.

Cloudflare One, Access - Cloudflare identity provider is now the default for new accounts

Thu, 18 Jun 2026 00:00:00 GMT

When you create a new Zero Trust organization, Cloudflare now adds the Cloudflare identity provider as your default login method. Previously, new organizations started with one-time PIN (OTP).

With the Cloudflare identity provider, your users authenticate using their existing Cloudflare account credentials, and authentication is restricted to members of your account. You can still add OTP or connect any third-party identity provider whenever you need to.

This change only applies to newly created accounts. Existing organizations keep the login methods they already have configured. If you would like to use the Cloudflare Identity Provider in an existing account, you must enable it.

Cloudflare Images - New optimization features in Images

Tue, 16 Jun 2026 00:00:00 GMT

These updates introduce new features for optimizing and manipulating with Images:

New composite option: Control how overlays are blended with the base image.
Percentage widths: Set the dimensions of an overlay as a fraction of the dimensions of the base image.
New fit modes: Use aspect-crop to always preserve the target aspect ratio or scale-up to always enlarge images.
New upscale parameter: Apply AI upscaling to produce sharper, more detailed results when enlarging images.

Workers - Workers tracing now supports custom spans

Tue, 16 Jun 2026 00:00:00 GMT

You can now create custom trace spans in your Workers code using tracing.enterSpan(). Custom spans appear alongside the automatic platform instrumentation (fetch calls, KV reads, D1 queries, and other platform operations) in your traces and OpenTelemetry exports, with correct parent-child nesting.

The API is available via import { tracing } from "cloudflare:workers" or through the handler context as ctx.tracing:

import { tracing } from "cloudflare:workers";

export default {
  async fetch(request, env, ctx) {
    return tracing.enterSpan("handleRequest", async (span) => {
      span.setAttribute("url.path", new URL(request.url).pathname);
      const data = await env.MY_KV.get("key");
      return new Response(data);
    });
  },
};

Spans nest automatically based on the JavaScript async context, and are auto-ended when the callback returns or its returned promise settles. The Span object provides setAttribute(key, value) for attaching metadata and an isTraced property to check whether the current request is being sampled.

Tracing must be enabled in your Wrangler configuration for spans to be recorded.

For full API details and examples, refer to Custom spans.

Data Loss Prevention - Define custom topics for AI prompt protection

Thu, 11 Jun 2026 00:00:00 GMT

You can now define custom topics for AI prompt protection. Predefined AI prompt topics cover common content and intent categories such as PII, source code, and jailbreak attempts. Custom topics let you detect unique or proprietary concepts that are not included in predefined categories.

You describe a custom topic in natural language, and Cloudflare DLP detects whether a prompt matches that topic based on context rather than specific keywords. For example, a topic that describes confidential merger discussions matches a prompt that paraphrases the deal, even when the prompt never uses the word merger or names the companies involved. To detect literal values such as internal codenames or product identifiers, use a custom wordlist or pattern entry instead.

Custom topics run through the same application granular controls path as predefined AI prompt topics. Custom topics are available for ChatGPT, Google Gemini, Perplexity, and Claude.

Create a custom AI prompt topic

In the Cloudflare dashboard ↗︎, go to Zero Trust > Data loss prevention > Detection entries.
Select AI prompt topics, then select Custom Prompt Topic.
Describe the topic in natural language. Be specific about the concept you want to detect. For example, describe unreleased product roadmap details or confidential customer contract terms.
Add this detection entry to an existing DLP profile, or create a new DLP profile.
Use the profile in a Gateway HTTP policy to log or block prompts that match the topic.

For more information, refer to AI prompt topics.

Workers - Track Dynamic Workers usage from the dashboard and GraphQL API

Thu, 11 Jun 2026 00:00:00 GMT

Customers can now view the number of 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 by using workersInvocationsByOwnerAndScriptGroups and selecting distinctDynamicWorkerCount:

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:

{
	"accountTag": "<ACCOUNT_ID>",
	"filter": {
		"date_geq": "2026-06-01",
		"date_leq": "2026-06-30"
	}
}

For more information, refer to Dynamic Workers pricing.

Cloudflare Images - Manage hosted images with the Images binding

Wed, 10 Jun 2026 00:00:00 GMT

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) — Upload a new image to your account.
.list(options) — List images with pagination.
.image(imageId).details() — Get image metadata.
.image(imageId).bytes() — Stream the original image bytes.
.image(imageId).update(options) — Update metadata or access controls.
.image(imageId).delete() — Delete an image.

For example, you can upload an image from a request body and return its metadata:

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:

const bytes = await env.IMAGES.hosted.image("IMAGE_ID").bytes();
return new Response(bytes);

For more information, refer to the Images binding.

Gateway, Cloudflare Mesh, Workers VPC - Filter Workers' public Internet traffic using Gateway policies

Fri, 05 Jun 2026 00:00:00 GMT

Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway. 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.

Worker
Calls env.EGRESS.fetch()
VPC binding
Cloudflare Mesh
Bind via cf1:network
↓
Cloudflare Gateway
Policies applied:
DNS HTTP Network
↓
Public Internet
Any public hostname or IP

Gateway logsDNSHTTPNetwork

What you get by default:

Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network 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.

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

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

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

// 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. For policy authoring, refer to Cloudflare Gateway traffic policies.

Access - Share identity providers across accounts with IdP federation

Thu, 04 Jun 2026 00:00:00 GMT

Cloudflare Access now supports 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.

Cloudflare Fundamentals, Workers, D1, R2, KV, Queues, Vectorize, Durable Objects, Containers - Billable usage and budget alerts now in product sidebars

Thu, 04 Jun 2026 00:00:00 GMT

Pay-as-you-go customers can now view billable usage and create budget alerts directly from the product overview pages for Workers & Pages, D1, R2, Workers KV, Queues, Vectorize, Durable Objects, and 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 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.

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.

Access - SAML assertion encryption for identity providers

Wed, 03 Jun 2026 00:00:00 GMT

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 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.

Workers - New Workers bulk secrets API endpoint

Wed, 03 Jun 2026 00:00:00 GMT

You can now create, update, or delete multiple secrets for your Worker in a single request using the bulk secrets endpoint.

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:

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).

Workers - Store Wrangler's OAuth credentials in your OS keychain

Wed, 03 Jun 2026 00:00:00 GMT

Wrangler can now store the OAuth credentials returned by wrangler login in an AES-256-GCM ↗︎-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:

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:

🔐 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 ↗︎ via the secret-tool CLI from the libsecret-tools package.
Windows uses Credential Manager via @napi-rs/keyring ↗︎, installed on-demand the first time you opt in.

Refer to 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.

Cloudflare WAN, Cloudflare One - Cisco IOS XE

Tue, 02 Jun 2026 00:00:00 GMT

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 guide.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.5.1155.1)

Fri, 29 May 2026 00:55:38 GMT

A new Beta release for the macOS Cloudflare One Client is now available on the beta releases downloads page.

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 / network policy. 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 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 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 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 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.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.5.1155.1)

Fri, 29 May 2026 00:55:37 GMT

A new Beta release for the Windows Cloudflare One Client is now available on the beta releases downloads page.

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 / network policy. 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 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 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 and documentation 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 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 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.

Access - Tool and prompt aliases for MCP server portals

Thu, 28 May 2026 00:00:00 GMT

When you connect third-party MCP servers through MCP server portals, you have no control over how the server author named tools or wrote descriptions. Unclear names make it harder for AI agents to select the right tool and harder for users to understand what is available.

You can now rename tools and prompts and rewrite their descriptions directly on the portal, without modifying the upstream server. For example, a tool named super_cool_tool can become search_customer_records with a description tailored to your organization.

Modified tools display a Modified label in the tools list so administrators can see which tools have been customized at a glance.

Aliases override the metadata that MCP clients receive. You can set them at two levels:

Per portal: Applies only within a specific portal. Takes precedence over server-level aliases.
Per server: Applies across all portals that use the server.

You can reset an alias at any time to restore the original upstream name.

For more information, refer to Tool and prompt aliases.

Cloudflare Mesh, Cloudflare One - High availability replica management for Cloudflare Mesh

Thu, 28 May 2026 00:00:00 GMT

The Cloudflare Mesh dashboard now shows per-replica details for high availability nodes. You can see which replica is active, view each replica's Mesh IP and connection details, and manually trigger failover — all from the node detail page.

What's new

Replica tabs on the node detail page — switch between replicas to see each one's Mesh IP, edge data center, origin IP, platform, version, and uptime.
Active/passive badges identify which replica is currently routing traffic.
Manual failover — promote a passive replica to active with a single click. The previous active replica switches to standby.
HA badge in the overview table identifies nodes running multiple replicas.
Active replica IP shown in the overview table — the dashboard now resolves which replica is active and displays the correct Mesh IP.

Manual failover

To manually promote a passive replica:

In the Cloudflare dashboard ↗︎, go to Networking > Mesh.
Select an HA-enabled node.
Select the passive replica tab.
Select Promote to active and confirm.

Traffic reroutes to the promoted replica immediately. Refer to High availability for details on failover behavior.

Cloudflare One, Gateway - Write regex using natural language in Cloudflare One

Wed, 27 May 2026 00:00:00 GMT

Cloudflare Gateway policy selectors which support regular expressions can now be authored in the dashboard using natural language. When building a policy with a regex-based selector (like matches regex), you can describe what you want to match in plain English and the Cloudflare Agent will generate and validate a corresponding regular expression.

To get started, select a regex-compatible selector in the Gateway policy builder and select the icon. You'll see an input field for natural language, such as "any URL starting with /api/v1" or ".com, .net, and .app hosts which contain gooogle in the host."

You can also use the tool to explain existing regular expressions. If a policy already contains a regex pattern, you can instantly generate a plain-language description.

A built-in feedback mechanism allows you to rate each interaction to help improve output quality over time.

For more information, refer to Cloudflare One firewall policies and expect to see the same functionality supported soon in Data loss prevention profiles.

Cloudflare Images - Transformation flows in Images

Wed, 27 May 2026 00:00:00 GMT

Flows are automated rules that pair conditions (such as file extension, URL path, or query parameter) with parameters. Set up a flow to automatically apply image optimization to matching requests on your zone without writing code or changing URLs.

There are two modes for transformation flows:

Provider flows — Migrate from another image optimization service. Your existing URLs continue to work while Cloudflare rewrites provider-specific parameters to their Cloudflare equivalents. Currently, Cloudflare supports provider flows for Fastly Image Optimizer.
Custom flows — Define your own conditions and actions for use cases like automatic format conversion, responsive sizing with width=auto, or directory-based optimization.

To get started, go to Images > Transformations > Automation in the Cloudflare dashboard ↗︎.

Learn more about transformation flows.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Cloudflare Tunnel now runs connectivity pre-checks at startup

Wed, 27 May 2026 00:00:00 GMT

Starting with cloudflared version 2026.5.2 ↗︎, Cloudflare Tunnel automates the entire connectivity pre-checks workflow directly inside the binary. Previously, customers had to install dig and netcat and run those commands by hand to verify their environment. Now cloudflared does it natively at startup — and surfaces actionable remediation when something is blocked.

On every cloudflared tunnel run (and cloudflared tunnel diag), the binary now natively checks:

DNS resolution — region1.v2.argotunnel.com and region2.v2.argotunnel.com resolve to valid Cloudflare IPs.
Transport connectivity — outbound UDP (QUIC) and TCP (HTTP/2) on port 7844.
Management API — outbound TCP/443 to api.cloudflare.com for software updates.

Results are printed in a scannable CLI table with three states:

✅ Pass — the check succeeded.
⚠️ Warn — a non-blocking issue, for example the Management API is unreachable so automatic updates will not work, but the tunnel will still come up.
❌ Fail — a blocking issue, with a specific remediation hint (for example, Allow outbound UDP on port 7844).

If DNS is unresolvable, or both UDP and TCP fail on port 7844, cloudflared exits early with the failure rather than looping on opaque failed to dial errors.

Pre-checks now run automatically on every start, which also catches regressions like overnight firewall policy changes — no need to remember to rerun the troubleshooting guide.

To get the new behavior, upgrade cloudflared to version 2026.5.2 or later. For more details, refer to the Connectivity pre-checks documentation.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.4.1390.0)

Tue, 26 May 2026 22:26:01 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

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

Additional Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.
Fixed a proxy mode connection stall issue.

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.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.4.1390.0)

Tue, 26 May 2026 22:26:00 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

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

Additional Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.
Fixed a proxy mode connection stall issue.

Known issues

Registration authentication for devices via the integrated WebView2 browser is unavailable in this version as a temporary measure. As a result, the client will utilize the default browser on the device to complete the authentication process.
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.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.4.1390.0)

Tue, 26 May 2026 20:32:41 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release introduces the new Cloudflare One Client UI for Linux! 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

Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.
Official support for RHEL 9 has been added for Cloudflare Mesh nodes. To install the RHEL 9 package, the Extra Packages for Enterprise Linux (EPEL) repository must be active, as it contains dependencies required for the tray icon and captive portal webview.
Fixed a proxy mode connection stall issue.

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.

Cloudflare Fundamentals, Cloudflare One, Cloudflare Tunnel for SASE, Cloudflare Tunnel, Cloudflare Mesh - Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

Thu, 21 May 2026 00:00:00 GMT

You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

What is new

When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
Scope a single policy to one or many Tunnels and Mesh nodes at once.

How it works

Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.
Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.
Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

Get started

Configure granular permissions for Cloudflare Tunnel.
Configure granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One.
Review the resource-scoped roles on the Cloudflare role reference.

Access - Cloudflare as identity provider and account membership selector

Tue, 19 May 2026 00:00:00 GMT

Cloudflare Access now supports using Cloudflare itself as an identity provider. If you publish an Access application and select Cloudflare as the login method, users can sign in with their existing Cloudflare account — no one-time PINs, no third-party IdP configuration, and no shared email inboxes. Authentication is backed by Cloudflare's own account security (including multi-factor authentication), making it both simpler to set up and more secure than OTP-based login for most use cases.

Cloudflare is now the default identity provider for all newly created Zero Trust accounts, replacing One-time PIN.

This also enables two new capabilities:

Cloudflare Account Member selector — A new policy selector that matches users based on their membership in a Cloudflare account. You can target the current account or specify a different account ID for cross-account access scenarios.
Restrict to account members — An identity provider configuration option that limits authentication to users who are members of your Cloudflare account.

To get started, add Cloudflare as an identity provider in your Zero Trust settings.

CASB - CASB adds support for Claude Compliance API

Tue, 19 May 2026 00:00:00 GMT

Cloudflare CASB now integrates with the Claude Compliance API ↗︎. This enhancement gives security teams visibility into Claude usage patterns, admin activity, and compliance-relevant events across their organization.

The Claude Compliance API provides structured access to audit logs and administrative actions within Claude Enterprise and Claude Platform. Cloudflare CASB ingests this data to surface security findings that help organizations enhance their security posture and enforce AI governance.

Key capabilities

Starting today, security teams can scan for security findings across the following assets:

Public projects — Projects set to public visibility
Project attachment — Files and documents added to projects that violate DLP policies
Chat files — User-uploaded and provider-generated files that violate DLP policies
Chat messages — User prompts and provider responses that violate DLP policies
Artifacts — Provider-generated documents and files that violate DLP policies

Learn more

This integration is available to all Cloudflare One customers. New Cloudflare customers can sign up and start with their first two integrations for free. Existing customers can enable the integration directly in the dashboard. The integration begins scanning immediately and surfaces findings in the dashboard within minutes.

Cloudflare WAN, Magic Transit - Network Analytics support for Unified Routing

Mon, 18 May 2026 00:00:00 GMT

Network Analytics is now fully supported for accounts using Unified Routing mode. Traffic that traverses Unified Routing onramps and offramps is now visible in Network Analytics with the same dimensions and filters as traffic on the standard data plane.

This closes a parity gap for customers who had moved tunnels onto Unified Routing and lost visibility into their dataplane traffic in the Network Analytics dashboard. No configuration change is required — analytics data is collected automatically for all accounts with Unified Routing enabled.

For the remaining beta limitations, refer to Traffic steering beta limitations.

Workers - Share local dev servers through Cloudflare Tunnel in Wrangler and Vite

Mon, 18 May 2026 00:00:00 GMT

You can now share local dev sessions through Cloudflare Tunnel and get a public URL when using either Wrangler or the Cloudflare Vite plugin. This is useful when you need to share a preview, test a webhook, or access your app from another device.

This lets you either:

start a temporary Quick Tunnel with a random *.trycloudflare.com hostname, or
use an existing named tunnel for a stable hostname and to restrict access with Cloudflare Access.

To start a tunnel, press t in Wrangler or t + Enter in Vite while your dev server is running. For details on setting up a named tunnel, refer to Share a local dev server.

Workers - New Domains tab in the Workers dashboard

Thu, 14 May 2026 00:00:00 GMT

In your Worker's dashboard, there is now a dedicated Domains tab where you can purchase a new domain through Cloudflare Registrar and have it automatically connected, add an existing domain, and manage all of your Worker's routing in one place.

You can also enable or disable your workers.dev subdomain and Preview URLs, put them behind Cloudflare Access to require sign-in, and jump directly to analytics or domain overview for any connected domain.

To get started, go to Workers & Pages, select a Worker, and open the Domains tab.

Go to Workers & Pages ↗

Cloudflare One, Access - Refreshed Access login page

Tue, 12 May 2026 00:00:00 GMT

The Access login page and one-time password (OTP) page now feature a refreshed design that improves visual consistency, user trust, and mobile responsiveness.

Before:

After:

The updated login experience includes:

Unified authentication card - All sign-in options (identity provider buttons, email input, OTP) now appear in a single card with consistent styling, replacing the previous multi-section layout.
Consistent button styling - Identity provider buttons use a uniform size and layout for easier scanning and selection.
Better mobile experience - Responsive layout improvements ensure the login page renders correctly on phones and tablets.
Dark mode support - The login page now supports dark mode.

Cloudflare WAN, Magic Transit, Cloudflare One - New accounts assigned a single IPv4 anycast address

Tue, 12 May 2026 00:00:00 GMT

New Magic Transit and Cloudflare WAN accounts are now assigned a single IPv4 anycast address by default.

Cloudflare handles failures on its network automatically by advertising your endpoint IP from multiple nodes across many globally distributed data centers. To handle failures on your network, configure two tunnels from separate routers.

To request additional anycast IP addresses for your account, contact your account team.

For tunnel configuration guidance, refer to Configure tunnel endpoints for Cloudflare WAN or Configure tunnel endpoints for Magic Transit.

Gateway - Create Gateway firewall policies with natural language

Tue, 12 May 2026 00:00:00 GMT

Cloudflare Gateway now supports natural language policy creation for DNS, HTTP, and Network firewall policies. Administrators can describe the outcome they want in plain language, and Cloudflare will generate a complete policy rule that populates the policy builder form.

To create a policy with natural language, select Create with AI on any Gateway firewall policy tab. Choose a policy type, describe what the policy should do, and a fully configured rule will appear in the policy builder for review. You can edit any field before saving, or re-generate with a different prompt.

The generated policy incorporates your account context - including lists, DLP profiles, applications, and device posture checks - so that references to your existing resources resolve automatically.

A built-in feedback mechanism allows you to rate each generated policy and provide optional comments, which Cloudflare uses to improve output quality over time.

For more information, refer to Gateway firewall policies.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.4.1350.0)

Mon, 11 May 2026 17:35:58 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

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

Additional Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.

Known issues

Registration authentication for devices via the integrated WebView2 browser is unavailable in this version as a temporary measure. As a result, the client will utilize the default browser on the device to complete the authentication process.
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.

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.4.1350.0)

Mon, 11 May 2026 17:35:57 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

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

Additional Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.

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.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.4.1350.0)

Mon, 11 May 2026 15:17:54 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

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

Changes and improvements

Added a new CLI command: warp-cli mdm refresh. This command executes an immediate refresh of the Mobile Device Management (MDM) configuration file.
Official support for RHEL 9 has been added for Cloudflare Mesh nodes. To install the RHEL 9 package, the Extra Packages for Enterprise Linux (EPEL) repository must be active, as it contains dependencies required for the tray icon and captive portal webview.

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.

Cloudflare WAN, Magic Transit - NAT-T support for IKE on UDP port 500

Mon, 11 May 2026 00:00:00 GMT

Cloudflare IPsec now supports the standard NAT traversal (NAT-T) flow, where IKE begins on UDP port 500 and switches to UDP port 4500 after NAT is detected.

Previously, devices behind NAT had to be configured to initiate IKE on UDP port 4500 directly. Devices that started on UDP port 500 could not complete the IKE handshake when NAT was in the path. This required custom configuration on devices such as VeloCloud SD-WAN edges, Cisco IOS-XE routers, and Juniper SRX firewalls, and was not possible on every platform.

What changed:

Devices behind NAT can now initiate IKE on either UDP port 500 or UDP port 4500.
Devices that start IKE on UDP port 500 and switch to UDP port 4500 after NAT detection now complete the handshake successfully.
No configuration change is required on Cloudflare. The change is available for all IPsec tunnels on Cloudflare WAN and Magic Transit.

This change does not affect existing tunnels:

Tunnels using UDP port 500 with no NAT detected continue to operate as before.
Tunnels configured to start IKE on UDP port 4500 continue to operate as before.
NAT detection logic is unchanged.

For configuration details, refer to GRE and IPsec tunnels.

Workers, WAF - WAF and framework adapter mitigations for React and Next.js vulnerabilities

Thu, 07 May 2026 12:00:00 GMT

Multiple security vulnerabilities were disclosed by the React team and Vercel affecting React Server Components and Next.js. These include denial of service, middleware and proxy bypass, server-side request forgery, cross-site scripting, and cache poisoning issues across a range of severity levels.

We strongly recommend updating your application and its dependencies immediately. Patched versions are available for React (react-server-dom-webpack, react-server-dom-parcel, and react-server-dom-turbopack 19.0.6, 19.1.7, and 19.2.6) and Next.js (15.5.16 and 16.2.5).

WAF protections

Cloudflare WAF rules deployed in response to prior React Server Component CVEs (CVE-2025-55184 ↗︎ and CVE-2026-23864 ↗︎) already provide coverage for the newly disclosed denial-of-service vulnerabilities. These rules are enabled by default with a Block action for all customers using the Cloudflare Managed Ruleset, including Free plan customers using the Free Managed Ruleset.

Ruleset	Rule description	Rule ID	Default action
Cloudflare Managed Ruleset	React - DoS - `CVE-2025-55184` ↗︎	`2694f1610c0b471393b21aef102ec699`	Block
Cloudflare Managed Ruleset	React - DoS - `CVE-2026-23864` ↗︎	`aaede80b4d414dc89c443cea61680354`	Block

The existing rules detect the underlying attack patterns generically. As a result, they apply to the new CVE-2026-23870 ↗︎ denial-of-service vulnerability in Server Components and the corresponding Next.js advisory GHSA-8h8q-6873-q5fj ↗︎.

Cloudflare is investigating whether WAF rules can be safely and effectively deployed for three of the high-severity advisories: CVE-2026-23870 ↗︎ / GHSA-8h8q-6873-q5fj ↗︎, GHSA-267c-6grr-h53f ↗︎, and GHSA-mg66-mrh9-m8jx ↗︎. If it is possible to create a managed WAF rule that mitigates these CVEs and does not potentially break application behavior, Cloudflare will add additional managed WAF rules. These rules will be announced through the WAF changelog. Because these vulnerabilities were shared with Cloudflare with minimal advance notice, we are still investigating what WAF mitigations are possible.

Several of the disclosed vulnerabilities are not possible to block in WAF. We strongly recommend updating your applications so they are not purely reliant on WAF mitigations.

Customers on Pro, Business, or Enterprise plans should ensure that Managed Rules are enabled.

Next.js adapters

Vinext: Vinext ↗︎ is a Vite plugin that reimplements the Next.js API surface. Vinext's latest release is not vulnerable to any of the disclosed CVEs. Vinext's architecture differs from stock Next.js in ways that sidestep the affected code paths. For example, it does not implement the PPR resume protocol, does not expose Pages Router data-route endpoints, and strips internal headers such as x-nextjs-data at request boundaries. As an extra layer of defense, we added a React 19.2.6 or later requirement when running vinext init (PR #1118 ↗︎, PR #1112 ↗︎) to prevent accidentally running a vulnerable version of React with Vinext.

OpenNext on Cloudflare: OpenNext is an adapter that lets you deploy Next.js apps to the Cloudflare Workers platform. OpenNext itself is not directly vulnerable to the React denial-of-service CVE, but users must update the Next.js version in their application. The OpenNext team has updated the adapter to further harden against these vectors and released a new version of the Cloudflare adapter. Test fixtures and examples have been updated to use patched versions (PR #1255 ↗︎).

Summary of disclosed vulnerabilities

Advisory	Severity	Issue	WAF status
`CVE-2026-23870` ↗︎ / `GHSA-8h8q-6873-q5fj` ↗︎	High	Denial of service in Server Components	WAF rules in place: `2694f1610c0b471393b21aef102ec699`, `aaede80b4d414dc89c443cea61680354` Cloudflare is investigating additional managed WAF coverage
`GHSA-267c-6grr-h53f` ↗︎	High	Middleware bypass via segment-prefetch routes	Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
`GHSA-mg66-mrh9-m8jx` ↗︎	High	Denial of service via connection exhaustion in Cache Components	Cloudflare is investigating if this can be safely and effectively mitigated by a managed WAF rule
`GHSA-492v-c6pp-mqqv` ↗︎	High	Middleware bypass via dynamic route parameter injection	Not possible to safely enable a managed WAF rule without potentially breaking application behavior
`GHSA-c4j6-fc7j-m34r` ↗︎	High	SSRF via WebSocket upgrades	Not possible to safely enable a managed WAF rule without potentially breaking application behavior
`GHSA-36qx-fr4f-26g5` ↗︎	High	Middleware bypass in Pages Router i18n	Custom WAF rule possible; global managed rule could potentially break application behavior
`GHSA-ffhc-5mcf-pf4q` ↗︎	Moderate	XSS via CSP nonces	Custom WAF rule possible; global managed rule could potentially break application behavior
`GHSA-gx5p-jg67-6x7h` ↗︎	Moderate	XSS in `beforeInteractive` scripts	Not possible to safely enable a managed WAF rule without potentially breaking application behavior
`GHSA-h64f-5h5j-jqjh` ↗︎	Moderate	Denial of service in Image Optimization API	Custom WAF rule possible; global managed rule could potentially break application behavior
`GHSA-wfc6-r584-vfw7` ↗︎	Moderate	Cache poisoning in RSC responses	Custom WAF rule possible; global managed rule could potentially break application behavior
`GHSA-vfv6-92ff-j949` ↗︎	Low	Cache poisoning via RSC cache-busting collisions	Not possible to safely enable a managed WAF rule without potentially breaking application behavior
`GHSA-3g8h-86w9-wvmq` ↗︎	Low	Middleware redirect cache poisoning	Custom WAF rule possible; global managed rule could potentially break application behavior

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Custom DHCP options on Cloudflare One Appliance

Thu, 07 May 2026 00:00:00 GMT

When the Cloudflare One Appliance is acting as the DHCP server for a LAN, you can now configure custom DHCP options on the leases it issues. This unlocks workflows such as PXE / iPXE boot, VoIP phone provisioning, and vendor-specific client configuration.

Each option is defined by option_number, value, and one of four value types: text, integer, hex, or ip. Configurations are validated on the appliance before being applied — invalid configurations are rejected and the underlying error is returned to the API caller, so a bad option will not disrupt the live DHCP service.

For details, refer to DHCP server options.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Source-based breakout and prioritization on Cloudflare One Appliance

Thu, 07 May 2026 00:00:00 GMT

Breakout and traffic prioritization rules on the Cloudflare One Appliance can now match by source in addition to destination application. You can pin breakout or priority behavior to:

A source LAN interface — VLANs attached to that LAN are included automatically.
A source IP address, range, or CIDR block.

This is the natural way to break out a guest VLAN to the local Internet, or to prioritize traffic from a specific subnet, without enumerating destination applications.

For details, refer to Breakout traffic.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Self-serve provisioning of Cloudflare One Virtual Appliance via API

Thu, 07 May 2026 00:00:00 GMT

You can now create, rotate, and delete Cloudflare One Virtual Appliance instances and their license keys directly via the API and Terraform.

Create a virtual appliance and receive a license key: POST /accounts/{account_id}/magic/connectors with device.provision_license: true.
Rotate the license key for an existing virtual appliance: PATCH /accounts/{account_id}/magic/connectors/{connector_id} with provision_license: true. The previous key is immediately and irrevocably revoked.
Delete a virtual appliance to release the associated licensed device.

The license key is returned in the response only once, at create or rotate time. Copy and store it securely.

For details, refer to Configure a Cloudflare One Virtual Appliance.

Stream - Introducing Stream Bindings for Workers

Thu, 07 May 2026 00:00:00 GMT

You can now interact with your Stream video library using new bindings for Workers! This allows customers to upload content to Stream, provision direct uploads, manage videos, and generate signed URLs from a Worker without making authenticated API calls. We're excited to bring Stream and Workers closer together to empower more programmatic pipelines, tighter integrations, and support generative AI and inference workloads.

Use the Stream binding when you want to:

Upload videos from URLs or create basic direct upload links for end users
Generate signed playback tokens without managing signing keys
Manage video metadata, captions, downloads, and watermarks
Build video pipelines entirely within Workers

To get started, add the Stream binding to your Wrangler configuration:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "stream": {
    "binding": "STREAM"
  }
}

[stream]
binding = "STREAM"

Generate a video with AI and upload directly to Stream or send a URL of a file you already have:

const aiResponse = await env.AI.run(
	"google/veo-3.1",
	{
		prompt: "A dog walking next to a river",
		duration: "10s",
		aspect_ratio: "16:9",
		resolution: "1080p",
		generate_audio: true,
	},
	{
		gateway: { id: "experiments" },
	},
);

// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;

// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';

// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);

// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

const aiResponse = await env.AI.run(
	'google/veo-3.1',
	{
		prompt: 'A dog walking next to a river',
		duration: '10s',
		aspect_ratio: '16:9',
		resolution: '1080p',
		generate_audio: true,
	},
	{
		gateway: { id: 'experiments' },
	},
);

// Veo will return a URL of the generated asset.
const videoUrl = aiResponse.result.video;

// Alternative option: a video of the Austin Office mobile
// const videoUrl = 'https://pub-d9fcbc1abcd244c1821f38b99017347f.r2.dev/aus-mobile.mp4';

// Upload to Stream by providing a URL
const streamVideo = await env.STREAM.upload(videoUrl);

// The streamVideo response will include the video ID, playback and manifest
// URLs, and other information, just like the REST API.

Generate a signed URL without using a signing key or an API call:

const video_id = "ce800be43a9772f4bb02f35b860fb516";
const token = await env.STREAM.video(video_id).generateToken();

// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

const video_id = 'ce800be43a9772f4bb02f35b860fb516';
const token = await env.STREAM.video(video_id).generateToken();

// Use the "token" in an iframe embed code, manifest URL, or thumbnail:
const embedUrl = `https://customer-igynxd2rwhmuoxw8.cloudflarestream.com/${token}/iframe`;

Get and set video properties easily:

const video_id = "46c8b7f480d410840758c1cb14a72e47";
const result = await env.STREAM.video(video_id).details();

await env.STREAM.video(video_id).update({
	meta: { name: "sample video" },
});

const video_id = '46c8b7f480d410840758c1cb14a72e47';
const result = await env.STREAM.video(video_id).details();

await env.STREAM.video(video_id).update({
  meta: { name: 'sample video' }
});

For setup instructions and the full API reference, refer to Bind to Workers API.

Get started with your Agent

Add a binding for Cloudflare Stream (env.STREAM). On the watch page, use the Stream binding to get info based on the ID, and leverage video.meta.name as the page title.

Workers - Automatic tracing across Durable Object and Worker subrequests

Thu, 07 May 2026 00:00:00 GMT

You can now get a single unified trace across Worker-to-Worker subrequests, with trace context propagating automatically. Previously, automatic tracing produced disconnected traces when a Worker called another Worker through a service binding or Durable Object.

This means you can:

Follow a request through your entire Worker architecture in one trace view
See service binding and Durable Object calls as nested child spans instead of separate traces
Debug cross-Worker request flows in the Cloudflare dashboard or in an external observability platform via OpenTelemetry

Tracing must be enabled in your Wrangler configuration for traces to be recorded. Checkout Workers tracing to get started.

Up next, we are working on external trace context propagation using W3C Trace Context standards ↗︎, which will allow traces from your Workers to link with traces from services outside of Cloudflare.

Email security - Cloudy Summaries in PhishNet O365

Wed, 06 May 2026 18:15:13 GMT

PhishNet users can now access Cloudy summaries directly within the email investigation experience. When reviewing a message in PhishNet, users will see an AI-generated summary that provides additional context and key details about the email.

These summaries help users quickly understand the nature of a message without needing to manually parse through headers, body content, and detection signals. Cloudy surfaces the most relevant information so users can make faster, more informed decisions about suspicious emails.

These summaries are not trained on customer data. They are generated using the outputs of our existing detection models and analysis systems.

This feature is available for PhishNet with Office 365. Support for Gmail will be available by the end of the quarter.

Cloudflare One - IPv6 CIDR routes for Cloudflare Mesh

Wed, 06 May 2026 00:00:00 GMT

Cloudflare Mesh nodes now support IPv6 CIDR routes. You can advertise both IPv4 and IPv6 subnets through your Mesh nodes, making IPv6-only or dual-stack private networks reachable from any enrolled device.

To add an IPv6 route, follow the same steps as adding an IPv4 route — enter the IPv6 CIDR (for example, fd00::/64) when configuring the route in the dashboard ↗︎ or via the API.

Cloudflare One, Cloudflare WAN - Post-quantum IPsec interoperability with third-party devices

Thu, 30 Apr 2026 00:00:00 GMT

Cloudflare IPsec now supports post-quantum key agreement with compatible third-party devices. Cisco ↗︎ and Fortinet ↗︎ are the first third-party vendors validated to interoperate with Cloudflare IPsec using ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).

Post-quantum IPsec uses RFC 9370 ↗︎ and draft-ietf-ipsecme-ikev2-mlkem ↗︎ to negotiate hybrid key agreement during the IKEv2 IKE_INTERMEDIATE phase. This combines classical Diffie-Hellman (Group 20) with ML-KEM-768 or ML-KEM-1024 to protect against harvest-now, decrypt-later ↗︎ attacks.

Key details:

Compatible with Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1 and Fortinet FortiOS 7.6.6 and later.
Uses ML-KEM-768 or ML-KEM-1024 as an additional Key Exchange to DH Group 20.
Follows RFC 9370 and draft-ietf-ipsecme-ikev2-mlkem standards.
No additional licensing required.

Post-quantum IPsec with third-party devices is now generally available with confirmed interoperability for the platforms listed above. Cloudflare intends to support interoperability with more vendors as they build out support for draft-ietf-ipsecme-ikev2-mlkem. Contact your account team to discuss support for additional vendors.

For supported key exchange methods and the list of validated platforms, refer to GRE and IPsec tunnels.

Data Loss Prevention - Classify sensitive content with Data Classification

Thu, 30 Apr 2026 00:00:00 GMT

Cloudflare DLP now includes Data Classification, which lets administrators organize and label sensitive content using labels, templates, and reusable data classes.

With Data Classification, administrators can define labels such as sensitivity schemas and levels, and data tag groups and tags. Administrators can also build from Cloudflare-managed templates and create reusable data classes that combine detection entries, other data classes, sensitivity levels, and data tags.

You can then use those classifications in custom DLP profiles to identify the severity of sensitive content, understand where it exists, and apply that logic consistently across DLP profiles.

For more information, refer to Data Classification.

Data Loss Prevention - New predefined detection entries are available

Thu, 30 Apr 2026 00:00:00 GMT

Cloudflare DLP now includes new predefined detection entries.

The expanded catalog includes detections for specific credential types, webhooks, addresses, tax identifiers, national IDs, financial data, and crypto wallets.

Examples include GitHub PAT, OpenAI API Key, Slack Webhook, Discord Webhook, US Physical Address, and Bitcoin Wallet.

For the full list, refer to Predefined detection entries.

Digital Experience Monitoring - Digital experience tests to authenticated resources and enhanced configuration

Wed, 29 Apr 2026 00:00:00 GMT

Digital experience tests now support testing applications protected by Cloudflare Access or third-party authentication. All authentication secrets are managed via Cloudflare Secret Store.

Digital experience tests also have enhanced configuration options including:

New HTTP methods (DELETE, PATCH, POST, PUT)
Secret Store headers, custom plain text headers, and custom request bodies
Advanced settings: follow redirects, response bodies, response headers, and allow untrusted certificates

Gateway - Gateway Authorization Proxy and hosted PAC files are now generally available

Wed, 29 Apr 2026 00:00:00 GMT

The Gateway Authorization Proxy and hosted PAC files are now generally available for all plan types.

Authorization proxy endpoints add an identity-aware option alongside the existing source IP proxy endpoints, using Cloudflare Access authentication to verify who a user is before applying Gateway filtering — without installing the Cloudflare One Client. Cloudflare-hosted PAC files let you create and distribute PAC files directly from Cloudflare One on Cloudflare's global network.

These features are ideal for environments where deploying a device client is not an option, such as virtual desktops (VDI) or compliance-restricted endpoints.

To get started, refer to the proxy endpoints documentation.

Digital Experience Monitoring - Internet outage notifications for devices

Tue, 28 Apr 2026 00:00:00 GMT

Digital Experience will display a dashboard notification when an Internet outage or traffic anomaly may impact a Cloudflare One Client device based on its geographic location or network connection.

This Internet outage and traffic anomaly data is pulled from Cloudflare Radar ↗︎. All Internet outage and traffic anomaly observations can be viewed in the Radar Outage Center ↗︎.

Digital Experience Monitoring - Cloudflare One Client speed tests

Tue, 28 Apr 2026 00:00:00 GMT

IT teams can now remotely run speed tests from the Cloudflare One Client to Cloudflare's network edge.

Each speed test includes the following metrics:

Internet speed: download and upload throughput
Latency: download, upload, unloaded latency, and jitter
Network quality score: video streaming, webchat/real-time communication (RTC)

In the Cloudflare dashboard ↗︎, go to Zero Trust > Insights > Digital experience > Diagnostics and select Run diagnostics to use the feature today.

Data Loss Prevention - Create and manage DLP detection entries outside of profiles

Tue, 28 Apr 2026 00:00:00 GMT

You can now create, view, and manage DLP detection entries outside of profiles.

Detection entries are no longer hidden inside individual profiles. Administrators can manage detection entries directly from the Detection entries section and use them in custom DLP profiles.

For more information, refer to Configure detection entries.

Data Loss Prevention - Detect PII records with a new predefined DLP profile

Tue, 28 Apr 2026 00:00:00 GMT

Cloudflare DLP now includes a new predefined profile designed to detect PII records that contain multiple types of personal data: Personally Identifiable Information (PII) Record.

Most predefined and custom DLP profiles match when any enabled detection entry matches. The Personally Identifiable Information (PII) Record profile is different. It only matches when at least three unique detection entries are found in close proximity, which reduces false positives from standalone values that may not represent a real PII record.

Detection entries included in the profile:

AU Passport Number
American Express Card Number
Diners Club Card Number
US Driver's License Number
Email Address
Full Name
US Mailing Address
Mastercard Card Number
US Individual Tax Identification Number (ITIN)
US Passport Number
US Phone Number
Union Pay Card Number
United States SSN Numeric Detection
Visa Card Number

For more information, refer to predefined DLP profiles.

Gateway, Cloudflare One - Network Session Logs now available for all on-ramps

Fri, 24 Apr 2026 00:00:00 GMT

Zero Trust Network Session Logs are now generated for all traffic proxied through Cloudflare Gateway, regardless of on-ramp type. This includes traffic from proxy endpoints (PAC files) and Browser Isolation egress — on-ramps that previously did not generate session logs.

Customers who already consume the zero_trust_network_sessions dataset via Logpush or Log Explorer may see increased log volume if they use these on-ramps.

For field definitions, refer to Zero Trust Network Session Logs. For traffic analysis, refer to Network session analytics.

Access - AAGUID restrictions and AMR matching for Access independent MFA

Thu, 23 Apr 2026 00:00:00 GMT

Independent MFA in Cloudflare Access now supports two additional organization-level controls:

Restrict authenticators by AAGUID — Limit enrollment to a specific set of WebAuthn authenticators using their AAGUID ↗︎. This is useful for organizations that require FIPS-validated security keys or company-issued hardware. AAGUIDs are managed through a new List type.
AMR matching — Skip the independent MFA prompt when the identity provider has already performed an equivalent MFA. Access reads the amr claim defined in RFC 8176 ↗︎ and matches supported values such as hwk, otp, and fpt to the authenticator types allowed on the application or policy. This prevents users from having to complete MFA twice when their identity provider already enforces it.

To get started, refer to Independent MFA.

Cloudflare Network Firewall, Magic Transit, Cloudflare WAN - Country rules supported in Unified Routing

Tue, 21 Apr 2026 12:00:00 GMT

Cloudflare Advanced Network Firewall Country rules are now supported for accounts using Unified Routing mode. This feature requires a Cloudflare Advanced Network Firewall subscription.

You can create firewall rules that match traffic based on source or destination country to enforce geographic access policies across your network.

This is the first of the Cloudflare Advanced Network Firewall features to become available in Unified Routing. Support for additional features - IP Lists, ASN Lists, Threat Intel Lists, IDS, Rate Limiting, SIP, and Managed Rulesets - is planned.

For the full list of current beta limitations, refer to Traffic steering beta limitations.

Cloudflare Fundamentals, Workers - Introducing Billable Usage dashboard and Budget alerts

Tue, 21 Apr 2026 00:00:00 GMT

Pay-as-you-go customers can now monitor usage-based costs and configure spend alerts through two new features: the Billable Usage dashboard and Budget alerts.

Billable Usage dashboard

The Billable Usage dashboard provides daily visibility into usage-based costs across your Cloudflare account. The data comes from the same system that generates your monthly invoice, so the figures match your bill.

The dashboard displays:

A bar chart showing daily usage charges for your billing period
A sortable table breaking down usage by product, including total usage, billable usage, and cumulative costs
Ability to view previous billing periods

Usage data aligns to your billing cycle, not the calendar month. The total usage cost shown at the end of a completed billing period matches the usage overage charges on your corresponding invoice.

To access the dashboard, go to Manage Account > Billing > Billable Usage.

Budget alerts

Budget alerts allow you to set dollar-based thresholds for your account-level usage spend. You receive an email notification when your projected monthly spend reaches your configured threshold, giving you proactive visibility into your bill before month-end.

To configure a budget alert:

Go to Manage Account > Billing > Billable Usage.
Select Set Budget Alert.
Enter a budget threshold amount greater than $0.
Select Create.

Alternatively, configure alerts via Notifications > Add > Budget Alert.

You can create multiple budget alerts at different dollar amounts. The notifications system automatically deduplicates alerts if multiple thresholds trigger at the same time. Budget alerts are calculated daily based on your usage trends and fire once per billing cycle when your projected spend first crosses your threshold.

Both features are available to Pay-as-you-go accounts with usage-based products (Workers, R2, Images, etc.). Enterprise contract accounts are not supported.

For more information, refer to the Usage based billing documentation.

Workers - WebSocket binary messages now delivered as Blob by default

Tue, 21 Apr 2026 00:00:00 GMT

Binary frames received on a WebSocket are now delivered to the message event as Blob ↗︎ objects by default. This matches the WebSocket specification ↗︎ and standard browser behavior. Previously, binary frames were always delivered as ArrayBuffer ↗︎. The binaryType property on WebSocket controls the delivery type on a per-WebSocket basis.

This change has been active for Workers with compatibility dates on or after 2026-03-17, via the websocket_standard_binary_type compatibility flag. We should have documented this change when it shipped but didn't. We're sorry for the trouble that caused. If your Worker handles binary WebSocket messages and assumes event.data is an ArrayBuffer, the frames will arrive as Blob instead, and a naive instanceof ArrayBuffer check will silently drop every frame.

To opt back into ArrayBuffer delivery, assign binaryType before calling accept(). This works regardless of the compatibility flag:

const resp = await fetch("https://example.com", {
	headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery for this WebSocket.
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
	if (typeof event.data === "string") {
		// Text frame.
	} else {
		// event.data is an ArrayBuffer because we set binaryType above.
	}
});

If you are not ready to migrate and want to keep ArrayBuffer as the default for all WebSockets in your Worker, add the no_websocket_standard_binary_type flag to your Wrangler configuration file.

This change has no effect on the Durable Object hibernatable WebSocket webSocketMessage handler, which continues to receive binary data as ArrayBuffer.

For more information, refer to WebSockets binary messages.

Cloudflare One, Gateway - Network session analytics dashboard

Mon, 20 Apr 2026 00:00:00 GMT

The new Network session analytics dashboard is now available in Cloudflare One. This dashboard provides visibility into your network traffic patterns, helping you understand how traffic flows through your Cloudflare One infrastructure.

What you can do with Network session analytics

Analyze geographic distribution: View a world map showing where your network traffic originates, with a list of top locations by session count.
Monitor key metrics: Track session count, total bytes transferred, and unique users.
Identify connection issues: Analyze connection close reasons to troubleshoot network problems.
Review protocol usage: See which network protocols (TCP, UDP, ICMP) are most used.

Dashboard features

Summary metrics: Session count, bytes total, and unique users
Traffic by location: World map visualization and location list with top traffic sources
Top protocols: Breakdown of TCP, UDP, ICMP, and ICMPv6 traffic
Connection close reasons: Insights into why sessions terminated (client closed, origin closed, timeouts, errors)

How to access

Log in to Cloudflare One ↗︎.
Go to Zero Trust > Insights > Dashboards.
Select Network session analytics.

For more information, refer to the Network session analytics documentation.

Access - Homepage and sign-out for MCP server portals

Fri, 17 Apr 2026 00:00:00 GMT

MCP server portals display a homepage when users visit the portal domain in a browser.

The homepage shows:

The portal name and organization branding
The MCP endpoint URL with a copy button
Per-client connection instructions for Claude Desktop, Workers AI Playground, OpenCode, Windsurf, and other MCP clients

Authenticated users see their email address and a Sign out button. Selecting Sign out revokes all portal-level OAuth grants, deletes upstream server OAuth states, and redirects through Cloudflare Access logout. A confirmation page shows a summary of the revoked sessions.

For more information, refer to MCP server portals.

Access - Independent MFA for Access applications

Wed, 15 Apr 2026 00:00:00 GMT

Cloudflare Access now supports independent multi-factor authentication (MFA), allowing you to enforce MFA requirements without relying on your identity provider (IdP). With per-application and per-policy configuration, you can enforce stricter authentication methods like hardware security keys on sensitive applications without requiring them across your entire organization. This reduces the risk of MFA fatigue for your broader user population while adding additional security where it matters most.

This feature also addresses common gaps in IdP-based MFA, such as inconsistent MFA policies across different identity providers or the need for additional security layers beyond what the IdP provides.

Independent MFA supports the following authenticator types:

Authenticator application — Time-based one-time passwords (TOTP) using apps like Google Authenticator, Microsoft Authenticator, or Authy.
Security key — Hardware security keys such as YubiKeys.
Biometrics — Built-in device authenticators including Apple Touch ID, Apple Face ID, and Windows Hello.

Configuration levels

You can configure MFA requirements at three levels:

Level	Description
Organization	Enforce MFA by default for all applications in your account.
Application	Require or turn off MFA for a specific application.
Policy	Require or turn off MFA for users who match a specific policy.

Settings at lower levels (policy) override settings at higher levels (organization), giving you granular control over MFA enforcement.

User enrollment

Users enroll their authenticators through the App Launcher. To help with onboarding, administrators can share a direct enrollment link: <your-team-name>.cloudflareaccess.com/AddMfaDevice.

To get started with Independent MFA, refer to Independent MFA.

Cloudflare One - New, streamlined creation experience for Access Applications and Gateway Policies

Wed, 15 Apr 2026 00:00:00 GMT

The Cloudflare One dashboard now features redesigned builders for two core workflows: creating Gateway policies and configuring self-hosted Access applications.

Gateway rule builder

The Gateway rule builder now features a redesigned user experience, bringing it in line with the Access policy builder experience. Improvements include:

Streamlined UX with clearer states and improved user interactions
Wirefilter editing for viewing and editing Gateway rules directly from wirefilter expressions
Preview state to review the impact of your policy in a simple graphic

For more information, refer to Traffic policies.

Access application builder for self-hosted apps

The self-hosted Access application builder now offers a simplified creation workflow with fewer steps from setup to save. Improvements include:

New application selection experience that makes choosing the right application type before you begin easier.
Streamlined creation flow with fewer clicks to build and save an application
Inline policy creation for building Access policies directly within the application creation flow
Preview state to understand how your policies enforce user access before saving

For more information, refer to self-hosted applications.

Digital Experience Monitoring - Last seen timestamp for Cloudflare One Client devices is more consistent

Wed, 15 Apr 2026 00:00:00 GMT

The last seen timestamp for Cloudflare One Client devices is now more consistent across the dashboard. IT teams will see more consistent information about the most recent client event between a device and Cloudflare's network.

Data Loss Prevention - DLP account-level settings

Tue, 14 Apr 2026 12:00:00 GMT

Account-level DLP settings are now available in Cloudflare One. You can now configure advanced DLP settings at the account level, including OCR, AI context analysis, and payload masking. This provides consistent enforcement across all DLP profiles and simplifies configuration management.

Key changes:

Consistent enforcement: Settings configured at the account level apply to all DLP profiles
Simplified migration: Settings enabled on any profile are automatically migrated to account level
Deprecation notice: Profile-level advanced settings will be deprecated in a future release

Migration details:

During the migration period, if a setting is enabled on any profile, it will automatically be enabled at the account level. This means profiles that previously had a setting disabled may now have it enabled if another profile in the account had it enabled.

Settings are evaluated using OR logic - a setting is enabled if it is turned on at either the account level or the profile level. However, profile-level settings cannot be enabled when the account-level setting is off.

For more details, refer to the DLP settings documentation.

Cloudflare One - Introducing Cloudflare Mesh

Tue, 14 Apr 2026 00:00:00 GMT

Cloudflare Mesh is now available (blog post ↗︎). Mesh connects your services and devices with post-quantum encrypted networking, allowing you to route traffic privately between servers, laptops, and phones over TCP, UDP, and ICMP.

What Cloudflare Mesh does

Assigns a private Mesh IP to every enrolled device and node.
Enables any participant to reach any other participant by IP — including client-to-client, without deploying any infrastructure.
Supports CIDR routes for subnet routing through Mesh nodes.
Supports high availability with active-passive replicas for nodes with routes.
All traffic flows through Cloudflare, so Gateway network policies, device posture checks, and access rules apply to every connection.

What changed

WARP Connector is now Cloudflare Mesh. Existing WARP Connectors are now called mesh nodes. All existing deployments continue to work — no migration required.
Peer-to-peer connectivity is now called Mesh connectivity and is part of the Cloudflare Mesh documentation.
Mesh node limit increased from 10 to 50 per account.
New dashboard experience ↗︎ at Networking > Mesh with an interactive network map, node management, route configuration, diagnostics, and a setup wizard.

Get started

Refer to the Cloudflare Mesh documentation to set up your first Mesh network.

Data Loss Prevention - Detect Cloudflare API tokens with DLP

Tue, 14 Apr 2026 00:00:00 GMT

The Credentials and Secrets DLP profile now includes three new predefined entries for detecting Cloudflare API credentials:

Entry name	Token prefix	Detects
Cloudflare User API Key	`cfk_`	User-scoped API keys
Cloudflare User API Token	`cfut_`	User-scoped API tokens
Cloudflare Account Owned API Token	`cfat_`	Account-scoped API tokens

These detections target the new Cloudflare API credential format, which uses a structured prefix and a CRC32 checksum suffix. The identifiable prefix makes it possible to detect leaked credentials with high confidence and low false positive rates — no surrounding context such as Authorization: Bearer headers is required.

Credentials generated before this format change will not be matched by these entries.

How to enable Cloudflare API token detections

In the Cloudflare dashboard ↗︎, go to Zero Trust > DLP > DLP Profiles.
Select the Credentials and Secrets profile.
Turn on one or more of the new Cloudflare API token entries.
Use the profile in a Gateway HTTP policy to log or block traffic containing these credentials.

Example policy:

Selector	Operator	Value	Action
DLP Profile	in	Credentials and Secrets	Block

You can also enable individual entries to scope detection to specific credential types — for example, enabling Account Owned API Token detection without enabling User API Key detection.

For more information, refer to predefined DLP profiles.

Gateway, Data Loss Prevention - Configure how sensitive data appears in DLP payload logs

Tue, 14 Apr 2026 00:00:00 GMT

You can now configure how sensitive data matches are displayed in your DLP payload match logs — giving your incident response team the context they need to validate alerts without compromising your security posture.

To get started, go to the Cloudflare dashboard ↗︎, select Zero Trust > Data loss prevention > DLP settings and find the Payload log masking card.

Previously, all DLP payload logs used a single masking mode that obscured matched data entirely and hid the original character count, making it difficult to distinguish true positives from false positives. This update introduces three options:

Full Mask (default): Masks the match while preserving character count and visual formatting (for example, ***-**-**** for a Social Security Number). This is an improvement over the previous default, which did not preserve character count.
Partial Mask: Reveals 25% of the matched content while masking the remainder (for example, ***-**-6789).
Clear Text: Stores the full, unmasked violation for deep investigation (for example, 123-45-6789).

Important: The masking level you select is applied at detection time, before the payload is encrypted. This means the chosen format is what your team will see after decrypting the log with your private key — the existing encryption workflow is unchanged.

Applies to all enabled detections: When a masking level other than Full Mask is selected, it applies to all sensitive data matches found within a payload window — not just the match that triggered the policy. Any data matched by your enabled DLP detection entries will be masked at the selected level.

For more information, refer to DLP logging options.

Workers - Local Explorer for local resource data

Mon, 13 Apr 2026 00:00:00 GMT

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

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

Supported resources

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

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

OpenAPI-powered REST API

Local Explorer exposes a REST API at /cdn-cgi/local/explorer/api that provides programmatic access to the same operations available in the browser. The root endpoint returns an OpenAPI specification ↗︎ describing all available endpoints, parameters, and response formats.

curl http://localhost:8787/cdn-cgi/local/explorer/api

Point an AI coding agent at /cdn-cgi/local/explorer/api and it can discover and interact with your local resources without manual setup. This enables iterative development loops where an agent can populate test data in KV or D1, inspect Durable Object state, trigger Workflow runs, or upload files to R2.

For more details, refer to the Local Explorer documentation.

Browser Isolation - Canvas Remoting optimizes performance for productivity applications

Fri, 10 Apr 2026 00:00:00 GMT

Remote Browser Isolation now supports Canvas Remoting, improving performance for HTML5 Canvas applications by sending vector draw commands instead of rasterized bitmaps.

Key improvements

10x bandwidth reduction: Microsoft Word and other Office apps use 90% less bandwidth
Smooth performance: Google Sheets maintains consistent 30fps rendering
Responsive terminals: Web-based development environments and AI notebooks work in real-time
Zero configuration: Enabled by default for all Browser Isolation customers

How it works

Instead of sending rasterized bitmaps for every Canvas update, Browser Isolation now:

Captures Canvas draw commands at the source
Converts them to lightweight vector instructions
Renders Canvas content on the client

This reduces bandwidth from hundreds of kilobytes per second to tens of kilobytes per second.

Managing Canvas Remoting

To temporarily disable for troubleshooting:

Right-click the isolated webpage background
Select Disable Canvas Remoting
Re-enable the same way by selecting Enable Canvas Remoting

Limitations

Currently supports 2D Canvas contexts only. WebGL and 3D graphics applications continue using bitmap rendering. For more information, refer to Canvas Remoting.

CASB - Send CASB posture finding instances with webhooks

Thu, 09 Apr 2026 00:00:00 GMT

You can now use CASB webhooks in Cloudflare One to send posture finding instances to external systems such as chat platforms, ticketing systems, SIEMs, SOAR tools, and custom automation services.

This gives security teams a simple way to route CASB posture findings into the tools and workflows they already use for triage and response.

To get started, go to Integrations > Webhooks in the Cloudflare One dashboard to create a webhook destination. After you configure a webhook, open a posture finding instance and select Send webhook to send it.

Key capabilities

Flexible authentication — Configure destinations using None, Basic Auth, Bearer Auth, Static Headers, or HMAC-Signing.
Built-in testing — Use Test delivery to send a test request before sending a live finding instance.
Posture finding workflows — Send posture finding instances directly from the finding details workflow in Cloud & SaaS findings.
HTTPS destinations — Configure webhook destinations with public https:// URLs.

Learn more

Configure CASB webhooks in Cloudflare.
Learn how to manage findings in Cloudflare.

CASB webhooks are now available in Cloudflare One.

Workers - Relaxed simultaneous connection limiting for Workers

Thu, 09 Apr 2026 00:00:00 GMT

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

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

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

This means Workers can now have many more connections open at the same time without queueing, as long as no more than six are waiting for their initial response. This eliminates the Response closed due to connection limit exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks.

Previously, the runtime used a deadlock avoidance algorithm that watched each open connection for I/O activity. If all six connections appeared idle — even momentarily — the runtime would cancel the least-recently-used connection to make room for new requests. In practice, this heuristic was fragile. For example, when a response used Content-Encoding: gzip, the runtime's internal decompression created brief gaps between read and write operations. During these gaps, the connection appeared stalled despite being actively read by the Worker. If multiple connections hit these gaps at the same time, the runtime could spuriously cancel a connection that was working correctly. By only counting connections during the waiting-for-headers phase — where the runtime is fully in control and there is no ambiguity about whether the connection is active — this class of bug is eliminated entirely.

Before: Connections could be canceled during brief internal pauses

After: Connections complete normally regardless of internal pauses

Risk Score - User risk scoring for high risk browsing activity

Wed, 08 Apr 2026 00:00:00 GMT

Cloudflare One's User Risk Scoring now incorporates direct signals from Gateway DNS traffic patterns. This update allows security teams to automatically elevate a user's risk score when they visit high-risk or malicious domains, providing a more holistic view of internal threats.

Why this matters

Browsing activity is a primary indicator of potential compromise. By tying Gateway DNS logs to specific users, administrators can now flag individuals interacting with:

Security threats: Domains associated with malware, phishing, or command-and-control (C2) centers.
High-risk content: Categories such as questionable content or violence that may violate corporate compliance.

Even if a Gateway policy is set to Block the traffic, the interaction is still captured as a "hit" to ensure the user's risk profile reflects the attempted activity.

New risk behaviors

Two new behaviors are now available in the dashboard:

Suspicious Security Domain Visited: Triggers when a user visits a domain in the security threats or security risk categories.
High risk domain visited: Triggers when a user visits domains categorized as questionable content, violence, or CIPA.

To learn more and get started, refer to the User Risk Scoring documentation.

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.3.851.0)

Tue, 07 Apr 2026 15:56:36 GMT

A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

The next stable release for Windows will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

Fixed an issue causing Windows client tunnel interface initialization failure which prevented clients from establishing a tunnel for connection.
Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
Added monitoring for tunnel statistics collection timeouts.
Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
Fixed packet capture failing on tunnel interface when the tunnel interface is renamed by SCCM VPN boundary support.
Fixed unnecessary registration deletion caused by RDP connections in multi-user mode.
Fixed increased tunnel interface start-up time due to a race between duplicate address detection (DAD) and disabling NetBT.
Fixed tunnel failing to connect when the system DNS search list contains unexpected characters.
Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.
Fixed an issue where degraded Windows Management Instrumentation (WMI) state could put the client in a failed connection state loop during initialization.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 version KB5062553 or higher for resolution. This warning will be omitted from future release notes. This Windows update was released in July 2025.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later. This warning will be omitted from future release notes. This Microsoft Security Intelligence update was released in May 2025.
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, reconnect the client by selecting Disconnect and then Connect in the client user interface.

Email security - User Submission Triage Status Tracking

Tue, 07 Apr 2026 09:00:00 GMT

Cloudflare Email security now supports Triage Status Tracking for User Submissions. This enhancement gives SOC teams a streamlined way to track, manage, and prioritize user-submitted emails directly within the Cloudflare One dashboard.

The User Submissions table now includes a Status column with three states: Unreviewed (new submissions awaiting triage), Reviewed (submissions assessed by the SOC team), and Escalated (submissions escalated to team submissions for further investigation). Analysts can quickly update statuses and filter the table to focus on what needs attention.
SOC teams can now organize their triage workflows, avoid duplicate reviews, and make sure critical threats get escalated for deeper investigation—bringing order to the chaos of high-volume submission management.

Triage Status Tracking is automatically available for all Email security customers using the user submissions feature. No additional configuration is required; customers just need to make sure user submissions are being sent to their user submission aliases.

This applies to all Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Link aggregation (LACP) support for Cloudflare One Appliance

Tue, 07 Apr 2026 00:00:00 GMT

Cloudflare One Appliance now supports Link Aggregation Control Protocol (LACP), allowing you to bundle up to six physical LAN ports into a single logical interface. Link aggregation increases available bandwidth and eliminates single points of failure on the LAN side of the appliance.

This feature is available in beta on physical appliance hardware with the latest OS. No entitlement is required.

To configure a Link Aggregation Group, refer to Configure link aggregation groups.

Workers - WebSockets now automatically reply to Close frames

Tue, 07 Apr 2026 00:00:00 GMT

The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The readyState transitions to CLOSED before the close event fires. This matches the WebSocket specification ↗︎ and standard browser behavior.

This change is enabled by default for Workers using compatibility dates on or after 2026-04-07 (via the web_socket_auto_reply_to_close compatibility flag). Existing code that manually calls close() inside the close event handler will continue to work — the call is silently ignored when the WebSocket is already closed.

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
	// readyState is already CLOSED — no need to call server.close().
	console.log(server.readyState); // WebSocket.CLOSED
	console.log(event.code); // 1000
	console.log(event.wasClean); // true
});

Half-open mode for WebSocket proxying

The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass { allowHalfOpen: true } to accept():

const [client, server] = Object.values(new WebSocketPair());

server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
	// readyState is still CLOSING here, giving you time
	// to coordinate the close on the other side.
	console.log(server.readyState); // WebSocket.CLOSING

	// Manually close when ready.
	server.close(event.code, "done");
});

For more information, refer to WebSockets Close behavior.

Email security - DANE Support for MX Deployments

Mon, 06 Apr 2026 09:00:00 GMT

Cloudflare Email Security now supports DANE (DNS-based Authentication of Named Entities) for MX deployments. This enhancement strengthens email transport security by enabling DNSSEC-backed certificate verification for our regional MX records.

Regional MX hostnames now publish DANE TLSA records backed by DNSSEC, enabling DANE-capable SMTP senders to cryptographically validate certificate identities before establishing TLS connections—moving beyond opportunistic encryption to verified encrypted delivery.
DANE support is automatically available for all customers using regional MX deployments. No additional configuration is required; DANE-capable mail infrastructure will automatically validate MX certificates using the published records.

This applies to all Email Security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare Fundamentals, Cloudflare One, Gateway, Organizations - Organizations is now in public beta for enterprises

Mon, 06 Apr 2026 00:00:00 GMT

We're announcing the public beta of Organizations for enterprise customers, a new top-level Cloudflare container that lets Cloudflare customers manage multiple accounts, members, analytics, and shared policies from one centralized location.

What's New

Organizations [BETA]: Organizations are a new top-level container for centrally managing multiple accounts. Each Organization supports up to 500 accounts and 5000 zones, giving larger teams a single place to administer resources at scale.

Self-serve onboarding: Enterprise customers can create an Organization in the dashboard and assign accounts where they are already Super Administrators.

Centralized Account Management: At launch, every Organization member has the Organization Super Admin role. Organization Super Admins can invite other users and manage any child account under the Organization implicitly. Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management. Implicit access: Members of an Organization automatically receive Super Administrator permissions across child accounts, removing the need for explicit membership on each account. Additional Org-level roles will be available over the course of the year.

Unified analytics: View, filter, and download aggregate HTTP analytics across all Organization child accounts from a single dashboard for centralized visibility into traffic patterns and security events.

Terraform provider support: Manage Organizations with infrastructure as code from day one. Provision organizations, assign accounts, and configure settings programmatically with the Cloudflare Terraform provider ↗︎.

Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

For more info:

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.3.846.0)

Thu, 02 Apr 2026 16:28:33 GMT

A new GA release for the macOS Cloudflare One Client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

The next stable release for macOS will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
Added monitoring for tunnel statistics collection timeouts.
Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.3.846.0)

Thu, 02 Apr 2026 15:39:10 GMT

A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

The next stable release for Linux will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
Added monitoring for tunnel statistics collection timeouts.
Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

Access - Session management for MCP server portals

Thu, 02 Apr 2026 00:00:00 GMT

MCP server portals support in-session management of upstream MCP server connections. Users can return to the server selection page at any time to enable or disable servers, reauthenticate, or change which data a server has access to — all without leaving their MCP client.

To return to the server selection page, ask your AI agent with a prompt like "take me back to the server selection page." The portal responds with an authorization URL via MCP elicitation ↗︎ that you open in your browser:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

From the server selection page you can:

Enable or disable servers — Toggle individual upstream MCP servers on or off. Disabling a server removes its tools from the active session, which reduces context window usage.
Log out and reauthenticate — Log out of a server and log back in to change which data the server has access to, or to reauthenticate with different permissions.

Users can also enable or disable a server inline by asking their AI agent directly, for example "enable the wiki server" or "disable my Jira server."

The portal also automatically prompts connected users to authorize new servers when an admin adds them to the portal. This requires the use of managed OAuth.

For more information, refer to Manage portal sessions.

Cloudflare One, Access, Gateway - Logs UI refresh

Wed, 01 Apr 2026 00:00:00 GMT

Access authentication logs and Gateway activity logs (DNS, Network, and HTTP) now feature a refreshed user interface that gives you more flexibility when viewing and analyzing your logs.

The updated UI includes:

Filter by field - Select any field value to add it as a filter and narrow down your results.
Customizable fields - Choose which fields to display in the log table. Querying for fewer fields improves log loading performance.
View details - Select a timestamp to view the full details of a log entry.
Switch to classic view - Return to the previous log viewer interface if needed.

For more information, refer to Access authentication logs and Gateway activity logs.

Workers - Deploy Hooks are now available for Workers Builds

Wed, 01 Apr 2026 00:00:00 GMT

Workers Builds now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request.

Each Deploy Hook is a unique URL tied to a specific branch. Send it a POST and your Worker builds and deploys.

curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/<DEPLOY_HOOK_ID>"

To create one, go to Workers & Pages > your Worker > Settings > Builds > Deploy Hooks.

Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a Cron Trigger can rebuild your project on a schedule:

export default {
	async scheduled(event, env, ctx) {
		ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
	},
};

export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
    ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
  },
} satisfies ExportedHandler<Env>;

You can also use Deploy Hooks to rebuild when your CMS publishes new content or deploy from a Slack slash command.

Built-in optimizations

Automatic deduplication: If a Deploy Hook fires multiple times before the first build starts running, redundant builds are automatically skipped. This keeps your build queue clean when webhooks retry or CMS events arrive in bursts.
Last triggered: The dashboard shows when each hook was last triggered.
Build source: Your Worker's build history shows which Deploy Hook started each build by name.

Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account. For all limits, see Limits & pricing.

To get started, read the Deploy Hooks documentation.

Workers - New L4 transport telemetry fields in Workers

Wed, 01 Apr 2026 00:00:00 GMT

Three new properties are now available on request.cf in Workers that expose Layer 4 transport telemetry from the client connection. These properties let your Worker make decisions based on real-time connection quality signals — such as round-trip time and data delivery rate — without requiring any client-side changes.

Previously, this telemetry was only available via the Server-Timing: cfL4 response header. These new properties surface the same data directly in the Workers runtime, so you can use it for routing, logging, or response customization.

New properties

Property	Type	Description
`clientTcpRtt`	number \| undefined	The smoothed TCP round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for TCP connections (HTTP/1, HTTP/2). For example, `22`.
`clientQuicRtt`	number \| undefined	The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only present for QUIC connections (HTTP/3). For example, `42`.
`edgeL4`	Object \| undefined	Layer 4 transport statistics. Contains `deliveryRate` (number) — the most recent data delivery rate estimate for the connection, in bytes per second. For example, `123456`.

Example: Log connection quality metrics

export default {
  async fetch(request) {
    const cf = request.cf;

    const rtt = cf.clientTcpRtt ?? cf.clientQuicRtt ?? 0;
    const deliveryRate = cf.edgeL4?.deliveryRate ?? 0;
    const transport = cf.clientTcpRtt ? "TCP" : "QUIC";

    console.log(`Transport: ${transport}, RTT: ${rtt}ms, Delivery rate: ${deliveryRate} B/s`);

    const headers = new Headers(request.headers);
    headers.set("X-Client-RTT", String(rtt));
    headers.set("X-Delivery-Rate", String(deliveryRate));

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Workers Runtime APIs: Request.

Workers - New RFC 9440 mTLS certificate fields in Workers

Fri, 27 Mar 2026 00:00:00 GMT

Four new fields are now available on request.cf.tlsClientAuth in Workers for requests that include a mutual TLS (mTLS) client certificate. These fields encode the client certificate and its intermediate chain in RFC 9440 ↗︎ format — the same standard format used by the Client-Cert and Client-Cert-Chain HTTP headers — so your Worker can forward them directly to your origin without any custom parsing or encoding logic.

New fields

Field	Type	Description
`certRFC9440`	String	The client leaf certificate in RFC 9440 format (`:base64-DER:`). Empty if no client certificate was presented.
`certRFC9440TooLarge`	Boolean	`true` if the leaf certificate exceeded 10 KB and was omitted from `certRFC9440`.
`certChainRFC9440`	String	The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediates were sent or if the chain exceeded 16 KB.
`certChainRFC9440TooLarge`	Boolean	`true` if the intermediate chain exceeded 16 KB and was omitted from `certChainRFC9440`.

Example: forwarding client certificate headers to your origin

export default {
  async fetch(request) {
    const tls = request.cf.tlsClientAuth;

    // Only forward if cert was verified and chain is complete
    if (!tls || !tls.certVerified || tls.certRevoked || tls.certChainRFC9440TooLarge) {
      return new Response("Unauthorized", { status: 401 });
    }

    const headers = new Headers(request.headers);
    headers.set("Client-Cert", tls.certRFC9440);
    headers.set("Client-Cert-Chain", tls.certChainRFC9440);

    return fetch(new Request(request, { headers }));
  },
};

For more information, refer to Client certificate variables and Mutual TLS authentication.

Access - Code Mode for MCP server portals

Thu, 26 Mar 2026 00:00:00 GMT

MCP server portals support Code Mode MCP server patterns, a technique that reduces context window usage by replacing individual tool definitions with a single code execution tool. Code Mode is turned on by default on all portals.

To turn it off, edit the portal in Access controls > AI controls and turn off Code Mode under Basic information.

When Code Mode is active, the portal exposes a single code tool instead of listing every tool from every upstream MCP server. The connected AI agent writes JavaScript that calls typed codemode.* methods for each upstream tool. The generated code runs in an isolated Dynamic Worker environment, keeping authentication credentials and environment variables out of the model context.

To use Code Mode, append ?codemode=search_and_execute to your portal URL when connecting from an MCP client:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

For more information, refer to Code Mode.

Access - Context optimization for MCP server portals

Thu, 26 Mar 2026 00:00:00 GMT

MCP server portals support two context optimization options that reduce how many tokens tool definitions consume in the model's context window. Both options are activated by appending the optimize_context query parameter to the portal URL.

`minimize_tools`

Strips tool descriptions and input schemas from all upstream tools, leaving only their names. The portal exposes a special query tool that agents use to retrieve full definitions on demand. This provides up to 5x savings in token usage.

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

`search_and_execute`

Hides all upstream tools and exposes only two tools: query and execute. The query tool searches and retrieves tool definitions. The execute tool runs the upstream tools in an isolated Dynamic Worker environment. This reduces the initial token cost to a small constant, regardless of how many tools are available through the portal.

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

For more information, refer to Optimize context.

Data Loss Prevention - Streaming ZIP file scanning removes per-file size limits

Thu, 26 Mar 2026 00:00:00 GMT

DLP now processes ZIP files using a streaming handler that scans archive contents element-by-element as data arrives. This removes previous file size limitations and improves memory efficiency when scanning large archives.

Microsoft Office documents (DOCX, XLSX, PPTX) also benefit from this improvement, as they use ZIP as a container format.

This improvement is automatic — no configuration changes are required.

Data Loss Prevention - Detect and sanitize HAR files

Wed, 25 Mar 2026 00:00:00 GMT

HTTP Archive (HAR) files are used by engineering and support teams to capture and share web traffic logs for troubleshooting. However, these files routinely contain highly sensitive data — including session cookies, authorization headers, and other credentials — that can pose a significant risk if uploaded to third-party services without being reviewed or cleaned first.

Gateway now includes a predefined DLP profile called Unsanitized HAR that detects HAR files in HTTP traffic. You can use this profile in a Gateway HTTP policy to either block HAR file uploads entirely or redirect users to a sanitization tool before allowing the upload to proceed.

How to configure a HAR file policy

In the Cloudflare dashboard ↗︎, go to Zero Trust > Traffic policies > Firewall Policies > HTTP and create a new HTTP policy using the DLP Profile selector:

Selector	Operator	Value	Action
DLP Profile	in	Unsanitized HAR

Then choose one of the following actions:

Block: Prevents the upload of any HAR file that has not been sanitized by Cloudflare's sanitizer. Use this for strict environments where HAR file sharing must be disallowed entirely.
Block with Gateway Redirect: Intercepts the upload and redirects the user to https://har-sanitizer.pages.dev/, where they can sanitize the file. Once sanitized, the user can re-upload the clean file and proceed with their workflow.

Sanitized HAR recognition

HAR files processed by the Cloudflare HAR sanitizer receive a tamper-evident sanitized marker. DLP recognizes this marker and will not re-trigger the policy on a file that has already been sanitized and has not been modified since. If a previously sanitized file is edited, it will be treated as unsanitized and flagged again.

Visibility in Gateway logs

Gateway logs will reflect whether a detected HAR file was classified as Unsanitized or Sanitized, giving your security team full visibility into HAR file activity across your organization.

For more information, refer to predefined DLP profiles.

Workers - Declare required secrets in your Wrangler configuration

Wed, 25 Mar 2026 00:00:00 GMT

The new secrets configuration property lets you declare the secret names your Worker requires in your Wrangler configuration file. Required secrets are validated during local development and deploy, and used as the source of truth for type generation.

{
	"secrets": {
		"required": ["API_KEY", "DB_PASSWORD"],
	},
}

[secrets]
required = [ "API_KEY", "DB_PASSWORD" ]

Local development

When secrets is defined, wrangler dev and vite dev load only the keys listed in secrets.required from .dev.vars or .env/process.env. Additional keys in those files are excluded. If any required secrets are missing, a warning is logged listing the missing names.

Type generation

wrangler types generates typed bindings from secrets.required instead of inferring names from .dev.vars or .env. This lets you run type generation in CI or other environments where those files are not present. Per-environment secrets are supported — the aggregated Env type marks secrets that only appear in some environments as optional.

Deploy

wrangler deploy and wrangler versions upload validate that all secrets in secrets.required are configured on the Worker before the operation succeeds. If any required secrets are missing, the command fails with an error listing which secrets need to be set.

For more information, refer to the secrets configuration property reference.

Gateway - OIDC Claims filtering now available in Gateway Firewall, Resolver, and Egress policies

Tue, 24 Mar 2026 00:00:00 GMT

Cloudflare Gateway now supports OIDC Claims as a selector in Firewall, Resolver, and Egress policies. Administrators can use custom OIDC claims from their identity provider to build fine-grained, identity-based traffic policies across all Gateway policy types.

With this update, you can:

Filter traffic in DNS, HTTP, and Network firewall policies based on OIDC claim values.
Apply custom resolver policies to route DNS queries to specific resolvers depending on a user's OIDC claims.
Control egress policies to assign dedicated egress IPs based on OIDC claim attributes.

For example, you can create a policy that routes traffic differently for users with department=engineering in their OIDC claims, or restrict access to certain destinations based on a user's role claim.

To get started, configure custom OIDC claims on your identity provider and use the OIDC Claims selector in the Gateway policy builder.

For more information, refer to Identity-based policies.

Workers - Dynamic Workers, now in open beta

Tue, 24 Mar 2026 00:00:00 GMT

Dynamic Workers are now in open beta ↗︎ for all paid Workers users. You can now have a Worker spin up other Workers, called Dynamic Workers, at runtime to execute code on-demand in a secure, sandboxed environment. Dynamic Workers start in milliseconds, making them well suited for fast, secure code execution at scale.

Use Dynamic Workers for

Code Mode: LLMs are trained to write code. Run tool-calling logic written in code instead of stepping through many tool calls, which can save up to 80% in inference tokens and cost.
AI agents executing code: Run code for tasks like data analysis, file transformation, API calls, and chained actions.
Running AI-generated code: Run generated code for prototypes, projects, and automations in a secure, isolated sandboxed environment.
Fast development and previews: Load prototypes, previews, and playgrounds in milliseconds.
Custom automations: Create custom tools on the fly that execute a task, call an integration, or automate a workflow.

Executing Dynamic Workers

Dynamic Workers support two loading modes:

load(code) — for one-time code execution (equivalent to calling get() with a null ID).
get(id, callback) — caches a Dynamic Worker by ID so it can stay warm across requests. Use this when the same code will receive subsequent requests.

export default {
	async fetch(request, env) {
		const worker = env.LOADER.load({
			compatibilityDate: "2026-01-01",
			mainModule: "src/index.js",
			modules: {
				"src/index.js": `
					export default {
						fetch() {
							return new Response("Hello from a dynamic Worker");
						},
					};
				`,
			},
			// Block all outbound network access from the Dynamic Worker.
			globalOutbound: null,
		});

		return worker.getEntrypoint().fetch(request);
	},
};

export default {
	async fetch(request: Request, env: Env): Promise<Response> {
		const worker = env.LOADER.load({
			compatibilityDate: "2026-01-01",
			mainModule: "src/index.js",
			modules: {
				"src/index.js": `
					export default {
						fetch() {
							return new Response("Hello from a dynamic Worker");
						},
					};
				`,
			},
			// Block all outbound network access from the Dynamic Worker.
			globalOutbound: null,
		});

		return worker.getEntrypoint().fetch(request);
	},
};

Helper libraries for Dynamic Workers

Here are 3 new libraries to help you build with Dynamic Workers:

@cloudflare/codemode ↗︎: Replace individual tool calls with a single code() tool, so LLMs write and execute TypeScript that orchestrates multiple API calls in one pass.
@cloudflare/worker-bundler ↗︎: Resolve npm dependencies and bundle source files into ready-to-load modules for Dynamic Workers, all at runtime.
@cloudflare/shell ↗︎: Give your agent a virtual filesystem inside a Dynamic Worker with persistent storage backed by SQLite and R2.

Try it out

Dynamic Workers Starter

Use this starter ↗︎ to deploy a Worker that can load and execute Dynamic Workers.

Dynamic Workers Playground

Deploy the Dynamic Workers Playground ↗︎ to write or import code, bundle it at runtime with @cloudflare/worker-bundler, execute it through a Dynamic Worker, and see real-time responses and execution logs.

For the full API reference and configuration options, refer to the Dynamic Workers documentation.

Pricing

Dynamic Workers pricing is based on three dimensions: Dynamic Workers created daily, requests, and CPU time.

	Included	Additional usage
Dynamic Workers created daily	1,000 unique Dynamic Workers per month	+$0.002 per Dynamic Worker per day
Requests ¹	10 million per month	+$0.30 per million requests
CPU time ¹	30 million CPU milliseconds per month	+$0.02 per million CPU milliseconds

¹ Uses Workers Standard rates and will appear as part of your existing Workers bill, not as separate Dynamic Workers charges.

Note: Dynamic Workers requests and CPU time are already billed as part of your Workers plan and will count toward your Workers requests and CPU usage. The Dynamic Workers created daily charge is not yet active — you will not be billed for the number of Dynamic Workers created at this time. Pricing information is shared in advance so you can estimate future costs.

Access - Managed OAuth for Cloudflare Access

Fri, 20 Mar 2026 00:00:00 GMT

Cloudflare Access supports managed OAuth, which allows non-browser clients — such as CLIs, AI agents, SDKs, and scripts — to authenticate with Access-protected applications using a standard OAuth 2.0 authorization code flow.

Previously, non-browser clients that attempted to access a protected application received a 302 redirect to a login page they could not complete. The established workaround was cloudflared access curl, which required installing additional tooling.

With managed OAuth, clients instead receive a 401 response with a WWW-Authenticate header that points to Access's OAuth discovery endpoints (RFC 8414 ↗︎ and RFC 9728 ↗︎). The client opens the end user's browser to the Access login page. The end user authenticates with their identity provider, and the client receives an OAuth access token for subsequent requests.

Access enforces the same policies as a browser login; the OAuth layer is a new transport mechanism, not a separate authentication path.

Managed OAuth can be enabled on any self-hosted Access application or MCP server portal. It is opt-in for existing applications to avoid interfering with those that run their own OAuth servers and rely on their own WWW-Authenticate headers.

To enable managed OAuth, go to Zero Trust > Access controls > Applications, edit the application, and turn on Managed OAuth under Advanced settings.

You can also enable it via the API by setting oauth_configuration.enabled to true on the Access applications endpoint.

For setup instructions, refer to Enable managed OAuth.

Access - Route MCP server portal traffic through Cloudflare Gateway

Fri, 20 Mar 2026 00:00:00 GMT

MCP server portals can now route traffic through Cloudflare Gateway for richer HTTP request logging and data loss prevention (DLP) scanning.

When Gateway routing is turned on, portal traffic appears in your Gateway HTTP logs. You can create Gateway HTTP policies with DLP profiles to detect and block sensitive data sent to upstream MCP servers.

To enable Gateway routing, go to Access controls > AI controls, edit the portal, and turn on Route traffic through Cloudflare Gateway under Basic information.

For more details, refer to Route traffic through Gateway.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Stream logs from multiple replicas of Cloudflare Tunnel simultaneously

Fri, 20 Mar 2026 00:00:00 GMT

In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all replicas of that tunnel and supports streaming logs from multiple replicas at once.

Previously, you could only stream logs from one replica at a time. With this update:

Replicas on the tunnel overview — All active replicas for the selected tunnel now appear on that tunnel's overview page under Connectors. Select any replica to stream its logs.
Multi-connector log streaming — Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to Cloudflare One ↗︎ and go to Networks > Connectors > Cloudflare Tunnels. Select View logs next to the tunnel you want to monitor.

For more information, refer to Tunnel log streams and Deploy replicas.

Cloudflare Tunnel, Workers - Manage Cloudflare Tunnels with Wrangler

Thu, 19 Mar 2026 00:00:00 GMT

You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.

Available commands:

wrangler tunnel create — Create a new remotely managed tunnel.
wrangler tunnel list — List all tunnels in your account.
wrangler tunnel info — Display details about a specific tunnel.
wrangler tunnel delete — Delete a tunnel.
wrangler tunnel run — Run a tunnel using the cloudflared daemon.
wrangler tunnel quick-start — Start a free, temporary tunnel without an account using Quick Tunnels.

Wrangler handles downloading and managing the cloudflared binary automatically. On first use, you will be prompted to download cloudflared to a local cache directory.

These commands are currently experimental and may change without notice.

To get started, refer to the Wrangler tunnel commands documentation.

Stream - Media Transformations binding for Workers

Wed, 18 Mar 2026 00:00:00 GMT

You can now use a Workers binding to transform videos with Media Transformations. This allows you to resize, crop, extract frames, and extract audio from videos stored anywhere, even in private locations like R2 buckets.

The Media Transformations binding is useful when you want to:

Transform videos stored in private or protected sources
Optimize videos and store the output directly back to R2 for re-use
Extract still frames for classification or description with Workers AI
Extract audio tracks for transcription using Workers AI

To get started, add the Media binding to your Wrangler configuration:

{
  "$schema": "./node_modules/wrangler/config-schema.json",
  "media": {
    "binding": "MEDIA"
  }
}

[media]
binding = "MEDIA"

Then use the binding in your Worker to transform videos:

export default {
	async fetch(request, env) {
		const video = await env.R2_BUCKET.get("input.mp4");

		const result = env.MEDIA.input(video.body)
			.transform({ width: 480, height: 270 })
			.output({ mode: "video", duration: "5s" });

		return await result.response();
	},
};

export default {
	async fetch(request, env) {
		const video = await env.R2_BUCKET.get("input.mp4");

		const result = env.MEDIA.input(video.body)
			.transform({ width: 480, height: 270 })
			.output({ mode: "video", duration: "5s" });

		return await result.response();
	},
};

Output modes include video for optimized MP4 clips, frame for still images, spritesheet for multiple frames, and audio for M4A extraction.

For more information, refer to the Media Transformations binding documentation.

Email security - Unlimited result paging in Investigations

Sun, 15 Mar 2026 16:00:00 GMT

Investigations now support unlimited result paging in both the dashboard and the API, removing the previous 1,000-record cap. Security teams can page through complete result sets when searching across large mail volumes, giving SOC analysts and automated workflows deeper visibility for forensics and threat hunting.

In the dashboard, infinite paging is now supported in the Investigations view. The 1,000-record ceiling has been removed, so you can navigate through the full result set directly in the UI. The Investigations API now returns up to 10,000 records per page (up from 1,000), with no cap on total result volume across pages.

For high-volume use cases, we recommend:

Logpush to a SIEM for full-fidelity datasets and long-term retention.
SOAR playbooks against the async bulk action API for large-scale remediation. Bulk actions initiated from the dashboard remain capped at 1,000 messages per action.
The Investigations API for report exports larger than 1,000 results, which is the dashboard download cap.

This applies to all Email Security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare One Client - WARP client for macOS (version 2026.3.566.1)

Tue, 10 Mar 2026 17:10:39 GMT

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and introduces a brand new visual style for the client interface. The new Cloudflare One Client interface changes connectivity management from a toggle to a button and brings useful connectivity settings to the home screen. The redesign also introduces a collapsible navigation bar. When expanded, more client information can be accessed including connectivity, settings, and device profile information. If you have any feedback or questions, visit the Cloudflare Community forum and let us know.

Changes and improvements

Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
Fixed an issue in proxy mode where the client could become unresponsive due to upstream connection timeouts.
Fixed emergency disconnect state from a previous organization incorrectly persisting after switching organizations.
Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
Added monitoring for tunnel statistics collection timeouts.
Switched tunnel congestion control algorithm to Cubic for improved reliability across platforms.
Fixed initiating managed network detection checks when no network is available, which caused device profile flapping.

Known issues

The client may become stuck in a Connecting state. To resolve this issue, reconnect the client by selecting Disconnect and then Connect in the client user interface. Alternatively, change the client's operation mode.
The client may display an empty white screen upon the device waking from sleep. To resolve this issue, exit and then open the client to re-launch it.
Canceling login during a single MDM configuration setup results in an empty page with no way to resume authentication. To work around this issue, exit and relaunch the client.

Cloudflare One Client - WARP client for Windows (version 2026.3.566.1)

Tue, 10 Mar 2026 17:10:37 GMT

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

Changes and improvements

Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
Added monitoring for tunnel statistics collection timeouts.
Switched tunnel congestion control algorithm to Cubic for improved reliability across platforms.
Fixed packet capture failing on tunnel interface when the tunnel interface is renamed by SCCM VPN boundary support.
Fixed unnecessary registration deletion caused by RDP connections in multi-user mode.
Fixed increased tunnel interface start-up time due to a race between duplicate address detection (DAD) and disabling NetBT.
Fixed tunnel failing to connect when the system DNS search list contains unexpected characters.
Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
Fixed an issue in proxy mode where the client could become unresponsive due to upstream connection timeouts.
Fixed emergency disconnect state from a previous organization incorrectly persisting after switching organizations.
Fixed initiating managed network detection checks when no network is available, which caused device profile flapping.

Known issues

The client may unexpectedly terminate during captive portal login. To work around this issue, use a web browser to authenticate with the captive portal and then re-launch the client.
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.
The client may become stuck in a Connecting state. To resolve this issue, reconnect the client by selecting Disconnect and then Connect in the client user interface. Alternatively, change the client's operation mode.
The client may display an empty white screen upon the device waking from sleep. To resolve this issue, exit and then open the client to re-launch it.
Canceling login during a single MDM configuration setup results in an empty page with no way to resume authentication. To work around this issue, exit and relaunch the client.
For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 version KB5062553 or higher for resolution.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later. This warning will be omitted from future release notes. This Microsoft Security Intelligence update was released in May 2025.
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, reconnect the client by selecting Disconnect and then Connect in the client user interface.

Cloudflare One, Access - User risk score selector in Access policies

Wed, 04 Mar 2026 00:00:00 GMT

You can now use user risk scores in your Access policies. The new User Risk Score selector allows you to create Access policies that respond to user behavior patterns detected by Cloudflare's risk scoring system, including impossible travel, high DLP policy matches, and more.

For more information, refer to Use risk scores in Access policies.

Gateway - Gateway Authorization Proxy and hosted PAC files (open beta)

Wed, 04 Mar 2026 00:00:00 GMT

The Gateway Authorization Proxy and PAC file hosting are now in open beta for all plan types.

Previously, proxy endpoints relied on static source IP addresses to authorize traffic, providing no user-level identity in logs or policies. The new authorization proxy replaces IP-based authorization with Cloudflare Access authentication, verifying who a user is before applying Gateway filtering without installing the WARP client.

This is ideal for environments where you cannot deploy a device client, such as virtual desktops (VDI), mergers and acquisitions, or compliance-restricted endpoints.

Key capabilities

Identity-aware proxy traffic — Users authenticate through your identity provider (Okta, Microsoft Entra ID, Google Workspace, and others) via Cloudflare Access. Logs now show exactly which user accessed which site, and you can write identity-based policies like "only the Finance team can access this accounting tool."
Multiple identity providers — Display one or multiple login methods simultaneously, giving flexibility for organizations managing users across different identity systems.
Cloudflare-hosted PAC files — Create and host PAC files directly in Cloudflare One with pre-configured templates for Okta and Azure, hosted at https://pac.cloudflare-gateway.com/<account-id>/<slug> on Cloudflare's global network.
Simplified billing — Each user occupies a seat, exactly like they do with the Cloudflare One Client. No new metrics to track.

Get started

In Cloudflare One ↗︎, go to Networks > Resolvers & Proxies > Proxy endpoints.
Create an authorization proxy endpoint and configure Access policies.
Create a hosted PAC file or write your own.
Configure browsers to use the PAC file URL.
Install the Cloudflare certificate for HTTPS inspection.

For more details, refer to the proxy endpoints documentation and the announcement blog post ↗︎.

Cloudflare One - Copy Cloudflare One resources as JSON or POST requests

Mon, 02 Mar 2026 00:00:00 GMT

You can now copy Cloudflare One resources as JSON or as a ready-to-use API POST request directly from the dashboard. This makes it simple to transition workflows into API calls, automation scripts, or infrastructure-as-code pipelines.

To use this feature, click the overflow menu (⋮) on any supported resource and select Copy as JSON or Copy as POST request. The copied output includes only the fields present on your resource, giving you a clean and minimal starting point for your own API calls.

Initially supported resources:

Access applications
Access policies
Gateway policies
Resolver policies
Service tokens
Identity providers

We will continue to add support for more resources throughout 2026.

Access - Clipboard controls for browser-based RDP

Sun, 01 Mar 2026 00:00:00 GMT

You can now configure clipboard controls for browser-based RDP with Cloudflare Access. Clipboard controls allow administrators to restrict whether users can copy or paste text between their local machine and the remote Windows server.

This feature is useful for organizations that support bring-your-own-device (BYOD) policies or third-party contractors using unmanaged devices. By restricting clipboard access, you can prevent sensitive data from being transferred out of the remote session to a user's personal device.

Configuration options

Clipboard controls are configured per policy within your Access application. For each policy, you can independently allow or deny:

Copy from local client to remote RDP session — Users can copy/paste text from their local machine into the browser-based RDP session.
Copy from remote RDP session to local client — Users can copy/paste text from the browser-based RDP session to their local machine.

By default, both directions are denied for new policies. For existing Access applications created before this feature was available, clipboard access remains enabled to preserve backwards compatibility.

When a user attempts a restricted clipboard action, the clipboard content is replaced with an error message informing them that the action is not allowed.

For more information, refer to Clipboard controls for browser-based RDP.

Access - Export MCP server portal logs with Logpush

Fri, 27 Feb 2026 00:00:00 GMT

MCP server portals now supports Logpush integration. You can automatically export MCP server portal activity logs to third-party storage destinations or security information and event management (SIEM) tools for analysis and auditing.

Available log fields

The MCP server portal logs dataset includes fields such as:

Datetime — Timestamp of the request
PortalID / PortalAUD — Portal identifiers
ServerID / ServerURL — Upstream MCP server details
Method — JSON-RPC method (for example, tools/call, prompts/get, resources/read)
ToolCallName / PromptGetName / ResourceReadURI — Method-specific identifiers
UserID / UserEmail — Authenticated user information
Success / Error — Request outcome
ServerResponseDurationMs — Response time from upstream server

For the complete field reference, refer to MCP portal logs.

Set up Logpush

To configure Logpush for MCP server portal logs, refer to Logpush integration.

Gateway - New protocols added for Gateway Protocol Detection (Beta)

Fri, 27 Feb 2026 00:00:00 GMT

Gateway Protocol Detection now supports seven additional protocols in beta:

Protocol	Notes
IMAP	Internet Message Access Protocol — email retrieval
POP3	Post Office Protocol v3 — email retrieval
SMTP	Simple Mail Transfer Protocol — email sending
MYSQL	MySQL database wire protocol
RSYNC-DAEMON	rsync daemon protocol
LDAP	Lightweight Directory Access Protocol
NTP	Network Time Protocol

These protocols join the existing set of detected protocols (HTTP, HTTP2, SSH, TLS, DCERPC, MQTT, and TPKT) and can be used with the Detected Protocol selector in Network policies to identify and filter traffic based on the application-layer protocol, without relying on port-based identification.

If protocol detection is enabled on your account, these protocols will automatically be logged when detected in your Gateway network traffic.

For more information on using Protocol Detection, refer to the Protocol detection documentation.

Workers - Better Windows support for Python Workers

Wed, 25 Feb 2026 00:00:00 GMT

Pywrangler ↗︎, the CLI tool for managing Python Workers and packages, now supports Windows, allowing you to develop and deploy Python Workers from Windows environments. Previously, Pywrangler was only available on macOS and Linux.

You can install and use Pywrangler on Windows the same way you would on other platforms. Specify your Worker's Python dependencies in your pyproject.toml file, then use the following commands to develop and deploy:

uvx --from workers-py pywrangler dev
uvx --from workers-py pywrangler deploy

All existing Pywrangler functionality, including package management, local development, and deployment, works on Windows without any additional configuration.

Requirements

This feature requires the following minimum versions:

wrangler >= 4.64.0
workers-py >= 1.72.0
uv >= 0.9.28

To upgrade workers-py (which includes Pywrangler) in your project, run:

uv tool upgrade workers-py

To upgrade wrangler, run:

npm install -g wrangler@latest

To upgrade uv, run:

uv self update

To get started with Python Workers on Windows, refer to the Python packages documentation for full details on Pywrangler.

Workers - Write structured queries to filter and search your Workers logs and traces

Wed, 25 Feb 2026 00:00:00 GMT

Workers Observability now includes a query language that lets you write structured queries directly in the search bar to filter your logs and traces. The search bar doubles as a free text search box — type any term to search across all metadata and attributes, or write field-level queries for precise filtering.

Queries written in the search bar sync with the Query Builder sidebar, so you can write a query by hand and then refine it visually, or build filters in the Query Builder and see the corresponding query syntax. The search bar provides autocomplete suggestions for metadata fields and operators as you type.

The query language supports:

Free text search — search everywhere with a keyword like error, or match an exact phrase with "exact phrase"
Field queries — filter by specific fields using comparison operators (for example, status = 500 or $workers.wallTimeMs > 100)
Operators — =, !=, >, >=, <, <=, and : (contains)
Functions — contains(field, value), startsWith(field, prefix), regex(field, pattern), and exists(field)
Boolean logic — add conditions with AND, OR, and NOT

Select the help icon next to the search bar to view the full syntax reference, including all supported operators, functions, and keyboard shortcuts.

Go to the Workers Observability dashboard ↗︎ to try the query language.

Workers - No config? No problem. Just `wrangler deploy`

Wed, 25 Feb 2026 00:00:00 GMT

You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and wrangler deploy will just work.

Starting with Wrangler 4.68.0, running wrangler deploy automatically configures your project by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.

Using Wrangler locally

npx wrangler deploy

When you run wrangler deploy in a project without a configuration file, Wrangler:

Detects your framework from package.json
Prompts you to confirm the detected settings
Installs any required adapters
Generates a wrangler.jsonc configuration file
Deploys your project to Cloudflare Workers

You can also use wrangler setup to configure without deploying, or pass --yes to skip prompts.

Using the Cloudflare dashboard

When you connect a repository through the Workers dashboard ↗︎, a pull request is generated for you with all necessary files, and a preview deployment to check before merging.

Background

In December 2025, we introduced automatic configuration as an experimental feature. It is now generally available and the default behavior.

If you have questions or run into issues, join the GitHub discussion ↗︎.

Cloudflare One Client - WARP client for Windows (version 2026.1.150.0)

Tue, 24 Feb 2026 01:15:23 GMT

A new GA release for the Windows WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features.

Changes and improvements

Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
Improvement for the Windows client certificate posture check to ensure logged results are from checks that run once users log in.
Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
Fixed an issue causing DNS requests to fail with clients in Traffic and DNS mode.
Improved service shutdown behavior in cases where the daemon is unresponsive.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2026.1.150.0)

Tue, 24 Feb 2026 01:15:22 GMT

A new GA release for the macOS WARP client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
Fixed an issue with DNS server configuration failures that caused tunnel connection delays.
Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
Fixed an issue causing DNS requests to fail with clients in Traffic and DNS mode.

Cloudflare One Client - WARP client for Linux (version 2026.1.150.0)

Tue, 24 Feb 2026 00:14:20 GMT

A new GA release for the Linux WARP client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

WARP client version 2025.8.779.0 introduced an updated public key for Linux packages. The public key must be updated if it was installed before September 12, 2025 to ensure the repository remains functional after December 4, 2025. Instructions to make this update are available at pkg.cloudflareclient.com.

Changes and improvements

Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
Fixed issues causing DNS requests to fail with clients in Traffic and DNS mode or DNS only mode.

Stream - Stream live inputs can now be disabled and enabled

Tue, 24 Feb 2026 00:00:00 GMT

You can now disable a live input to reject incoming RTMPS and SRT connections. When a live input is disabled, any broadcast attempts will fail to connect.

This gives you more control over your live inputs:

Temporarily pause an input without deleting it
Programmatically end creator broadcasts
Prevent new broadcasts from starting on a specific input

To disable a live input via the API, set the enabled property to false:

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/live_inputs/{input_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--data '{"enabled": false}'

You can also disable or enable a live input from the Live inputs list page or the live input detail page in the Dashboard.

All existing live inputs remain enabled by default. For more information, refer to Start a live stream.

CASB - Understand CASB findings instantly with Cloudy Summaries

Fri, 20 Feb 2026 00:00:00 GMT

You can now easily understand your SaaS security posture findings and why they were detected with Cloudy Summaries in CASB. This feature integrates Cloudflare's Cloudy AI directly into your CASB Posture Findings to automatically generate clear, plain-language summaries of complex security misconfigurations, third-party app risks, and data exposures.

This allows security teams and IT administrators to drastically reduce triage time by immediately understanding the context, potential impact, and necessary remediation steps for any given finding—without needing to be an expert in every connected SaaS application.

To view a summary, simply navigate to your Posture Findings in the Cloudflare One dashboard (under Cloud and SaaS findings) and open the finding details of a specific instance of a Finding.

Cloudy Summaries are supported on all available integrations, including Microsoft 365, Google Workspace, Salesforce, GitHub, AWS, Slack, and Dropbox. See the full list of supported integrations here.

Key capabilities

Contextual explanations — Quickly understand the specifics of a finding with plain-language summaries detailing exactly what was detected, from publicly shared sensitive files to risky third-party app scopes.
Clear risk assessment — Instantly grasp the potential security impact of the finding, such as data breach risks, unauthorized account access, or email spoofing vulnerabilities.
Actionable guidance — Get clear recommendations and next steps on how to effectively remediate the issue and secure your environment.
Built-in feedback — Help improve future AI summarization accuracy by submitting feedback directly using the thumbs-up and thumbs-down buttons.

Learn more

Learn more about managing CASB Posture Findings in Cloudflare.

Cloudy Summaries in CASB are available to all Cloudflare CASB users today.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard

Fri, 20 Feb 2026 00:00:00 GMT

Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗︎, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.

This new experience provides everything you need to manage Tunnels for public applications, including:

Full Tunnel lifecycle management: Create, configure, delete, and monitor all your Tunnels in one place.
Native integrations: View Tunnels by name when configuring DNS records and Workers VPC — no more copy-pasting UUIDs.
Real-time visibility: Monitor replicas and Tunnel health status directly in the dashboard.
Routing map: Manage all ingress routes for your Tunnel, including public applications, private hostnames, private CIDRs, and Workers VPC services, from a single interactive interface.

Choose the right dashboard for your use case

Core Dashboard: Navigate to Networking > Tunnels ↗︎ to manage Tunnels for:

Securing origin servers and public applications with CDN, WAF, Load Balancing, and DDoS protection
Connecting Workers to private services via Workers VPC

Cloudflare One Dashboard: Navigate to Zero Trust > Networks > Connectors ↗︎ to manage Tunnels for:

Securing your public applications with Zero Trust access policies
Connecting users to private applications
Building a private mesh network

Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow.

Get started

New to Tunnel? Learn how to get started with Cloudflare Tunnel or explore advanced use cases like securing SSH servers or running Tunnels in Kubernetes.

Digital Experience Monitoring - DEX Supports EU Customer Metadata Boundary

Thu, 19 Feb 2026 00:00:00 GMT

Digital Experience Monitoring (DEX) provides visibility into WARP device connectivity and performance to any internal or external application.

Now, all DEX logs are fully compatible with Cloudflare's Customer Metadata Boundary (CMB) setting for the 'EU' (European Union), which ensures that DEX logs will not be stored outside the 'EU' when the option is configured.

If a Cloudflare One customer using DEX enables CMB 'EU', they will not see any DEX data in the Cloudflare One dashboard. Customers can ingest DEX data via LogPush, and build their own analytics and dashboards.

If a customer enables CMB in their account, they will see the following message in the Digital Experience dashboard: "DEX data is unavailable because Customer Metadata Boundary configuration is on. Use Cloudflare LogPush to export DEX datasets."

Access - Streamlined clientless browser isolation for private applications

Tue, 17 Feb 2026 00:00:00 GMT

A new Allow clientless access setting makes it easier to connect users without a device client to internal applications, without using public DNS.

Previously, to provide clientless access to a private hostname or IP without a published application, you had to create a separate bookmark application pointing to a prefixed Clientless Web Isolation URL (for example, https://<your-teamname>.cloudflareaccess.com/browser/https://10.0.0.1/). This bookmark was visible to all users in the App Launcher, regardless of whether they had access to the underlying application.

Now, you can manage clientless access directly within your private self-hosted application. When Allow clientless access is turned on, users who pass your Access application policies will see a tile in their App Launcher pointing to the prefixed URL. Users must have remote browser permissions to open the link.

Access - Policies for bookmark applications

Tue, 17 Feb 2026 00:00:00 GMT

You can now assign Access policies to bookmark applications. This lets you control which users see a bookmark in the App Launcher based on identity, device posture, and other policy rules.

Previously, bookmark applications were visible to all users in your organization. With policy support, you can now:

Tailor the App Launcher to each user — Users only see the applications they have access to, reducing clutter and preventing accidental clicks on irrelevant resources.
Restrict visibility of sensitive bookmarks — Limit who can view bookmarks to internal tools or partner resources based on group membership, identity provider, or device posture.

Bookmarks support all Access policy configurations except purpose justification, temporary authentication, and application isolation. If no policy is assigned, the bookmark remains visible to all users (maintaining backwards compatibility).

For more information, refer to Add bookmarks.

Cloudflare One, Cloudflare WAN, Cloudflare Network Firewall, Network Flow - Cloudflare One Product Name Updates

Tue, 17 Feb 2026 00:00:00 GMT

We are updating naming related to some of our Networking products to better clarify their place in the Zero Trust and Secure Access Service Edge (SASE) journey.

We are retiring some older brand names in favor of names that describe exactly what the products do within your network. We are doing this to help customers build better, clearer mental models for comprehensive SASE architecture delivered on Cloudflare.

What's changing

Magic WAN → Cloudflare WAN
Magic WAN IPsec → Cloudflare IPsec
Magic WAN GRE → Cloudflare GRE
Magic WAN Connector → Cloudflare One Appliance
Magic Firewall → Cloudflare Network Firewall
Magic Network Monitoring → Network Flow
Magic Cloud Networking → Cloudflare One Multi-cloud Networking

No action is required by you — all functionality, existing configurations, and billing will remain exactly the same.

For more information, visit the Cloudflare One documentation.

Workers - Quick Editor devtools replaced with log viewer

Mon, 16 Feb 2026 00:00:00 GMT

Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.

This aligns our logging with wrangler tail and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.

We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the Workers Playground docs.

If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the wrangler init --from-dash command. For more information, refer to Wrangler commands.

Workers - New Best Practices guide for Workers

Sun, 15 Feb 2026 00:00:00 GMT

A new Workers Best Practices guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.

Key guidance includes:

Keep your compatibility date current and enable nodejs_compat — Ensure you have access to the latest runtime features and Node.js built-in modules.

{
	"name": "my-worker",
	"main": "src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"compatibility_flags": ["nodejs_compat"],
}

name = "my-worker"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-11"
compatibility_flags = [ "nodejs_compat" ]

Generate binding types with wrangler types — Never hand-write your Env interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
Stream request and response bodies — Avoid buffering large payloads in memory. Use TransformStream and pipeTo to stay within the 128 MB memory limit and improve time-to-first-byte.
Use bindings, not REST APIs — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
Use Queues and Workflows for background work — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
Enable Workers Logs and Traces — Configure observability before deploying to production so you have data when you need to debug.
Avoid global mutable state — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
Always await or waitUntil your Promises — Floating promises cause silent bugs and dropped work.
Use Web Crypto for secure token generation — Never use Math.random() for security-sensitive operations.

To learn more, refer to Workers Best Practices.

Cloudflare Fundamentals, Access - Fine-grained permissions for Access policies and service tokens

Fri, 13 Feb 2026 00:00:00 GMT

Fine-grained permissions for Access policies and Access service tokens are available. These new resource-scoped roles expand the existing RBAC model, enabling administrators to grant permissions scoped to individual resources.

New roles

Cloudflare Access policy admin: Can edit a specific Access policy in an account.
Cloudflare Access service token admin: Can edit a specific Access service token in an account.

These roles complement the existing resource-scoped roles for Access applications, identity providers, and infrastructure targets.

For more information:

Cloudflare WAN - Anycast IPs displayed on the dashboard

Thu, 12 Feb 2026 00:00:00 GMT

Cloudflare WAN now displays your Anycast IP addresses directly in the dashboard when you configure IPsec or GRE tunnels.

Previously, customers received their Anycast IPs during onboarding or had to retrieve them with an API call. The dashboard now pre-loads these addresses, reducing setup friction and preventing configuration errors.

No action is required. All Cloudflare WAN customers can see their Anycast IPs in the tunnel configuration form automatically.

For more information, refer to Configure tunnel endpoints.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Post-quantum encryption support for Cloudflare One Appliance

Wed, 11 Feb 2026 00:00:00 GMT

Cloudflare One Appliance version 2026.2.0 adds post-quantum encryption support using hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).

The appliance now uses TLS 1.3 with hybrid ML-KEM for its connection to the Cloudflare edge. During the TLS handshake, the appliance and the edge share a symmetric secret over the TLS connection and inject it into the ESP layer of IPsec. This protects IPsec data plane traffic against harvest-now, decrypt-later attacks.

This upgrade deploys automatically to all appliances during their configured interrupt windows with no manual action required.

For more information, refer to Cloudflare One Appliance.

Workers - Workers are no longer limited to 1000 subrequests

Wed, 11 Feb 2026 00:00:00 GMT

Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

{
	"limits": {
		"subrequests": 50000,
	},
}

[limits]
subrequests = 50_000

Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

{
	"limits": {
		"subrequests": 10,
		"cpu_ms": 1000,
	},
}

[limits]
subrequests = 10
cpu_ms = 1_000

For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

Workers - Improved React Server Components support in the Cloudflare Vite plugin

Wed, 11 Feb 2026 00:00:00 GMT

The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc ↗︎, the official Vite plugin for React Server Components ↗︎.

A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

vite.config.tsts

export default defineConfig({
	plugins: [
		cloudflare({
			viteEnvironment: {
				name: "rsc",
				childEnvironments: ["ssr"],
			},
		}),
	],
});

@vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router ↗︎, build upon. The GitHub repository includes a basic Cloudflare example ↗︎.

Workers - Visualize data, share links, and create exports with the new Workers Observability dashboard

Fri, 06 Feb 2026 00:00:00 GMT

The Workers Observability dashboard ↗︎ has some major updates to make it easier to debug your application's issues and share findings with your team.

You can now:

Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
Expandable event details — Expand events inline to view full details without leaving the table
Keyboard shortcuts — Navigate the dashboard with hotkey support

These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

Email security - Improved Accessibility and Search for Monitoring

Mon, 02 Feb 2026 11:05:33 GMT

We have updated the Monitoring page to provide a more streamlined and insightful experience for administrators, improving both data visualization and dashboard accessibility.

Enhanced Visual Layout: Optimized contrast and the introduction of stacked bar charts for clearer data visualization and trend analysis.
Improved Accessibility & Usability:
- Widget Search: Added search functionality to multiple widgets, including Policies, Submitters, and Impersonation.
- Actionable UI: All available actions are now accessible via dedicated buttons.
- State Indicators: Improved UI states to clearly communicate loading, empty datasets, and error conditions.
Granular Data Breakdowns: New views for dispositions by month, malicious email details, link actions, and impersonations.

This applies to all Email Security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare WAN, Magic Transit, Cloudflare One - BGP over GRE and IPsec tunnels

Fri, 30 Jan 2026 00:00:00 GMT

Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta).

Using BGP peering allows customers to:

Automate the process of adding or removing networks and subnets.
Take advantage of failure detection and session recovery features.

With this functionality, customers can:

Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps.
Secure the session by MD5 authentication to prevent misconfigurations.
Exchange routes dynamically between their devices and their Magic routing table.

For configuration details, refer to:

Cloudflare One Client - WARP client for Windows (version 2026.1.89.1)

Tue, 27 Jan 2026 18:47:00 GMT

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

This release contains minor fixes, improvements, and new features.

Changes and improvements

Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
Improvement for the Windows client certificate posture check to ensure logged results are from checks that run once users log in.
Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2026.1.89.1)

Tue, 27 Jan 2026 18:46:59 GMT

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

Cloudflare One, Cloudflare WAN - Configure Cloudflare source IPs (beta)

Tue, 27 Jan 2026 00:00:00 GMT

Cloudflare source IPs are the IP addresses used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks.

For customers using legacy mode routing, traffic to private networks is sourced from public Cloudflare IPs, which may cause IP conflicts. For customers using Unified Routing mode (beta), traffic to private networks is sourced from dedicated, non-Internet-routable private IPv4 range to ensure:

Symmetric routing over private network connections
Proper firewall state preservation
Private traffic stays on secure paths

Key details:

IPv4: Sourced from 100.64.0.0/12 by default, configurable to any /12 CIDR
IPv6: Sourced from 2606:4700:cf1:5000::/64 (not configurable)
Affected connectors: GRE, IPsec, CNI, WARP Connector, and WARP Client (Cloudflare Tunnel is not affected)

Configuring Cloudflare source IPs requires Unified Routing (beta) and the Cloudflare One Networks Write permission.

For configuration details, refer to Configure Cloudflare source IPs.

Cloudflare One, Access - Require Access protection for zones

Thu, 22 Jan 2026 00:00:00 GMT

You can now require Cloudflare Access protection for all hostnames in your account. When enabled, traffic to any hostname that does not have a matching Access application is automatically blocked.

This deny-by-default approach prevents accidental exposure of internal resources to the public Internet. If a developer deploys a new application or creates a DNS record without configuring an Access application, the traffic is blocked rather than exposed.

How it works

Blocked by default: Traffic to all hostnames in the account is blocked unless an Access application exists for that hostname.
Explicit access required: To allow traffic, create an Access application with an Allow or Bypass policy.
Hostname exemptions: You can exempt specific hostnames from this requirement.

To turn on this feature, refer to Require Access protection.

Access - New granular API token permissions for Cloudflare Access

Thu, 22 Jan 2026 00:00:00 GMT

Three new API token permissions are available for Cloudflare Access, giving you finer-grained control when building automations and integrations:

Access: Organizations Revoke — Grants the ability to revoke user sessions in a Zero Trust organization. Use this permission when you need a token that can terminate active sessions without broader write access to organization settings.
Access: Population Read — Grants read access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that only need to read synced user and group data.
Access: Population Write — Grants write access to the SCIM users and groups synced from an identity provider to Cloudflare Access. Use this permission for tokens that need to create or modify synced user and group data.

These permissions are scoped at the account level and can be combined with existing Access permissions.

For a full list of available permissions, refer to API token permissions.

Workers - New Placement Hints for Workers

Thu, 22 Jan 2026 00:00:00 GMT

You can now configure Workers to run close to infrastructure in legacy cloud regions to minimize latency to existing services and databases. This is most useful when your Worker makes multiple round trips.

To set a placement hint, set the placement.region property in your Wrangler configuration file:

{
	"placement": {
		"region": "aws:us-east-1",
	},
}

[placement]
region = "aws:us-east-1"

Placement hints support Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure region identifiers. Workers run in the Cloudflare data center ↗︎ with the lowest latency to the specified cloud region.

If your existing infrastructure is not in these cloud providers, expose it to placement probes with placement.host for layer 4 checks or placement.hostname for layer 7 checks. These probes are designed to locate single-homed infrastructure and are not suitable for anycasted or multicasted resources.

{
	"placement": {
		"host": "my_database_host.com:5432",
	},
}

[placement]
host = "my_database_host.com:5432"

{
	"placement": {
		"hostname": "my_api_server.com",
	},
}

[placement]
hostname = "my_api_server.com"

This is an extension of Smart Placement, which automatically places your Workers closer to back-end APIs based on measured latency. When you do not know the location of your back-end APIs or have multiple back-end APIs, set mode: "smart":

{
	"placement": {
		"mode": "smart",
	},
}

[placement]
mode = "smart"

Workers - Use auxiliary Workers alongside full-stack frameworks

Tue, 20 Jan 2026 00:00:00 GMT

Auxiliary Workers are now fully supported when using full-stack frameworks, such as React Router and TanStack Start, that integrate with the Cloudflare Vite plugin. They are included alongside the framework's build output in the build output directory. Note that this feature requires Vite 7 or above.

Auxiliary Workers are additional Workers that can be called via service bindings from your main (entry) Worker. They are defined in the plugin config, as in the example below:

vite.config.tsts

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		tanstackStart(),
		cloudflare({
			viteEnvironment: { name: "ssr" },
			auxiliaryWorkers: [{ configPath: "./wrangler.aux.jsonc" }],
		}),
	],
});

See the Vite plugin API docs for more info.

Workers - Import SQL files as additional modules by default

Tue, 20 Jan 2026 00:00:00 GMT

The .sql file extension is now automatically configured to be importable in your Worker code when using Wrangler or the Cloudflare Vite plugin. This is particular useful for importing migrations in Durable Objects and means you no longer need to configure custom rules when using Drizzle ↗︎.

SQL files are imported as JavaScript strings:

// `example` will be a JavaScript string
import example from "./example.sql";

Magic Transit, Cloudflare Network Firewall, Cloudflare WAN, Network Flow - Network Services navigation update

Thu, 15 Jan 2026 00:00:00 GMT

The Network Services menu structure in Cloudflare's dashboard has been updated to reflect solutions and capabilities instead of product names. This will make it easier for you to find what you need and better reflects how our services work together.

Your existing configurations will remain the same, and you will have access to all of the same features and functionality.

The changes visible in your dashboard may vary based on the products you use. Overall, changes relate to Magic Transit ↗︎, Magic WAN ↗︎, and Magic Firewall ↗︎.

Summary of changes:

A new Overview page provides access to the most common tasks across Magic Transit and Magic WAN.
Product names have been removed from top-level navigation.
Magic Transit and Magic WAN configuration is now organized under Routes and Connectors. For example, you will find IP Prefixes under Routes, and your GRE/IPsec Tunnels under Connectors.
Magic Firewall policies are now called Firewall Policies.
Magic WAN Connectors and Connector On-Ramps are now referenced in the dashboard as Appliances and Appliance profiles. They can be found under Connectors > Appliances.
Network analytics, network health, and real-time analytics are now available under Insights.
Packet Captures are found under Insights > Diagnostics.
You can manage your Sites from Insights > Network health.
You can find Magic Network Monitoring under Insights > Network flow.

If you would like to provide feedback, complete this form ↗︎. You can also find these details in the January 7, 2026 email titled [FYI] Upcoming Network Services Dashboard Navigation Update.

Preview:

Risk Score - Support for CrowdStrike device scores in User Risk Scoring

Thu, 15 Jan 2026 00:00:00 GMT

Cloudflare One has expanded its [User Risk Scoring] (/cloudflare-one/insights/risk-score/) capabilities by introducing two new behaviors for organizations using the [CrowdStrike integration] (/cloudflare-one/integrations/service-providers/crowdstrike/).

Administrators can now automatically escalate the risk score of a user if their device matches specific CrowdStrike Zero Trust Assessment (ZTA) score ranges. This allows for more granular security policies that respond dynamically to the health of the endpoint.

New risk behaviors The following risk scoring behaviors are now available:

CrowdStrike low device score: Automatically increases a user's risk score when the connected device reports a "Low" score from CrowdStrike.
CrowdStrike medium device score: Automatically increases a user's risk score when the connected device reports a "Medium" score from CrowdStrike.

These scores are derived from [CrowdStrike device posture attributes] (/cloudflare-one/integrations/service-providers/crowdstrike/#device-posture-attributes), including OS signals and sensor configurations.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Verify WARP Connector connectivity with a simple ping

Thu, 15 Jan 2026 00:00:00 GMT

We have made it easier to validate connectivity when deploying WARP Connector as part of your software-defined private network.

You can now ping the WARP Connector host directly on its LAN IP address immediately after installation. This provides a fast, familiar way to confirm that the Connector is online and reachable within your network before testing access to downstream services.

Starting with version 2025.10.186.0, WARP Connector responds to traffic addressed to its own LAN IP, giving you immediate visibility into Connector reachability.

Learn more about deploying WARP Connector and building private network connectivity with Cloudflare One.

Cloudflare One Client - WARP client for Windows (version 2025.10.186.0)

Tue, 13 Jan 2026 15:48:19 GMT

A new GA release for the Windows WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features. New features include the ability to manage WARP client connectivity for all devices in your fleet using an external signal, and a new WARP client device posture check for Antivirus.

Changes and improvements

Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.
Fixed an issue that caused occasional audio degradation and increased CPU usage on Windows by optimizing route configurations for large domain-based split tunnel rules.
The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
Fixed an issue where sending large messages to the daemon by Inter-Process Communication (IPC) could cause the daemon to fail and result in service interruptions.
Added support for a new WARP client device posture check for Antivirus. The check confirms the presence of an antivirus program on a Windows device with the option to check if the antivirus is up to date.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2025.10.186.0)

Tue, 13 Jan 2026 15:48:17 GMT

A new GA release for the macOS WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features, including the ability to manage WARP client connectivity for all devices in your fleet using an external signal.

Changes and improvements

The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.

Cloudflare One Client - WARP client for Linux (version 2025.10.186.0)

Tue, 13 Jan 2026 01:53:14 GMT

A new GA release for the Linux WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features, including the ability to manage WARP client connectivity for all devices in your fleet using an external signal.

Changes and improvements

The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
Linux disk encryption posture check now supports non-filesystem encryption types like dm-crypt.
Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
Fixed an issue where the GUI becomes unresponsive when the Re-Authenticate in browser button is clicked.
Added a new feature to manage WARP client connectivity for all devices using an external signal. This feature allows administrators to send a global signal from an on-premises HTTPS endpoint that force disconnects or reconnects all WARP clients in an account based on configuration set on the endpoint.

Workers - `wrangler types` now generates types for all environments

Tue, 13 Jan 2026 00:00:00 GMT

The wrangler types command now generates TypeScript types for bindings from all environments defined in your Wrangler configuration file by default.

Previously, wrangler types only generated types for bindings in the top-level configuration (or a single environment when using the --env flag). This meant that if you had environment-specific bindings — for example, a KV namespace only in production or an R2 bucket only in staging — those bindings would be missing from your generated types, causing TypeScript errors when accessing them.

Now, running wrangler types collects bindings from all environments and includes them in the generated Env type. This ensures your types are complete regardless of which environment you deploy to.

Generating types for a specific environment

If you want the previous behavior of generating types for only a specific environment, you can use the --env flag:

wrangler types --env production

Learn more about generating types for your Worker in the Wrangler documentation.

Email security - Enhanced visibility for post-delivery actions

Mon, 12 Jan 2026 11:15:33 GMT

The Action Log now provides enriched data for post-delivery actions to improve troubleshooting. In addition to success confirmations, failed actions now display the targeted Destination folder and a specific failure reason within the Activity field.

This update allows you to see the full lifecycle of a failed action. For instance, if an administrator tries to move an email that has already been deleted or moved manually, the log will now show the multiple retry attempts and the specific destination error.

This applies to all Email Security packages:

Enterprise
Enterprise + PhishGuard

Workers - Validate your generated types with `wrangler types --check`

Mon, 12 Jan 2026 00:00:00 GMT

Wrangler now supports a --check flag for the wrangler types command. This flag validates that your generated types are up to date without writing any changes to disk.

This is useful in CI/CD pipelines where you want to ensure that developers have regenerated their types after making changes to their Wrangler configuration. If the types are out of date, the command will exit with a non-zero status code.

npx wrangler types --check

If your types are up to date, the command will succeed silently. If they are out of date, you'll see an error message indicating which files need to be regenerated.

For more information, see the Wrangler types documentation.

Workers, Queues - Get notified when your Workers builds succeed or fail

Fri, 09 Jan 2026 00:00:00 GMT

You can now receive notifications when your Workers' builds start, succeed, fail, or get cancelled using Event Subscriptions.

Workers Builds publishes events to a Queue that your Worker can read messages from, and then send notifications wherever you need — Slack, Discord, email, or any webhook endpoint.

You can deploy this Worker ↗︎ to your own Cloudflare account to send build notifications to Slack:

The template includes:

Build status with Preview/Live URLs for successful deployments
Inline error messages for failed builds
Branch, commit hash, and author name

For setup instructions, refer to the template README ↗︎ or the Event Subscriptions documentation.

Workers - Shell tab completions for Wrangler CLI

Fri, 09 Jan 2026 00:00:00 GMT

Wrangler now includes built-in shell tab completion support, making it faster and easier to navigate commands without memorizing every option. Press Tab as you type to autocomplete commands, subcommands, flags, and even option values like log levels.

Tab completions are supported for Bash, Zsh, Fish, and PowerShell.

Setup

Generate the completion script for your shell and add it to your configuration file:

# Bash
wrangler complete bash >> ~/.bashrc

# Zsh
wrangler complete zsh >> ~/.zshrc

# Fish
wrangler complete fish >> ~/.config/fish/config.fish

# PowerShell
wrangler complete powershell >> $PROFILE

After adding the script, restart your terminal or source your configuration file for the changes to take effect. Then you can simply press Tab to see available completions:

wrangler d<TAB>          # completes to 'deploy', 'dev', 'd1', etc.
wrangler kv <TAB>        # shows subcommands: namespace, key, bulk

Tab completions are dynamically generated from Wrangler's command registry, so they stay up-to-date as new commands and options are added. This feature is powered by @bomb.sh/tab ↗︎.

See the wrangler complete documentation for more details.

Access - Cloudflare admin activity logs capture creation of DNS over HTTP (DoH) users

Thu, 08 Jan 2026 00:00:00 GMT

Cloudflare admin activity logs now capture each time a DNS over HTTP (DoH) user is created.

These logs can be viewed from the Cloudflare One dashboard ↗︎, pulled via the Cloudflare API, and exported through Logpush.

Workers Analytics Engine, Workers - Workers Analytics Engine SQL now supports filtering using HAVING and LIKE

Wed, 07 Jan 2026 00:00:00 GMT

You can now use the HAVING clause and LIKE pattern matching operators in Workers Analytics Engine ↗︎.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale and query your data through a simple SQL API.

Filtering using `HAVING`

The HAVING clause complements the WHERE clause by enabling you to filter groups based on aggregate values. While WHERE filters rows before aggregation, HAVING filters groups after aggregation is complete.

You can use HAVING to filter groups where the average exceeds a threshold:

SELECT
    blob1 AS probe_name,
    avg(double1) AS average_temp
FROM temperature_readings
GROUP BY probe_name
HAVING average_temp > 10

You can also filter groups based on aggregates such as the number of items in the group:

SELECT
    blob1 AS probe_name,
    count() AS num_readings
FROM temperature_readings
GROUP BY probe_name
HAVING num_readings > 100

Pattern matching using `LIKE`

The new pattern matching operators enable you to search for strings that match specific patterns using wildcard characters:

LIKE - case-sensitive pattern matching
NOT LIKE - case-sensitive pattern exclusion
ILIKE - case-insensitive pattern matching
NOT ILIKE - case-insensitive pattern exclusion

Pattern matching supports two wildcard characters: % (matches zero or more characters) and _ (matches exactly one character).

You can match strings starting with a prefix:

SELECT *
FROM logs
WHERE blob1 LIKE 'error%'

You can also match file extensions (case-insensitive):

SELECT *
FROM requests
WHERE blob2 ILIKE '%.jpg'

Another example is excluding strings containing specific text:

SELECT *
FROM events
WHERE blob3 NOT ILIKE '%debug%'

Ready to get started?

Learn more about the HAVING clause or pattern matching operators in the Workers Analytics Engine SQL reference documentation.

Workers - Build microfrontend applications on Workers

Thu, 01 Jan 2026 00:00:00 GMT

You can now deploy microfrontends to Cloudflare, splitting a single application into smaller, independently deployable units that render as one cohesive application. This lets different teams using different frameworks develop, test, and deploy each microfrontend without coordinating releases.

Microfrontends solve several challenges for large-scale applications:

Independent deployments: Teams deploy updates on their own schedule without redeploying the entire application
Framework flexibility: Build multi-framework applications (for example, Astro, Remix, and Next.js in one app)
Gradual migration: Migrate from a monolith to a distributed architecture incrementally

Create a microfrontend project:

This template automatically creates a router worker with pre-configured routing logic, and lets you configure Service bindings to Workers you have already deployed to your Cloudflare account. The router Worker analyzes incoming requests, matches them against configured routes, and forwards requests to the appropriate microfrontend via service bindings. The router automatically rewrites HTML, CSS, and headers to ensure assets load correctly from each microfrontend's mount path. The router includes advanced features like preloading for faster navigation between microfrontends, smooth page transitions using the View Transitions API, and automatic path rewriting for assets, redirects, and cookies.

Each microfrontend can be a full-framework application, a static site with Workers Static Assets, or any other Worker-based application.

Get started with the microfrontends template ↗︎, or read the microfrontends documentation for implementation details.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Breakout traffic visibility via NetFlow

Wed, 31 Dec 2025 00:00:00 GMT

Magic WAN Connector now exports NetFlow data for breakout traffic to Magic Network Monitoring (MNM), providing visibility into traffic that bypasses Cloudflare's security filtering.

This feature allows you to:

Monitor breakout traffic statistics in the Cloudflare dashboard.
View traffic patterns for applications configured to bypass Cloudflare.
Maintain visibility across all traffic passing through your Magic WAN Connector.

For more information, refer to NetFlow statistics.

Workers - Static prerendering support for TanStack Start

Fri, 19 Dec 2025 00:00:00 GMT

TanStack Start ↗︎ apps can now prerender routes to static HTML at build time with access to build time environment variables and bindings, and serve them as static assets. To enable prerendering, configure the prerender option of the TanStack Start plugin in your Vite config:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";

export default defineConfig({
  plugins: [
    cloudflare({ viteEnvironment: { name: "ssr" } }),
    tanstackStart({
      prerender: {
        enabled: true,
      },
    }),
  ],
});

This feature requires @tanstack/react-start v1.138.0 or later. See the TanStack Start framework guide for more details.

Workers - Build image policies for Workers Builds and Cloudflare Pages

Thu, 18 Dec 2025 00:00:00 GMT

We've published build image policies for Workers Builds and Cloudflare Pages, which establish:

Minor version updates: We typically update preinstalled software to the latest available minor version without notice. For tools that don't follow semantic versioning (e.g., Bun or Hugo), we provide 3 months’ notice.
Major version updates: Before preinstalled software reaches end-of-life, we update to the next stable LTS version with 3 months’ notice.
Build image version deprecation (Pages only): We provide 6 months’ notice before deprecation. Projects on v1 or v2 will be automatically moved to v3 on their specified deprecation dates.

To prepare for updates, monitor the Cloudflare Changelog ↗︎, dashboard notifications, and email. You can also override default versions to maintain specific versions.

Workers - Retrieve your authentication token with `wrangler auth token`

Thu, 18 Dec 2025 00:00:00 GMT

Wrangler now includes a new wrangler auth token command that retrieves your current authentication token or credentials for use with other tools and scripts.

wrangler auth token

The command returns whichever authentication method is currently configured, in priority order: API token from CLOUDFLARE_API_TOKEN, or OAuth token from wrangler login (automatically refreshed if expired).

Use the --json flag to get structured output including the token type:

wrangler auth token --json

The JSON output includes the authentication type:

// API token
{ "type": "api_token", "token": "..." }

// OAuth token
{ "type": "oauth", "token": "..." }

// API key/email (only available with --json)
{ "type": "api_key", "key": "...", "email": "..." }

API key/email credentials from CLOUDFLARE_API_KEY and CLOUDFLARE_EMAIL require the --json flag since this method uses two values instead of a single token.

Gateway, Cloudflare One - Shadow IT - domain level SaaS analytics

Wed, 17 Dec 2025 00:00:00 GMT

Zero Trust has again upgraded its Shadow IT analytics, providing you with unprecedented visibility into your organizations use of SaaS tools. With this dashboard, you can review who is using an application and volumes of data transfer to the application.

With this update, you can review data transfer metrics at the domain level, rather than just the application level, providing more granular insight into your data transfer patterns.

These metrics can be filtered by all available filters on the dashboard, including user, application, or content category.

Both the analytics and policies are accessible in the Cloudflare Zero Trust dashboard ↗︎, empowering organizations with better visibility and control.

Cloudflare One - New duplicate action for supported Cloudflare One resources

Tue, 16 Dec 2025 00:00:00 GMT

You can now duplicate specific Cloudflare One resources with a single click from the dashboard.

Initially supported resources:

Access Applications
Access Policies
Gateway Policies

To try this out, simply click on the overflow menu (⋮) from the resource table and click Duplicate. We will continue to add the Duplicate action for resources throughout 2026.

Workers - Support for ctx.exports in @cloudflare/vitest-pool-workers

Tue, 16 Dec 2025 00:00:00 GMT

The @cloudflare/vitest-pool-workers package now supports the ctx.exports API, allowing you to access your Worker's top-level exports during tests.

You can access ctx.exports in unit tests by calling createExecutionContext():

import { createExecutionContext } from "cloudflare:test";
import { it, expect } from "vitest";

it("can access ctx.exports", async () => {
  const ctx = createExecutionContext();
  const result = await ctx.exports.MyEntryPoint.myMethod();
  expect(result).toBe("expected value");
});

Alternatively, you can import exports directly from cloudflare:workers:

import { exports } from "cloudflare:workers";
import { it, expect } from "vitest";

it("can access imported exports", async () => {
  const result = await exports.MyEntryPoint.myMethod();
  expect(result).toBe("expected value");
});

See the context-exports fixture ↗︎ for a complete example.

Workers - Configure your framework for Cloudflare automatically

Tue, 16 Dec 2025 00:00:00 GMT

Wrangler now supports automatic configuration for popular web frameworks in experimental mode, making it even easier to deploy to Cloudflare Workers.

Previously, if you wanted to deploy an application using a popular web framework like Next.js or Astro, you had to follow tutorials to set up your application for deployment to Cloudflare Workers. This usually involved creating a Wrangler file, installing adapters, or changing configuration options.

Now wrangler deploy does this for you. Starting with Wrangler 4.55, you can use npx wrangler deploy --x-autoconfig in the directory of any web application using one of the supported frameworks. Wrangler will then proceed to configure and deploy it to your Cloudflare account.

You can also configure your application without deploying it by using the new npx wrangler setup command. This enables you to easily review what changes we are making so your application is ready for Cloudflare Workers.

The following application frameworks are supported starting today:

Next.js
Astro
Nuxt
TanStack Start
SolidStart
React Router
SvelteKit
Docusaurus
Qwik
Analog

Automatic configuration also supports static sites by detecting the assets directory and build command. From a single index.html file to the output of a generator like Jekyll or Hugo, you can just run npx wrangler deploy --x-autoconfig to upload to Cloudflare.

We're really excited to bring you automatic configuration so you can do more with Workers. Please let us know if you run into challenges using this experimentally. We’ve opened a GitHub discussion ↗︎ and would love to hear your feedback.

Cloudflare One Client - WARP client for Windows (version 2025.10.118.1)

Tue, 09 Dec 2025 23:03:10 GMT

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.
Fixed an issue where sending large messages to the WARP daemon by Inter-Process Communication (IPC) could cause WARP to crash and result in service interruptions.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2025.10.118.1)

Tue, 09 Dec 2025 23:02:28 GMT

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

The Local Domain Fallback feature has been fixed for devices running WARP client version 2025.4.929.0 and newer. Previously, these devices could experience failures with Local Domain Fallback unless a fallback server was explicitly configured. This configuration is no longer a requirement for the feature to function correctly.
Proxy mode now supports transparent HTTP proxying in addition to CONNECT-based proxying.

Workers - Python cold start improvements

Mon, 08 Dec 2025 00:00:00 GMT

Python Workers now feature improved cold start performance, reducing initialization time for new Worker instances. This improvement is particularly noticeable for Workers with larger dependency sets or complex initialization logic.

Every time you deploy a Python Worker, a memory snapshot is captured after the top level of the Worker is executed. This snapshot captures all imports, including package imports that are often costly to load. The memory snapshot is loaded when the Worker is first started, avoiding the need to reload the Python runtime and all dependencies on each cold start.

We set up a benchmark that imports common packages (httpx ↗︎, fastapi ↗︎ and pydantic ↗︎) to see how Python Workers stack up against other platforms:

Platform	Mean Cold Start (ms)
Cloudflare Python Workers	1027
AWS Lambda	2502
Google Cloud Run	3069

These benchmarks run continuously. You can view the results and the methodology on our benchmark page ↗︎.

In additional testing, we have found that without any memory snapshot, the cold start for this benchmark takes around 10 seconds, so this change improves cold start performance by roughly a factor of 10.

To get started with Python Workers, check out our Python Workers overview.

Workers - Easy Python package management with Pywrangler

Mon, 08 Dec 2025 00:00:00 GMT

We are introducing a brand new tool called Pywrangler, which simplifies package management in Python Workers by automatically installing Workers-compatible Python packages into your project.

With Pywrangler, you specify your Worker's Python dependencies in your pyproject.toml file:

[project]
name = "python-beautifulsoup-worker"
version = "0.1.0"
description = "A simple Worker using beautifulsoup4"
requires-python = ">=3.12"
dependencies = [
    "beautifulsoup4"
]

[dependency-groups]
dev = [
  "workers-py",
  "workers-runtime-sdk"
]

You can then develop and deploy your Worker using the following commands:

uv run pywrangler dev
uv run pywrangler deploy

Pywrangler automatically downloads and vendors the necessary packages for your Worker, and these packages are bundled with the Worker when you deploy.

Consult the Python packages documentation for full details on Pywrangler and Python package management in Workers.

Workers - Wrangler config is optional when using Vite plugin

Mon, 08 Dec 2025 00:00:00 GMT

When using the Cloudflare Vite plugin to build and deploy Workers, a Wrangler configuration file is now optional for assets-only (static) sites. If no wrangler.toml, wrangler.json, or wrangler.jsonc file is found, the plugin generates sensible defaults for an assets-only site. The name is based on the package.json or the project directory name, and the compatibility_date uses the latest date supported by your installed Miniflare version.

This allows easier setup for static sites using Vite. Note that SPAs will still need to set assets.not_found_handling to single-page-application ↗︎ in order to function correctly.

Workers - Configure Workers programmatically using the Vite plugin

Mon, 08 Dec 2025 00:00:00 GMT

The Cloudflare Vite plugin now supports programmatic configuration of Workers without a Wrangler configuration file. You can use the config option to define Worker settings directly in your Vite configuration, or to modify existing configuration loaded from a Wrangler config file. This is particularly useful when integrating with other build tools or frameworks, as it allows them to control Worker configuration without needing users to manage a separate config file.

The `config` option

The Vite plugin's new config option accepts either a partial configuration object or a function that receives the current configuration and returns overrides. This option is applied after any config file is loaded, allowing the plugin to override specific values or define Worker configuration entirely in code.

Example usage

Setting config to an object to provide configuration values that merge with defaults and config file settings:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		cloudflare({
			config: {
				name: "my-worker",
				compatibility_flags: ["nodejs_compat"],
				send_email: [
					{
						name: "EMAIL",
					},
				],
			},
		}),
	],
});

Use a function to modify the existing configuration:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";
export default defineConfig({
	plugins: [
		cloudflare({
			config: (userConfig) => {
				delete userConfig.compatibility_flags;
			},
		}),
	],
});

Return an object with values to merge:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		cloudflare({
			config: (userConfig) => {
				if (!userConfig.compatibility_flags.includes("no_nodejs_compat")) {
					return { compatibility_flags: ["nodejs_compat"] };
				}
			},
		}),
	],
});

Auxiliary Workers

Auxiliary Workers also support the config option, enabling multi-Worker architectures without config files.

Define auxiliary Workers without config files using config inside the auxiliaryWorkers array:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		cloudflare({
			config: {
				name: "entry-worker",
				main: "./src/entry.ts",
				services: [{ binding: "API", service: "api-worker" }],
			},
			auxiliaryWorkers: [
				{
					config: {
						name: "api-worker",
						main: "./src/api.ts",
					},
				},
			],
		}),
	],
});

For more details and examples, see Programmatic configuration.

Workers - One-click Access protection for Workers now creates reusable Cloudflare Access policies

Thu, 04 Dec 2025 00:00:00 GMT

Workers applications now use reusable Cloudflare Access policies to reduce duplication and simplify access management across multiple Workers.

Previously, enabling Cloudflare Access on a Worker created per-application policies, unique to each application. Now, we create reusable policies that can be shared across applications:

Preview URLs: All Workers preview URLs share a single "Cloudflare Workers Preview URLs" policy across your account. This policy is automatically created the first time you enable Access on any preview URL. By sharing a single policy across all preview URLs, you can configure access rules once and have them apply company-wide to all Workers which protect preview URLs. This makes it much easier to manage who can access preview environments without having to update individual policies for each Worker.
Production workers.dev URLs: When enabled, each Worker gets its own reusable policy (named <worker-name> - Production) by default. We recognize production services often have different access requirements and having individual policies here makes it easier to configure service-to-service authentication or protect internal dashboards or applications with specific user groups. Keeping these policies separate gives you the flexibility to configure exactly the right access rules for each production service. When you disable Access on a production Worker, the associated policy is automatically cleaned up if it's not being used by other applications.

This change reduces policy duplication, simplifies cross-company access management for preview environments, and provides the flexibility needed for production services. You can still customize access rules by editing the reusable policies in the Zero Trust dashboard.

To enable Cloudflare Access on your Worker:

In the Cloudflare dashboard, go to Workers & Pages.
Select your Worker.
Go to Settings > Domains & Routes.
For workers.dev or Preview URLs, click Enable Cloudflare Access.
Optionally, click Manage Cloudflare Access to customize the policy.

For more information on configuring Cloudflare Access for Workers, refer to the Workers Access documentation.

Email security - Reclassifications to Submissions

Wed, 03 Dec 2025 21:11:33 GMT

We have updated the terminology “Reclassify” and “Reclassifications” to “Submit” and “Submissions” respectively. This update more accurately reflects the outcome of providing these items to Cloudflare.

Submissions are leveraged to tune future variants of campaigns. To respect data sanctity, providing a submission does not change the original disposition of the emails submitted.

This applies to all Email Security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Workers - Environment variable limits increase for Workers Builds

Fri, 21 Nov 2025 00:00:00 GMT

Workers Builds now supports up to 64 environment variables, and each environment variable can be up to 5 KB in size. The previous limit was 5 KB total across all environment variables.

This change enables better support for complex build configurations, larger application settings, and more flexible CI/CD workflows.

For more details, refer to the build limits documentation.

Workers - Better local deployment flow for Cloudflare Workers

Fri, 21 Nov 2025 00:00:00 GMT

Until now, if a Worker had been previously deployed via the Cloudflare Dashboard ↗︎, a subsequent deployment done via the Cloudflare Workers CLI, Wrangler (through the deploy command), would allow the user to override the Worker's dashboard settings without providing details on what dashboard settings would be lost.

Now instead, wrangler deploy presents a helpful representation of the differences between the local configuration and the remote dashboard settings, and offers to update your local configuration file for you.

See example below showing a before and after for wrangler deploy when a local configuration is expected to override a Worker's dashboard settings:

Before

After

Also, if instead Wrangler detects that a deployment would override remote dashboard settings but in an additive way, without modifying or removing any of them, it will simply proceed with the deployment without requesting any user interaction.

Update to Wrangler v4.50.0 or greater to take advantage of this improved deploy flow.

Email security - Adjustment to Final Disposition Column

Tue, 18 Nov 2025 00:00:00 GMT

Adjustment to Final Disposition column

The Final Disposition column in Submissions > Team Submissions tab is changing for non-Phishguard customers.

What's Changing

Column will be called Status instead of Final Disposition
Column status values will now be: Submitted, Accepted or Rejected.

Next Steps

We will listen carefully to your feedback and continue to find comprehensive ways to communicate updates on your submissions. Your submissions will continue to be addressed at an even greater rate than before, fuelling faster and more accurate email security improvement.

Cloudflare One - New Cloudflare One Navigation and Product Experience

Mon, 17 Nov 2025 00:00:00 GMT

The Zero Trust dashboard and navigation is receiving significant and exciting updates. The dashboard is being restructured to better support common tasks and workflows, and various pages have been moved and consolidated.

There is a new guided experience on login detailing the changes, and you can use the Zero Trust dashboard search to find product pages by both their new and old names, as well as your created resources. To replay the guided experience, you can find it in Overview > Get Started.

Notable changes

Product names have been removed from many top-level navigation items to help bring clarity to what they help you accomplish. For example, you can find Gateway policies under ‘Traffic policies' and CASB findings under ‘Cloud & SaaS findings.'
You can view all analytics, logs, and real-time monitoring tools from ‘Insights.'
‘Networks' better maps the ways that your corporate network interacts with Cloudflare. Some pages like Tunnels, are now a tab rather than a full page as part of these changes. You can find them at Networks > Connectors.
Settings are now located closer to the tools and resources they impact. For example, this means you'll find your WARP configurations at Team & Resources > Devices.

No changes to our API endpoint structure or to any backend services have been made as part of this effort.

Access - Generate Cloudflare Access SSH certificate authority (CA) directly from the Cloudflare dashboard

Fri, 14 Nov 2025 00:00:00 GMT

SSH with Cloudflare Access for Infrastructure allows you to use short-lived SSH certificates to eliminate SSH key management and reduce security risks associated with lost or stolen keys.

Previously, users had to generate this certificate by using the Cloudflare API ↗︎ directly. With this update, you can now create and manage this certificate in the Cloudflare One dashboard ↗︎ from the Access controls > Service credentials page.

For more details, refer to Generate a Cloudflare SSH CA.

CASB - New SaaS Security weekly digests with API CASB

Fri, 14 Nov 2025 00:00:00 GMT

You can now stay on top of your SaaS security posture with the new CASB Weekly Digest notification. This opt-in email digest is delivered to your inbox every Monday morning and provides a high-level summary of your organization's Cloudflare API CASB findings from the previous week.

This allows security teams and IT administrators to get proactive, at-a-glance visibility into new risks and integration health without having to log in to the dashboard.

To opt in, navigate to Manage Account > Notifications in the Cloudflare dashboard to configure the CASB Weekly Digest alert type.

Key capabilities

At-a-glance summary — Review new high/critical findings, most frequent finding types, and new content exposures from the past 7 days.
Integration health — Instantly see the status of all your connected SaaS integrations (Healthy, Unhealthy, or Paused) to spot API connection issues.
Proactive alerting — The digest is sent automatically to all subscribed users every Monday morning.
Easy to configure — Users can opt in by enabling the notification in the Cloudflare dashboard under Manage Account > Notifications.

Learn more

Configure notification preferences in Cloudflare.

The CASB Weekly Digest notification is available to all Cloudflare users today.

Digital Experience Monitoring - DEX Logpush jobs

Wed, 12 Nov 2025 00:00:00 GMT

Digital Experience Monitoring (DEX) provides visibility into WARP device metrics, connectivity, and network performance across your Cloudflare SASE deployment.

We've released four new WARP and DEX device data sets that can be exported via Cloudflare Logpush. These Logpush data sets can be exported to R2, a cloud bucket, or a SIEM to build a customized logging and analytics experience.

To create a new DEX or WARP Logpush job, customers can go to the account level of the Cloudflare dashboard > Analytics & Logs > Logpush to get started.

Workers Analytics Engine, Workers - More SQL aggregate, date and time functions available in Workers Analytics Engine

Wed, 12 Nov 2025 00:00:00 GMT

You can now perform more powerful queries directly in Workers Analytics Engine ↗︎ with a major expansion of our SQL function library.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.

Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:

New aggregate functions: ↗︎

countIf() - count the number of rows which satisfy a provided condition
sumIf() - calculate a sum from rows which satisfy a provided condition
avgIf() - calculate an average from rows which satisfy a provided condition

New date and time functions: ↗︎

toYear()
toMonth()
toDayOfMonth()
toDayOfWeek()
toHour()
toMinute()
toSecond()
toStartOfYear()
toStartOfMonth()
toStartOfWeek()
toStartOfDay()
toStartOfHour()
toStartOfFifteenMinutes()
toStartOfTenMinutes()
toStartOfFiveMinutes()
toStartOfMinute()
today()
toYYYYMM()

Ready to get started?

Whether you're building usage-based billing systems, customer analytics dashboards, or other custom analytics, these functions let you get the most out of your data. Get started with Workers Analytics Engine and explore all available functions in our SQL reference documentation.

Cloudflare One Client - WARP client for Windows (version 2025.9.558.0)

Tue, 11 Nov 2025 17:28:35 GMT

A new GA release for the Windows WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features including Path Maximum Transmission Unit Discovery (PMTUD). When PMTUD is enabled, the client will dynamically adjust packet sizing to optimize connection performance. There is also a new connection status message in the GUI to inform users that the local network connection may be unstable. This will make it easier to diagnose connectivity issues.

Changes and improvements

Fixed an inconsistency with Global WARP override settings in multi-user environments when switching between users.
The GUI now displays the health of the tunnel and DNS connections by showing a connection status message when the network may be unstable. This will make it easier to diagnose connectivity issues.
Fixed an issue where deleting a registration was erroneously reported as having failed.
Path Maximum Transmission Unit Discovery (PMTUD) may now be used to discover the effective MTU of the connection. This allows the WARP client to improve connectivity optimized for each network. PMTUD is disabled by default. To enable it, refer to the PMTUD documentation.
Improvements for the OS version WARP client check. Windows Updated Build Revision (UBR) numbers can now be checked by the client to ensure devices have required security patches and features installed.
The WARP client now supports Windows 11 ARM-based machines. For information on known limitations, refer to the Known limitations page.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices using WARP client 2025.4.929.0 and up may experience Local Domain Fallback failures if a fallback server has not been configured. To configure a fallback server, refer to Route traffic to fallback server.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2025.9.558.0)

Tue, 11 Nov 2025 17:28:35 GMT

A new GA release for the macOS WARP client is now available on the stable releases downloads page.

Changes and improvements

The GUI now displays the health of the tunnel and DNS connections by showing a connection status message when the network may be unstable. This will make it easier to diagnose connectivity issues.
Fixed an issue where deleting a registration was erroneously reported as having failed.
Path Maximum Transmission Unit Discovery (PMTUD) may now be used to discover the effective MTU of the connection. This allows the WARP client to improve connectivity optimized for each network. PMTUD is disabled by default. To enable it, refer to the PMTUD documentation.

Known issues

Devices using WARP client 2025.4.929.0 and up may experience Local Domain Fallback failures if a fallback server has not been configured. To configure a fallback server, refer to Route traffic to fallback server.

Cloudflare One Client - WARP client for Linux (version 2025.9.558.0)

Tue, 11 Nov 2025 15:06:09 GMT

A new GA release for the Linux WARP client is now available on the stable releases downloads page.

Changes and improvements

The GUI now displays the health of the tunnel and DNS connections by showing a connection status message when the network may be unstable. This will make it easier to diagnose connectivity issues.
Fixed an issue where deleting a registration was erroneously reported as having failed.
Path Maximum Transmission Unit Discovery (PMTUD) may now be used to discover the effective MTU of the connection. This allows the WARP client to improve connectivity optimized for each network. PMTUD is disabled by default. To enable it, refer to the PMTUD documentation.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - cloudflared proxy-dns command will be removed starting February 2, 2026

Tue, 11 Nov 2025 00:00:00 GMT

Starting February 2, 2026, the cloudflared proxy-dns command will be removed from all new cloudflared releases.

This change is being made to enhance security and address a potential vulnerability in an underlying DNS library. This vulnerability is specific to the proxy-dns command and does not affect any other cloudflared features, such as the core Cloudflare Tunnel service.

The proxy-dns command, which runs a client-side DNS-over-HTTPS (DoH) proxy, has been an officially undocumented feature for several years. This functionality is fully and securely supported by our actively developed products.

Versions of cloudflared released before this date will not be affected and will continue to operate. However, note that our official support policy for any cloudflared release is one year from its release date.

Migration paths

We strongly advise users of this undocumented feature to migrate to one of the following officially supported solutions before February 2, 2026, to continue benefiting from secure DNS-over-HTTPS.

End-user devices

The preferred method for enabling DNS-over-HTTPS on user devices is the Cloudflare WARP client. The WARP client automatically secures and proxies all DNS traffic from your device, integrating it with your organization's Zero Trust policies and posture checks.

Servers, routers, and IoT devices

For scenarios where installing a client on every device is not possible (such as servers, routers, or IoT devices), we recommend using the WARP Connector.

Instead of running cloudflared proxy-dns on a machine, you can install the WARP Connector on a single Linux host within your private network. This connector will act as a gateway, securely routing all DNS and network traffic from your entire subnet to Cloudflare for filtering and logging.

Workers - Select Wrangler environments using the CLOUDFLARE_ENV environment variable

Sun, 09 Nov 2025 00:00:00 GMT

Wrangler now supports using the CLOUDFLARE_ENV environment variable to select the active environment for your Worker commands. This provides a more flexible way to manage environments, especially when working with build tools and CI/CD pipelines.

What's new

Environment selection via environment variable:

Set CLOUDFLARE_ENV to specify which environment to use for Wrangler commands
Works with all Wrangler commands that support the --env flag
The --env command line argument takes precedence over the CLOUDFLARE_ENV environment variable

Example usage

# Deploy to the production environment using CLOUDFLARE_ENV
CLOUDFLARE_ENV=production wrangler deploy

# Upload a version to the staging environment
CLOUDFLARE_ENV=staging wrangler versions upload

# The --env flag takes precedence over CLOUDFLARE_ENV
CLOUDFLARE_ENV=dev wrangler deploy --env production
# This will deploy to production, not dev

Use with build tools

The CLOUDFLARE_ENV environment variable is particularly useful when working with build tools like Vite. You can set the environment once during the build process, and it will be used for both building and deploying your Worker:

# Set the environment for both build and deploy
CLOUDFLARE_ENV=production npm run build & wrangler deploy

When using @cloudflare/vite-plugin, the build process generates a "redirected deploy config" that is flattened to only contain the active environment. Wrangler will validate that the environment specified matches the environment used during the build to prevent accidentally deploying a Worker built for one environment to a different environment.

Learn more

Workers - Workers automatic tracing, now in open beta

Fri, 07 Nov 2025 00:00:00 GMT

Enable automatic tracing on your Workers, giving you detailed metadata and timing information for every operation your Worker performs.

Tracing helps you identify performance bottlenecks, resolve errors, and understand how your Worker interacts with other services on the Workers platform. You can now answer questions like:

Which calls are slowing down my application?
Which queries to my database take the longest?
What happened within a request that resulted in an error?

You can now:

View traces alongside your logs in the Workers Observability dashboard
Export traces (and correlated logs) to any OTLP-compatible destination ↗︎, such as Honeycomb, Sentry, or Grafana, by configuring a tracing destination in the Cloudflare dashboard ↗︎
Analyze and query across span attributes (operation type, status, duration, errors)

To get started, set:

{
	"observability": {
		"traces": {
			"enabled": true,
		},
	},
}

Want to learn more?

Cloudflare One, Cloudflare WAN - Automatic Return Routing (Beta)

Thu, 06 Nov 2025 00:00:00 GMT

Magic WAN now supports Automatic Return Routing (ARR), allowing customers to configure Magic on-ramps (IPsec/GRE/CNI) to learn the return path for traffic flows without requiring static routes.

Key benefits:

Route-less mode: Static or dynamic routes are optional when using ARR.
Overlapping IP space support: Traffic originating from customer sites can use overlapping private IP ranges.
Symmetric routing: Return traffic is guaranteed to use the same connection as the original on-ramp.

This feature is currently in beta and requires the new Unified Routing mode (beta).

For configuration details, refer to Configure Automatic Return Routing.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Designate WAN link for breakout traffic

Thu, 06 Nov 2025 00:00:00 GMT

Magic WAN Connector now allows you to designate a specific WAN port for breakout traffic, giving you deterministic control over the egress path for latency-sensitive applications.

With this feature, you can:

Pin breakout traffic for specific applications to a preferred WAN port.
Ensure critical traffic (such as Zoom or Teams) always uses your fastest or most reliable connection.
Benefit from automatic failover to standard WAN port priority if the preferred port goes down.

This is useful for organizations with multiple ISP uplinks who need predictable egress behavior for performance-sensitive traffic.

For configuration details, refer to Designate WAN ports for breakout apps.

Gateway - Applications to be remapped to the new categories

Thu, 06 Nov 2025 00:00:00 GMT

We have previously added new application categories to better reflect their content and improve HTTP traffic management: refer to Changelog. While the new categories are live now, we want to ensure you have ample time to review and adjust any existing rules you have configured against old categories. The remapping of existing applications into these new categories will be completed by January 30, 2026. This timeline allows you a dedicated period to:

Review the new category structure.
Identify any policies you have that target the older categories.
Adjust your rules to reference the new, more precise categories before the old mappings change. Once the applications have been fully remapped by January 30, 2026, you might observe some changes in the traffic being mitigated or allowed by your existing policies. We encourage you to use the intervening time to prepare for a smooth transition.

Applications being remappedd

Application Name	Existing Category	New Category
Google Photos	File Sharing	Photography & Graphic Design
Flickr	File Sharing	Photography & Graphic Design
ADP	Human Resources	Business
Greenhouse	Human Resources	Business
myCigna	Human Resources	Health & Fitness
UnitedHealthcare	Human Resources	Health & Fitness
ZipRecruiter	Human Resources	Business
Amazon Business	Human Resources	Business
Jobcenter	Human Resources	Business
Jobsuche	Human Resources	Business
Zenjob	Human Resources	Business
DocuSign	Legal	Business
Postident	Legal	Business
Adobe Creative Cloud	Productivity	Photography & Graphic Design
Airtable	Productivity	Development
Autodesk Fusion360	Productivity	IT Management
Coursera	Productivity	Education
Microsoft Power BI	Productivity	Business
Tableau	Productivity	Business
Duolingo	Productivity	Education
Adobe Reader	Productivity	Business
AnpiReport	Productivity	Travel
ビズリーチ	Productivity	Business
doda (デューダ)	Productivity	Business
求人ボックス	Productivity	Business
マイナビ2026	Productivity	Business
Power Apps	Productivity	Business
RECRUIT AGENT	Productivity	Business
シフトボード	Productivity	Business
スタンバイ	Productivity	Business
Doctolib	Productivity	Health & Fitness
Miro	Productivity	Photography & Graphic Design
MyFitnessPal	Productivity	Health & Fitness
Sentry Mobile	Productivity	Travel
Slido	Productivity	Photography & Graphic Design
Arista Networks	Productivity	IT Management
Atlassian	Productivity	Business
CoderPad	Productivity	Business
eAgreements	Productivity	Business
Vmware	Productivity	IT Management
Vmware Vcenter	Productivity	IT Management
AWS Skill Builder	Productivity	Education
Microsoft Office 365 (GCC)	Productivity	Business
Microsoft Exchange Online (GCC)	Productivity	Business
Canva	Sales & Marketing	Photography & Graphic Design
Instacart	Shopping	Food & Drink
Wawa	Shopping	Food & Drink
McDonald's	Shopping	Food & Drink
Vrbo	Shopping	Travel
American Airlines	Shopping	Travel
Booking.com	Shopping	Travel
Ticketmaster	Shopping	Entertainment & Events
Airbnb	Shopping	Travel
DoorDash	Shopping	Food & Drink
Expedia	Shopping	Travel
EasyPark	Shopping	Travel
UEFA Tickets	Shopping	Entertainment & Events
DHL Express	Shopping	Business
UPS	Shopping	Business

For more information on creating HTTP policies, refer to Applications and app types.

Workers - Capture Wrangler command output in structured format

Mon, 03 Nov 2025 00:00:00 GMT

You can now capture Wrangler command output in a structured ND-JSON ↗︎ format by setting the WRANGLER_OUTPUT_FILE_PATH or WRANGLER_OUTPUT_FILE_DIRECTORY environment variables. This feature is particularly useful for CI/CD pipelines and automation tools that need programmatic access to deployment information such as worker names, version IDs, deployment URLs, and error details. Commands that support this feature include wrangler deploy, wrangler versions upload, wrangler versions deploy, and wrangler pages deploy.

Workers, Durable Objects, Browser Run - Workers WebSocket message size limit increased from 1 MiB to 32 MiB

Fri, 31 Oct 2025 00:00:00 GMT

Workers, including those using Durable Objects and Browser Rendering, may now process WebSocket messages up to 32 MiB in size. Previously, this limit was 1 MiB.

This change allows Workers to handle use cases requiring large message sizes, such as processing Chrome Devtools Protocol messages.

For more information, please see the Durable Objects startup limits.

Workers - Access Workers preview URLs from the Build details page

Thu, 30 Oct 2025 00:00:00 GMT

You can now access preview URLs directly from the build details page, making it easier to test your changes when reviewing builds in the dashboard.

What's new

A Preview button now appears in the top-right corner of the build details page for successful builds
Click it to instantly open the latest preview URL
Matches the same experience you're familiar with from Pages

Access - Access private hostname applications support all ports/protocols

Tue, 28 Oct 2025 00:00:00 GMT

Cloudflare Access for private hostname applications can now secure traffic on all ports and protocols.

Previously, applying Zero Trust policies to private applications required the application to use HTTPS on port 443 and support Server Name Indicator (SNI).

This update removes that limitation. As long as the application is reachable via a Cloudflare off-ramp, you can now enforce your critical security controls — like single sign-on (SSO), MFA, device posture, and variable session lengths — to any private application. This allows you to extend Zero Trust security to services like SSH, RDP, internal databases, and other non-HTTPS applications.

For example, you can now create a self-hosted application in Access for ssh.testapp.local running on port 22. You can then build a policy that only allows engineers in your organization to connect after they pass an SSO/MFA check and are using a corporate device.

This feature is generally available across all plans.

CASB - CASB introduces new granular roles

Tue, 28 Oct 2025 00:00:00 GMT

Cloudflare CASB (Cloud Access Security Broker) now supports two new granular roles to provide more precise access control for your security teams:

Cloudflare CASB Read: Provides read-only access to view CASB findings and dashboards. This role is ideal for security analysts, compliance auditors, or team members who need visibility without modification rights.
Cloudflare CASB: Provides full administrative access to configure and manage all aspects of the CASB product.

These new roles help you better enforce the principle of least privilege. You can now grant specific members access to CASB security findings without assigning them broader permissions, such as the Super Administrator or Administrator roles.

To enable Data Loss Prevention (DLP), scans in CASB, account members will need the Cloudflare Zero Trust role.

You can find these new roles when inviting members or creating API tokens in the Cloudflare dashboard under Manage Account > Members.

To learn more about managing roles and permissions, refer to the Manage account members and roles documentation.

Gateway - New Application Categories added for HTTP Traffic Management

Tue, 28 Oct 2025 00:00:00 GMT

To give you precision and flexibility while creating policies to block unwanted traffic, we are introducing new, more granular application categories in the Gateway product.

We have added the following categories to provide more precise organization and allow for finer-grained policy creation, designed around how users interact with different types of applications:

Business
Education
Entertainment & Events
Food & Drink
Health & Fitness
Lifestyle
Navigation
Photography & Graphic Design
Travel

The new categories are live now, but we are providing a transition period for existing applications to be fully remapped to these new categories.

The full remapping will be completed by January 30, 2026.

We encourage you to use this time to:

Review the new category structure.
Identify and adjust any existing HTTP policies that reference older categories to ensure a smooth transition.

For more information on creating HTTP policies, refer to Applications and app types.

Workers - Automatic resource provisioning for KV, R2, and D1

Fri, 24 Oct 2025 00:00:00 GMT

Previously, if you wanted to develop or deploy a worker with attached resources, you'd have to first manually create the desired resources. Now, if your Wrangler configuration file includes a KV namespace, D1 database, or R2 bucket that does not yet exist on your account, you can develop locally and deploy your application seamlessly, without having to run additional commands.

Automatic provisioning is launching as an open beta, and we'd love to hear your feedback to help us make improvements! It currently works for KV, R2, and D1 bindings. You can disable the feature using the --no-x-provision flag.

To use this feature, update to wrangler@4.45.0 and add bindings to your config file without resource IDs e.g.:

{
	"kv_namespaces": [{ "binding": "MY_KV" }],
	"d1_databases": [{ "binding": "MY_DB" }],
	"r2_buckets": [{ "binding": "MY_R2" }],
}

wrangler dev will then automatically create these resources for you locally, and on your next run of wrangler deploy, Wrangler will call the Cloudflare API to create the requested resources and link them to your Worker.

Though resource IDs will be automatically written back to your Wrangler config file after resource creation, resources will stay linked across future deploys even without adding the resource IDs to the config file. This is especially useful for shared templates, which now no longer need to include account-specific resource IDs when adding a binding.

Workers - Build TanStack Start apps with the Cloudflare Vite plugin

Fri, 24 Oct 2025 00:00:00 GMT

The Cloudflare Vite plugin now supports TanStack Start ↗︎ apps. Get started with new or existing projects.

New projects

Create a new TanStack Start project that uses the Cloudflare Vite plugin via the create-cloudflare CLI:

npm create cloudflare@latest -- my-tanstack-start-app --framework=tanstack-start

yarn create cloudflare my-tanstack-start-app --framework=tanstack-start

pnpm create cloudflare@latest my-tanstack-start-app --framework=tanstack-start

Existing projects

Migrate an existing TanStack Start project to use the Cloudflare Vite plugin:

Install @cloudflare/vite-plugin and wrangler

npm i -D @cloudflare/vite-plugin wrangler

yarn add -D @cloudflare/vite-plugin wrangler

pnpm add -D @cloudflare/vite-plugin wrangler

bun add -d @cloudflare/vite-plugin wrangler

Add the Cloudflare plugin to your Vite config

vite.config.tsts

import { defineConfig } from "vite";
import { tanstackStart } from "@tanstack/react-start/plugin/vite";
import viteReact from "@vitejs/plugin-react";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [
		cloudflare({ viteEnvironment: { name: "ssr" } }),
		tanstackStart(),
		viteReact(),
	],
});

Add your Worker config file

{
	"$schema": "./node_modules/wrangler/config-schema.json",
	"name": "my-tanstack-start-app",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"compatibility_flags": [
		"nodejs_compat"
	],
	"main": "@tanstack/react-start/server-entry"
}

"$schema" = "./node_modules/wrangler/config-schema.json"
name = "my-tanstack-start-app"
# Set this to today's date
compatibility_date = "2026-10-11"
compatibility_flags = [ "nodejs_compat" ]
main = "@tanstack/react-start/server-entry"

Modify the scripts in your package.json

package.jsonjson

{
	"scripts": {
		"dev": "vite dev",
		"build": "vite build && tsc --noEmit",
		"start": "node .output/server/index.mjs",
		"preview": "vite preview",
		"deploy": "npm run build && wrangler deploy",
		"cf-typegen": "wrangler types"
	}
}

See the TanStack Start framework guide for more info.

Workers - Workers Preview URL default behavior now matches your workers.dev setting

Thu, 23 Oct 2025 00:00:00 GMT

We have updated the default behavior for Cloudflare Workers Preview URLs. Going forward, if a preview URL setting is not explicitly configured during deployment, its default behavior will automatically match the setting of your workers.dev subdomain.

This change is intended to provide a more intuitive and secure experience by aligning your preview URL's default state with your workers.dev configuration to prevent cases where a preview URL might remain public even after you disabled your workers.dev route.

What this means for you:

If neither setting is configured: both the workers.dev route and the preview URL will default to enabled
If your workers.dev route is enabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to enabled
If your workers.dev route is disabled and you do not explicitly set Preview URLs to enabled or disabled: Preview URLs will default to disabled

You can override the default setting by explicitly enabling or disabling the preview URL in your Worker's configuration through the API, Dashboard, or Wrangler.

Wrangler Version Behavior

The default behavior depends on the version of Wrangler you are using. This new logic applies to the latest version. Here is a summary of the behavior across different versions:

Before v4.34.0: Preview URLs defaulted to enabled, regardless of the workers.dev setting.
v4.34.0 up to (but not including) v4.44.0: Preview URLs defaulted to disabled, regardless of the workers.dev setting.
v4.44.0 or later: Preview URLs now default to matching your workers.dev setting.

Why we’re making this change

In July, we introduced preview URLs to Workers, which let you preview code changes before deploying to production. This made disabling your Worker’s workers.dev URL an ambiguous action — the preview URL, served as a subdomain of workers.dev (ex: preview-id-worker-name.account-name.workers.dev) would still be live even if you had disabled your Worker’s workers.dev route. If you misinterpreted what it meant to disable your workers.dev route, you might unintentionally leave preview URLs enabled when you didn’t mean to, and expose them to the public Internet.

To address this, we made a one-time update to disable preview URLs on existing Workers that had their workers.dev route disabled and changed the default behavior to be disabled for all new deployments where a preview URL setting was not explicitly configured.

While this change helped secure many customers, it was disruptive for customers who keep their workers.dev route enabled and actively use the preview functionality, as it now required them to explicitly enable preview URLs on every redeployment.This new, more intuitive behavior ensures that your preview URL settings align with your workers.dev configuration by default, providing a more secure and predictable experience.

Securing access to workers.dev and preview URL endpoints

To further secure your workers.dev subdomain and preview URL, you can enable Cloudflare Access with a single click in your Worker's settings to limit access to specific users or groups.

Gateway - Schedule DNS policies from the UI

Mon, 20 Oct 2025 00:00:00 GMT

Admins can now create scheduled DNS policies directly from the Zero Trust dashboard, without using the API. You can configure policies to be active during specific, recurring times, such as blocking social media during business hours or gaming sites on school nights.

Preset Schedules: Use built-in templates for common scenarios like Business Hours, School Days, Weekends, and more.
Custom Schedules: Define your own schedule with specific days and up to three non-overlapping time ranges per day.
Timezone Control: Choose to enforce a schedule in a specific timezone (for example, US Eastern) or based on the local time of each user.
Combined with Duration: Policies can have both a schedule and a duration. If both are set, the duration's expiration takes precedence.

You can see the flow in the demo GIF:

This update makes time-based DNS policies accessible to all Gateway customers, removing the technical barrier of the API.

Email security - On-Demand Security Report

Fri, 17 Oct 2025 22:14:43 GMT

You can now generate on-demand security reports directly from the Cloudflare dashboard. This new feature provides a comprehensive overview of your email security posture, making it easier than ever to demonstrate the value of Cloudflare’s Email security to executives and other decision makers.

These reports offer several key benefits:

Executive Summary: Quickly view the performance of Email security with a high-level executive summary.
Actionable Insights: Dive deep into trend data, breakdowns of threat types, and analysis of top targets to identify and address vulnerabilities.
Configuration Transparency: Gain a clear view of your policy, submission, and domain configurations to ensure optimal setup.
Account Takeover Risks: Get a snapshot of your M365 risky users (requires a Microsoft Entra ID P2 license and M365 SaaS integration ↗︎).

To get started, refer to Download a security report.

This feature is available across the following Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare One Client - WARP client for Windows (version 2025.9.173.1)

Thu, 16 Oct 2025 15:29:54 GMT

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

This release contains minor fixes, improvements, and new features including Path Maximum Transmission Unit Discovery (PMTUD). With PMTUD enabled, the client will dynamically adjust packet sizing to optimize connection performance. There is also a new connection status message in the GUI to inform users that the local network connection may be unstable. This will make it easier to debug connectivity issues.

Changes and improvements

Improvements for Windows multi-user to maintain the Global WARP override state when switching between users.
The GUI now displays the health of the tunnel and DNS connections by showing a connection status message when the network may be unstable. This will make it easier to debug connectivity issues.
Deleting registrations no longer returns an error when succeeding.
Path Maximum Transmission Unit Discovery (PMTUD) is now used to discover the effective MTU of the connection. This allows the client to improve connection performance optimized for the current network.

Known issues

For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.
Devices using WARP client 2025.4.929.0 and up may experience Local Domain Fallback failures if a fallback server has not been configured. To configure a fallback server, refer to Route traffic to fallback server.
Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.
DNS resolution may be broken when the following conditions are all true:
- WARP 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 WARP is connected.
To work around this issue, reconnect the WARP client by toggling off and back on.

Cloudflare One Client - WARP client for macOS (version 2025.9.173.1)

Thu, 16 Oct 2025 15:29:52 GMT

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

Changes and improvements

The GUI now displays the health of the tunnel and DNS connections by showing a connection status message when the network may be unstable. This will make it easier to debug connectivity issues.
Deleting registrations no longer returns an error when succeeding.
Path Maximum Transmission Unit Discovery (PMTUD) is now used to discover the effective MTU of the connection. This allows the client to improve connection performance optimized for the current network.

Known issues

macOS Sequoia: Due to changes Apple introduced in macOS 15.0.x, the WARP client may not behave as expected. Cloudflare recommends the use of macOS 15.4 or later.
Devices using WARP client 2025.4.929.0 and up may experience Local Domain Fallback failures if a fallback server has not been configured. To configure a fallback server, refer to Route traffic to fallback server.

Load Balancing - Monitor Groups for Advanced Health Checking With Load Balancing

Thu, 16 Oct 2025 00:00:00 GMT

Cloudflare Load Balancing now supports Monitor Groups, a powerful new way to combine multiple health monitors into a single, logical group. This allows you to create sophisticated health checks that more accurately reflect the true availability of your applications by assessing multiple services at once.

With Monitor Groups, you can ensure that all critical components of an application are healthy before sending traffic to an origin pool, enabling smarter failover decisions and greater resilience. This feature is now available via the API for customers with an Enterprise Load Balancing subscription.

What you can do:

Combine Multiple Monitors: Group different health monitors (for example, HTTP, TCP) that check various application components, like a primary API gateway and a specific /login service.
Isolate Monitors for Observation: Mark a monitor as "monitoring only" to receive alerts and data without it affecting a pool's health status or traffic steering. This is perfect for testing new checks or observing non-critical dependencies.
Improve Steering Intelligence: Latency for Dynamic Steering is automatically averaged across all active monitors in a group, providing a more holistic view of an origin's performance.

This enhancement is ideal for complex, multi-service applications where the health of one component depends on another. By aggregating health signals, Monitor Groups provide a more accurate and comprehensive assessment of your application's true status.

For detailed information and API configuration guides, please visit our developer documentation for Monitor Groups.

Gateway - New domain categories added

Fri, 10 Oct 2025 00:00:00 GMT

We have added three new domain categories under the Technology parent category, to better reflect online content and improve DNS filtering.

New categories added

Parent ID	Parent Name	Category ID	Category Name
26	Technology	194	Keep Awake Software
26	Technology	192	Remote Access
26	Technology	193	Shareware/Freeware

Refer to Gateway domain categories to learn more.

Workers - Worker startup time limit increased to 1 second

Fri, 10 Oct 2025 00:00:00 GMT

You can now upload a Worker that takes up 1 second to parse and execute its global scope. Previously, startup time was limited to 400 ms.

This allows you to run Workers that import more complex packages and execute more code prior to requests being handled.

For more information, see the documentation on Workers startup limits.

Workers - You can now deploy full-stack apps on Workers using Terraform

Thu, 09 Oct 2025 00:00:00 GMT

You can now upload Workers with static assets (like HTML, CSS, JavaScript, images) with the Cloudflare Terraform provider v5.11.0 ↗︎, making it even easier to deploy and manage full-stack apps with IaC.

Previously, you couldn't use Terraform to upload static assets without writing custom scripts to handle generating an asset manifest, calling the Cloudflare API to upload assets in chunks, and handling change detection.

Now, you simply define the directory where your assets are built, and we handle the rest. Check out the examples for what this looks like in Terraform configuration.

You can get started today with the Cloudflare Terraform provider (v5.11.0) ↗︎, using either the existing cloudflare_workers_script resource ↗︎, or the beta cloudflare_worker_version resource ↗︎.

Examples

With `cloudflare_workers_script`

Here's how you can use the existing cloudflare_workers_script ↗︎ resource to upload your Worker code and assets in one shot.

resource "cloudflare_workers_script" "my_app" {
  account_id  = var.account_id
  script_name = "my-app"

  content_file   = "./dist/worker/index.js"
  content_sha256 = filesha256("./dist/worker/index.js")
  main_module    = "index.js"

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }
}

With `cloudflare_worker`, `cloudflare_worker_version`, and `cloudflare_workers_deployment`

And here's an example using the beta cloudflare_worker_version ↗︎ resource, alongside the cloudflare_worker ↗︎ and cloudflare_workers_deployment ↗︎ resources:


# This tracks the existence of your Worker, so that you
# can upload code and assets separately from tracking Worker state.

resource "cloudflare_worker" "my_app" {
  account_id = var.account_id
  name       = "my-app"
}

resource "cloudflare_worker_version" "my_app_version" {
  account_id = var.account_id
  worker_id  = cloudflare_worker.my_app.id

  # Just point to your assets directory - that's it!
  assets = {
    directory = "./dist/static"
  }

  modules = [{
    name         = "index.js"
    content_file = "./dist/worker/index.js"
    content_type = "application/javascript+module"
  }]
}

resource "cloudflare_workers_deployment" "my_app_deployment" {
  account_id  = var.account_id
  script_name = cloudflare_worker.my_app.name

  strategy = "percentage"
  versions = [{
    version_id = cloudflare_worker_version.my_app_version.id
    percentage = 100
  }]
}

What's changed

Under the hood, the Cloudflare Terraform provider now handles the same logic that Wrangler uses for static asset uploads. This includes scanning your assets directory, computing hashes for each file, generating a manifest with file metadata, and calling the Cloudflare API to upload any missing files in chunks. We support large directories with parallel uploads and chunking, and when the asset manifest hash changes, we detect what's changed and trigger an upload for only those changed files.

Try it out

Get started with the Cloudflare Terraform provider (v5.11.0) ↗︎
You can use either the existing cloudflare_workers_script resource ↗︎ to upload your Worker code and assets in one resource.
Or you can use the new beta cloudflare_worker_version resource ↗︎ (along with the cloudflare_worker ↗︎ and cloudflare_workers_deployment ↗︎) resources to more granularly control the lifecycle of each Worker resource.

Workers - You can now deploy and manage Workflows in Terraform

Thu, 09 Oct 2025 00:00:00 GMT

You can now create and manage Workflows using Terraform, now supported in the Cloudflare Terraform provider v5.11.0 ↗︎. Workflows allow you to build durable, multi-step applications -- without needing to worry about retrying failed tasks or managing infrastructure.

Now, you can deploy and manage Workflows through Terraform using the new cloudflare_workflow resource ↗︎:

resource "cloudflare_workflow" "my_workflow" {
  account_id    = var.account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = "my-worker"
}

Examples

Here are full examples of how to configure cloudflare_workflow in Terraform, using the existing cloudflare_workers_script resource ↗︎, and the beta cloudflare_worker_version resource ↗︎.

With `cloudflare_workflow` and `cloudflare_workers_script`

resource "cloudflare_workers_script" "workflow_worker" {
  account_id  = var.cloudflare_account_id
  script_name = "my-workflow-worker"

  content_file   = "${path.module}/../dist/worker/index.js"
  content_sha256 = filesha256("${path.module}/../dist/worker/index.js")
  main_module    = "index.js"
}

resource "cloudflare_workflow" "workflow" {
  account_id    = var.cloudflare_account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = cloudflare_workers_script.workflow_worker.script_name
}

With `cloudflare_workflow`, and the new beta resources

You can more granularly control the lifecycle of each Worker resource using the beta cloudflare_worker_version ↗︎ resource, alongside the cloudflare_worker ↗︎ and cloudflare_workers_deployment ↗︎ resources.


resource "cloudflare_worker" "workflow_worker" {
  account_id = var.cloudflare_account_id
  name       = "my-workflow-worker"
}

resource "cloudflare_worker_version" "workflow_worker_version" {
  account_id = var.cloudflare_account_id
  worker_id  = cloudflare_worker.workflow_worker.id

  main_module         = "index.js"

  modules = [{
    name         = "index.js"
    content_file = "${path.module}/../dist/worker/index.js"
    content_type = "application/javascript+module"
  }]
}

resource "cloudflare_workers_deployment" "workflow_deployment" {
  account_id  = var.cloudflare_account_id
  script_name = cloudflare_worker.workflow_worker.name

  strategy = "percentage"
  versions = [{
    version_id = cloudflare_worker_version.workflow_worker_version.id
    percentage = 100
  }]
}

resource "cloudflare_workflow" "my_workflow" {
  account_id    = var.cloudflare_account_id
  workflow_name = "my-workflow"
  class_name    = "MyWorkflow"
  script_name   = cloudflare_worker.workflow_worker.name
}

Try it out

Get started with the Cloudflare Terraform provider (v5.11.0) ↗︎ and the new cloudflare_workflow resource ↗︎.

Workers - New Overview Page for Cloudflare Workers

Tue, 07 Oct 2025 00:00:00 GMT

Each of your Workers now has a new overview page in the Cloudflare dashboard.

The goal is to make it easier to understand your Worker without digging through multiple tabs. Think of it as a new home base, a place to get a high-level overview on what's going on.

It's the first place you land when you open a Worker in the dashboard, and it gives you an immediate view of what’s going on. You can see requests, errors, and CPU time at a glance. You can view and add bindings, and see recent versions of your app, including who published them.

Navigation is also simpler, with visually distinct tabs at the top of the page. At the bottom right you'll find guided steps for what to do next that are based on the state of your Worker, such as adding a binding or connecting a custom domain.

We plan to add more here over time. Better insights, more controls, and ways to manage your Worker from one page.

If you have feedback or suggestions for the new Overview page or your Cloudflare Workers experience in general, we'd love to hear from you. Join the Cloudflare developer community on Discord ↗︎.

Workers - One-click Cloudflare Access for Workers

Fri, 03 Oct 2025 00:00:00 GMT

You can now enable Cloudflare Access for your workers.dev and Preview URLs in a single click.

Access allows you to limit access to your Workers to specific users or groups. You can limit access to yourself, your teammates, your organization, or anyone else you specify in your Access policy.

To enable Cloudflare Access:

In the Cloudflare dashboard, go to the Workers & Pages page.
Go to Workers & Pages ↗
In Overview, select your Worker.
Go to Settings > Domains & Routes.
For workers.dev or Preview URLs, click Enable Cloudflare Access.
Optionally, to configure the Access application, click Manage Cloudflare Access. There, you can change the email addresses you want to authorize. View Access policies to learn about configuring alternate rules.

To fully secure your application, it is important that you validate the JWT that Cloudflare Access adds to the Cf-Access-Jwt-Assertion header on the incoming request.

The following code will validate the JWT using the jose NPM package ↗︎:

import { jwtVerify, createRemoteJWKSet } from "jose";

export default {
	async fetch(request, env, ctx) {
		// Verify the POLICY_AUD environment variable is set
		if (!env.POLICY_AUD) {
			return new Response("Missing required audience", {
				status: 403,
				headers: { "Content-Type": "text/plain" },
			});
		}

		// Get the JWT from the request headers
		const token = request.headers.get("cf-access-jwt-assertion");

		// Check if token exists
		if (!token) {
			return new Response("Missing required CF Access JWT", {
				status: 403,
				headers: { "Content-Type": "text/plain" },
			});
		}

		try {
			// Create JWKS from your team domain
			const JWKS = createRemoteJWKSet(
				new URL(`${env.TEAM_DOMAIN}/cdn-cgi/access/certs`),
			);

			// Verify the JWT
			const { payload } = await jwtVerify(token, JWKS, {
				issuer: env.TEAM_DOMAIN,
				audience: env.POLICY_AUD,
			});

			// Token is valid, proceed with your application logic
			return new Response(`Hello ${payload.email || "authenticated user"}!`, {
				headers: { "Content-Type": "text/plain" },
			});
		} catch (error) {
			// Token verification failed
			return new Response(`Invalid token: ${error.message}`, {
				status: 403,
				headers: { "Content-Type": "text/plain" },
			});
		}
	},
};

Required environment variables

Add these environment variables to your Worker:

POLICY_AUD: Your application's AUD tag
TEAM_DOMAIN: https://<your-team-name>.cloudflareaccess.com

Both of these appear in the modal that appears when you enable Cloudflare Access.

You can set these variables by adding them to your Worker's Wrangler configuration file, or via the Cloudflare dashboard under Workers & Pages > your-worker > Settings > Environment Variables.

Cloudflare Fundamentals, Access - Fine-grained Permissioning for Access for Apps, IdPs, & Targets now in Public Beta

Thu, 02 Oct 2025 00:00:00 GMT

Fine-grained permissions for Access Applications, Identity Providers (IdPs), and Targets is now available in Public Beta. This expands our RBAC model beyond account & zone-scoped roles, enabling administrators to grant permissions scoped to individual resources.

What's New

Access Applications ↗︎: Grant admin permissions to specific Access Applications.
Identity Providers ↗︎: Grant admin permissions to individual Identity Providers.
Targets ↗︎: Grant admin rights to specific Targets

For more info:

Workers Analytics Engine, Workers - Workers Analytics Engine adds supports for new SQL functions

Thu, 02 Oct 2025 00:00:00 GMT

You can now perform more powerful queries directly in Workers Analytics Engine ↗︎ with a major expansion of our SQL function library.

Workers Analytics Engine allows you to ingest and store high-cardinality data at scale (such as custom analytics) and query your data through a simple SQL API.

Today, we've expanded Workers Analytics Engine's SQL capabilities with several new functions:

New aggregate functions: ↗︎

argMin() - Returns the value associated with the minimum in a group
argMax() - Returns the value associated with the maximum in a group
topK() - Returns an array of the most frequent values in a group
topKWeighted() - Returns an array of the most frequent values in a group using weights
first_value() - Returns the first value in an ordered set of values within a partition
last_value() - Returns the last value in an ordered set of values within a partition

New bit functions: ↗︎

bitAnd() - Returns the bitwise AND of two expressions
bitCount() - Returns the number of bits set to one in the binary representation of a number
bitHammingDistance() - Returns the number of bits that differ between two numbers
bitNot() - Returns a number with all bits flipped
bitOr() - Returns the inclusive bitwise OR of two expressions
bitRotateLeft() - Rotates all bits in a number left by specified positions
bitRotateRight() - Rotates all bits in a number right by specified positions
bitShiftLeft() - Shifts all bits in a number left by specified positions
bitShiftRight() - Shifts all bits in a number right by specified positions
bitTest() - Returns the value of a specific bit in a number
bitXor() - Returns the bitwise exclusive-or of two expressions

New mathematical functions: ↗︎

abs() - Returns the absolute value of a number
log() - Computes the natural logarithm of a number
round() - Rounds a number to a specified number of decimal places
ceil() - Rounds a number up to the nearest integer
floor() - Rounds a number down to the nearest integer
pow() - Returns a number raised to the power of another number

New string functions: ↗︎

lowerUTF8() - Converts a string to lowercase using UTF-8 encoding
upperUTF8() - Converts a string to uppercase using UTF-8 encoding

New encoding functions: ↗︎

hex() - Converts a number to its hexadecimal representation
bin() - Converts a string to its binary representation

New type conversion functions: ↗︎

toUInt8() - Converts any numeric expression, or expression resulting in a string representation of a decimal, into an unsigned 8 bit integer

Ready to get started?

Data Loss Prevention - Expanded File Type Controls for Executables and Disk Images

Wed, 01 Oct 2025 00:00:00 GMT

You can now enhance your security posture by blocking additional application installer and disk image file types with Cloudflare Gateway. Preventing the download of unauthorized software packages is a critical step in securing endpoints from malware and unwanted applications.

We have expanded Gateway's file type controls to include:

Apple Disk Image (dmg)
Microsoft Software Installer (msix, appx)
Apple Software Package (pkg)

You can find these new options within the Upload File Types and Download File Types selectors when creating or editing an HTTP policy. The file types are categorized as follows:

System: Apple Disk Image (dmg)
Executable: Microsoft Software Installer (msix), Microsoft Software Installer (appx), Apple Software Package (pkg)

To ensure these file types are blocked effectively, please note the following behaviors:

DMG: Due to their file structure, DMG files are blocked at the very end of the transfer. A user's download may appear to progress but will fail at the last moment, preventing the browser from saving the file.
MSIX: To comprehensively block Microsoft Software Installers, you should also include the file type Unscannable. MSIX files larger than 100 MB are identified as Unscannable ZIP files during inspection.

To get started, go to your HTTP policies in Zero Trust. For a full list of file types, refer to supported file types.

Gateway - Application granular controls for operations in SaaS applications

Tue, 30 Sep 2025 00:00:00 GMT

Gateway users can now apply granular controls to their file sharing and AI chat applications through HTTP policies.

The new feature offers two methods of controlling SaaS applications:

Application Controls are curated groupings of Operations which provide an easy way for users to achieve a specific outcome. Application Controls may include Upload, Download, Prompt, Voice, and Share depending on the application.
Operations are controls aligned to the most granular action a user can take. This provides a fine-grained approach to enforcing policy and generally aligns to the SaaS providers API specifications in naming and function.

Get started using Application Granular Controls and refer to the list of supported applications.

Workers - Automatic loopback bindings via ctx.exports

Fri, 26 Sep 2025 00:00:00 GMT

The ctx.exports API contains automatically-configured bindings corresponding to your Worker's top-level exports. For each top-level export extending WorkerEntrypoint, ctx.exports will contain a Service Binding by the same name, and for each export extending DurableObject (and for which storage has been configured via a migration), ctx.exports will contain a Durable Object namespace binding. This means you no longer have to configure these bindings explicitly in wrangler.jsonc/wrangler.toml.

Example:

import { WorkerEntrypoint } from "cloudflare:workers";

export class Greeter extends WorkerEntrypoint {
  greet(name) {
    return `Hello, ${name}!`;
  }
}

export default {
  async fetch(request, env, ctx) {
    let greeting = await ctx.exports.Greeter.greet("World")
    return new Response(greeting);
  }
}

At present, you must use the enable_ctx_exports compatibility flag to enable this API, though it will be on by default in the future.

See the API reference for more information.

Gateway, Data Loss Prevention - Refine DLP Scans with New Body Phase Selector

Thu, 25 Sep 2025 00:00:00 GMT

You can now more precisely control your HTTP DLP policies by specifying whether to scan the request or response body, helping to reduce false positives and target specific data flows.

In the Gateway HTTP policy builder, you will find a new selector called Body Phase. This allows you to define the direction of traffic the DLP engine will inspect:

Request Body: Scans data sent from a user's machine to an upstream service. This is ideal for monitoring data uploads, form submissions, or other user-initiated data exfiltration attempts.
Response Body: Scans data sent to a user's machine from an upstream service. Use this to inspect file downloads and website content for sensitive data.

For example, consider a policy that blocks Social Security Numbers (SSNs). Previously, this policy might trigger when a user visits a website that contains example SSNs in its content (the response body). Now, by setting the Body Phase to Request Body, the policy will only trigger if the user attempts to upload or submit an SSN, ignoring the content of the web page itself.

All policies without this selector will continue to scan both request and response bodies to ensure continued protection.

For more information, refer to Gateway HTTP policy selectors.

Email security - Invalid Submissions Feedback

Tue, 23 Sep 2025 23:11:49 GMT

Email security relies on your submissions to continuously improve our detection models. However, we often receive submissions in formats that cannot be ingested, such as incomplete EMLs, screenshots, or text files.

To ensure all customer feedback is actionable, we have launched two new features to manage invalid submissions sent to our team and user submission aliases:

Email Notifications: We now automatically notify users by email when they provide an invalid submission, educating them on the correct format. To disable notifications, go to Settings ↗︎ > Invalid submission emails and turn the feature off.

Invalid Submission dashboard: You can quickly identify which users need education to provide valid submissions so Cloudflare can provide continuous protection.

Learn more about this feature on invalid submissions.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Workers - Improved support for running multiple Workers with `wrangler dev`

Tue, 23 Sep 2025 00:00:00 GMT

You can run multiple Workers in a single dev command by passing multiple config files to wrangler dev:

wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc

Previously, if you ran the command above and then also ran wrangler dev for a different Worker, the Workers running in separate wrangler dev sessions could not communicate with each other. This prevented you from being able to use Service Bindings ↗︎ and Tail Workers ↗︎ in local development, when running separate wrangler dev sessions.

Now, the following works as expected:

# Terminal 1: Run your application that includes both Web and API workers
wrangler dev --config ./web/wrangler.jsonc --config ./api/wrangler.jsonc

# Terminal 2: Run your auth worker separately
wrangler dev --config ./auth/wrangler.jsonc

These Workers can now communicate with each other across separate dev commands, regardless of your development setup.

./api/src/index.tsjs

export default {
	async fetch(request, env) {
		// This service binding call now works across dev commands
		const authorized = await env.AUTH.isAuthorized(request);

		if (!authorized) {
			return new Response("Unauthorized", { status: 401 });
		}

		return new Response("Hello from API Worker!", { status: 200 });
	},
};

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

Access - Access Remote Desktop Protocol (RDP) destinations securely from your browser — now generally available!

Mon, 22 Sep 2025 00:00:00 GMT

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

Since we announced our open beta, we've made a few improvements:

Support for targets with IPv6.
Support for Magic WAN and WARP Connector as on-ramps.
More robust error messaging on the login page to help you if you encounter an issue.
Worldwide keyboard support. Whether your day-to-day is in Portuguese, Chinese, or something in between, your browser-based RDP experience will look and feel exactly like you are using a desktop RDP client.
Cleaned up some other miscellaneous issues, including but not limited to enhanced support for Entra ID accounts and support for usernames with spaces, quotes, and special characters.

As a refresher, here are some benefits browser-based RDP provides:

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.

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

Workers - Rate Limiting in Workers is now GA

Fri, 19 Sep 2025 00:00:00 GMT

Rate Limiting within Cloudflare Workers is now Generally Available (GA).

The ratelimit binding is now stable and recommended for all production workloads. Existing deployments using the unsafe binding will continue to function to allow for a smooth transition.

For more details, refer to Workers Rate Limiting documentation.

Workers - Panic Recovery for Rust Workers

Fri, 19 Sep 2025 00:00:00 GMT

In workers-rs ↗︎, Rust panics were previously non-recoverable. A panic would put the Worker into an invalid state, and further function calls could result in memory overflows or exceptions.

Now, when a panic occurs, in-flight requests will throw 500 errors, but the Worker will automatically and instantly recover for future requests.

This ensures more reliable deployments. Automatic panic recovery is enabled for all new workers-rs deployments as of version 0.6.5, with no configuration required.

Fixing Rust Panics with Wasm Bindgen

Rust Workers are built with Wasm Bindgen, which treats panics as non-recoverable. After a panic, the entire Wasm application is considered to be in an invalid state.

We now attach a default panic handler in Rust:

std::panic::set_hook(Box::new(move |panic_info| {
  hook_impl(panic_info);
}));

Which is registered by default in the JS initialization:

import { setPanicHook } from "./index.js";
setPanicHook(function (err) {
	console.error("Panic handler!", err);
});

When a panic occurs, we reset the Wasm state to revert the Wasm application to how it was when the application started.

Resetting VM State in Wasm Bindgen

We worked upstream on the Wasm Bindgen project to implement a new --experimental-reset-state-function compilation option ↗︎ which outputs a new __wbg_reset_state function.

This function clears all internal state related to the Wasm VM, and updates all function bindings in place to reference the new WebAssembly instance.

One other necessary change here was associating Wasm-created JS objects with an instance identity. If a JS object created by an earlier instance is then passed into a new instance later on, a new "stale object" error is specially thrown when using this feature.

Layered Solution

Building on this new Wasm Bindgen feature, layered with our new default panic handler, we also added a proxy wrapper to ensure all top-level exported class instantiations (such as for Rust Durable Objects) are tracked and fully reinitialized when resetting the Wasm instance. This was necessary because the workerd runtime will instantiate exported classes, which would then be associated with the Wasm instance.

This approach now provides full panic recovery for Rust Workers on subsequent requests.

Of course, we never want panics, but when they do happen they are isolated and can be investigated further from the error logs - avoiding broader service disruption.

WebAssembly Exception Handling

In the future, full support for recoverable panics could be implemented without needing reinitialization at all, utilizing the WebAssembly Exception Handling ↗︎ proposal, part of the newly announced WebAssembly 3.0 ↗︎ specification. This would allow unwinding panics as normal JS errors, and concurrent requests would no longer fail.

We're making significant improvements to the reliability of Rust Workers ↗︎. Join us in #rust-on-workers on the Cloudflare Developers Discord ↗︎ to stay updated.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Connect and secure any private or public app by hostname, not IP — with hostname routing for Cloudflare Tunnel

Thu, 18 Sep 2025 00:00:00 GMT

You can now route private traffic to Cloudflare Tunnel based on a hostname or domain, moving beyond the limitations of IP-based routing. This new capability is free for all Cloudflare One customers.

Previously, Tunnel routes could only be defined by IP address or CIDR range. This created a challenge for modern applications with dynamic or ephemeral IP addresses, often forcing administrators to maintain complex and brittle IP lists.

What’s new:

Hostname & Domain Routing: Create routes for individual hostnames (e.g., payroll.acme.local) or entire domains (e.g., *.acme.local) and direct their traffic to a specific Tunnel.
Simplified Zero Trust Policies: Build resilient policies in Cloudflare Access and Gateway using stable hostnames, making it dramatically easier to apply per-resource authorization for your private applications.
Precise Egress Control: Route traffic for public hostnames (e.g., bank.example.com) through a specific Tunnel to enforce a dedicated source IP, solving the IP allowlist problem for third-party services.
No More IP Lists: This feature makes the workaround of maintaining dynamic IP Lists for Tunnel connections obsolete.

Get started in the Tunnels section of the Zero Trust dashboard with your first private hostname or public hostname route.

Learn more in our blog post ↗︎.

Workers - Increased vCPU for Workers Builds on paid plans

Thu, 18 Sep 2025 00:00:00 GMT

We recently increased the available disk space from 8 GB to 20 GB for all plans. Building on that improvement, we’re now doubling the CPU power available for paid plans — from 2 vCPU to 4 vCPU.

These changes continue our focus on making Workers Builds faster and more reliable.

Metric	Free Plan	Paid Plans
CPU	2 vCPU	4 vCPU

Performance Improvements

Fast build times: Even single-threaded workloads benefit from having more vCPUs
2x faster multi-threaded builds: Tools like esbuild ↗︎ and webpack ↗︎ can now utilize additional cores, delivering near-linear performance scaling

All other build limits — including memory, build minutes, and timeout remain unchanged.

Workers - Preview URLs now default to opt-in

Wed, 17 Sep 2025 00:00:00 GMT

To prevent the accidental exposure of applications, we've updated how Worker preview URLs (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) are handled. We made this change to ensure preview URLs are only active when intentionally configured, improving the default security posture of your Workers.

One-Time Update for Workers with workers.dev Disabled

We performed a one-time update to disable preview URLs for existing Workers where the workers.dev subdomain was also disabled.

Because preview URLs were historically enabled by default, users who had intentionally disabled their workers.dev route may not have realized their Worker was still accessible at a separate preview URL. This update was performed to ensure that using a preview URL is always an intentional, opt-in choice.

If your Worker was affected, its preview URL (<PREVIEW>-<WORKER_NAME>.<SUBDOMAIN>.workers.dev) will now direct to an informational page explaining this change.

How to Re-enable Your Preview URL

If your preview URL was disabled, you can re-enable it via the Cloudflare dashboard by navigating to your Worker's Settings page and toggling on the Preview URL.

Alternatively, you can use Wrangler by adding the preview_urls = true setting to your Wrangler file and redeploying the Worker.

{
  "preview_urls": true
}

preview_urls = true

Note: You can set preview_urls = true with any Wrangler version that supports the preview URL flag (v3.91.0+). However, we recommend updating to v4.34.0 or newer, as this version defaults preview_urls to false, ensuring preview URLs are always enabled by explicit choice.

Cloudflare One - New AI-Enabled Search for Zero Trust Dashboard

Tue, 16 Sep 2025 00:00:00 GMT

Zero Trust Dashboard has a brand new, AI-powered search functionality. You can search your account by resources (applications, policies, device profiles, settings, etc.), pages, products, and more.

Ask Cloudy — You can also ask Cloudy, our AI agent, questions about Cloudflare Zero Trust. Cloudy is trained on our developer documentation and implementation guides, so it can tell you how to configure functionality, best practices, and can make recommendations.

Cloudy can then stay open with you as you move between pages to build configuration or answer more questions.

Find Recents — Recent searches and Cloudy questions also have a new tab under Zero Trust Overview.

Workers - Remote bindings GA - Connect to remote resources (D1, KV, R2, etc.) during local development

Tue, 16 Sep 2025 00:00:00 GMT

Three months ago we announced the public beta of remote bindings for local development. Now, we're excited to say that it's available for everyone in Wrangler, Vite, and Vitest without using an experimental flag!

With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

Example configuration

To enable remote bindings, add "remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

{
	"name": "my-worker",
	// Set this to today's date
	"compatibility_date": "2026-10-11",

	"r2_buckets": [
		{
			"bucket_name": "screenshots-bucket",
			"binding": "screenshots_bucket",
			"remote": true,
		},
	],
}

name = "my-worker"
# Set this to today's date
compatibility_date = "2026-10-11"

[[r2_buckets]]
bucket_name = "screenshots-bucket"
binding = "screenshots_bucket"
remote = true

When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

You can try out remote bindings for local development today with:

Email security - Regional Email Processing for Germany, India, or Australia

Thu, 11 Sep 2025 23:15:00 GMT

We’re excited to announce that Email security customers can now choose their preferred mail processing location directly from the UI when onboarding a domain. This feature is available for the following onboarding methods: MX, BCC, and Journaling.

What’s new

Customers can now select where their email is processed. The following regions are supported:

Germany
India
Australia

Global processing remains the default option, providing flexibility to meet both compliance requirements or operational preferences.

How to use it

When onboarding a domain with MX, BCC, or Journaling:

Select the desired processing location (Germany, India, or Australia).
The UI will display updated processing addresses specific to that region.
For MX onboarding, if your domain is managed by Cloudflare, you can automatically update MX records directly from the UI.

Availability

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

What’s next

We’re expanding the list of processing locations to match our Data Localization Suite (DLS) footprint, giving customers the broadest set of regional options in the market without the complexity of self-hosting.

Gateway, Cloudflare WAN, Cloudflare Tunnel for SASE - DNS filtering for private network onramps

Thu, 11 Sep 2025 00:00:00 GMT

Magic WAN and WARP Connector users can now securely route their DNS traffic to the Gateway resolver without exposing traffic to the public Internet.

Routing DNS traffic to the Gateway resolver allows DNS resolution and filtering for traffic coming from private networks while preserving source internal IP visibility. This ensures Magic WAN users have full integration with our Cloudflare One features, including Internal DNS and hostname-based policies.

To configure DNS filtering, change your Magic WAN or WARP Connector DNS settings to use Cloudflare's shared resolver IPs, 172.64.36.1 and 172.64.36.2. Once you configure DNS resolution and filtering, you can use Source Internal IP as a traffic selector in your resolver policies for routing private DNS traffic to your Internal DNS.

Workers - Worker version rollback limit increased from 10 to 100

Thu, 11 Sep 2025 00:00:00 GMT

The number of recent versions available for a Worker rollback has been increased from 10 to 100.

This allows you to:

Promote any of the 100 most recent versions to be the active deployment.
Split traffic using gradual deployments between your latest code and any of the 100 most recent versions.

You can do this through the Cloudflare dashboard or with Wrangler's rollback command

Learn more about versioned deployments and rollbacks.

Workers - Built with Cloudflare button

Wed, 10 Sep 2025 00:00:00 GMT

We've updated our "Built with Cloudflare" button to make it easier to share that you're building on Cloudflare with the world. Embed it in your project's README, blog post, or wherever you want to let people know.

Check out the documentation for usage information.

Workers - Deploy static sites to Workers without a configuration file

Tue, 09 Sep 2025 00:00:00 GMT

Deploying static site to Workers is now easier. When you run wrangler deploy [directory] or wrangler deploy --assets [directory] without an existing configuration file, Wrangler CLI now guides you through the deployment process with interactive prompts.

Before and after

Before: Required remembering multiple flags and parameters

wrangler deploy --assets ./dist --compatibility-date 2025-09-09 --name my-project

After: Simple directory deployment with guided setup

wrangler deploy dist
# Interactive prompts handle the rest as shown in the example flow below

What's new

Interactive prompts for missing configuration:

Wrangler detects when you're trying to deploy a directory of static assets
Prompts you to confirm the deployment type
Asks for a project name (with smart defaults)
Automatically sets the compatibility date to today

Automatic configuration generation:

Creates a wrangler.jsonc file with your deployment settings
Stores your choices for future deployments
Eliminates the need to remember complex command-line flags

Example workflow

# Deploy your built static site
wrangler deploy dist

# Wrangler will prompt:
✔ It looks like you are trying to deploy a directory of static assets only. Is this correct? … yes
✔ What do you want to name your project? … my-astro-site

# Automatically generates a wrangler.jsonc file and adds it to your project:
{
  "name": "my-astro-site",
  "compatibility_date": "2025-09-09",
  "assets": {
    "directory": "dist"
  }
}

# Next time you run wrangler deploy, this will use the configuration in your newly generated wrangler.jsonc file
wrangler deploy

Requirements

You must use Wrangler version 4.24.4 or later in order to use this feature

Cloudflare WAN - Custom IKE ID for IPsec Tunnels

Mon, 08 Sep 2025 00:00:00 GMT

Now, Magic WAN customers can configure a custom IKE ID for their IPsec tunnels. Customers that are using Magic WAN and a VeloCloud SD-WAN device together can utilize this new feature to create a high availability configuration.

This feature is available via API only. Customers can read the Magic WAN documentation to learn more about the Custom IKE ID feature and the API call to configure it.

Cloudflare WAN - Bidirectional tunnel health checks are compatible with all Magic on-ramps

Fri, 05 Sep 2025 00:00:00 GMT

All bidirectional tunnel health check return packets are accepted by any Magic on-ramp.

Previously, when a Magic tunnel had a bidirectional health check configured, the bidirectional health check would pass when the return packets came back to Cloudflare over the same tunnel that was traversed by the forward packets.

There are SD-WAN devices, like VeloCloud, that do not offer controls to steer traffic over one tunnel versus another in a high availability tunnel configuration.

Now, when a Magic tunnel has a bidirectional health check configured, the bidirectional health check will pass when the return packet traverses over any tunnel in a high availability configuration.

Workers, Workers for Platforms - Increased static asset limits for Workers

Thu, 04 Sep 2025 00:00:00 GMT

You can now upload up to 100,000 static assets per Worker version

Paid and Workers for Platforms users can now upload up to 100,000 static assets per Worker version, a 5x increase from the previous limit of 20,000.
Customers on the free plan still have the same limit as before — 20,000 static assets per version of your Worker
The individual file size limit of 25 MiB remains unchanged for all customers.

This increase allows you to build larger applications with more static assets without hitting limits.

Wrangler

To take advantage of the increased limits, you must use Wrangler version 4.34.0 or higher. Earlier versions of Wrangler will continue to enforce the previous 20,000 file limit.

Learn more

For more information about Workers static assets, see the Static Assets documentation and Platform Limits.

Workers - A new, simpler REST API for Cloudflare Workers (Beta)

Thu, 04 Sep 2025 00:00:00 GMT

You can now manage Workers, Versions, and Deployments as separate resources with a new, resource-oriented API (Beta).

This new API is supported in the Cloudflare Terraform provider ↗︎ and the Cloudflare Typescript SDK ↗︎, allowing platform teams to manage a Worker's infrastructure in Terraform, while development teams handle code deployments from a separate repository or workflow. We also designed this API with AI agents in mind, as a clear, predictable structure is essential for them to reliably build, test, and deploy applications.

Try it out

New beta API endpoints
Cloudflare TypeScript SDK v5.0.0 ↗︎
Cloudflare Go SDK v6.0.0 ↗︎
Terraform provider v5.9.0 ↗︎: cloudflare_worker ↗︎ , cloudflare_worker_version ↗︎, and cloudflare_workers_deployments ↗︎ resources.
See full examples in our Infrastructure as Code (IaC) guide

Before: Eight+ endpoints with mixed responsibilities

The existing API was originally designed for simple, one-shot script uploads:

curl -X PUT "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/workers/scripts/$SCRIPT_NAME" \
    -H "X-Auth-Email: $CLOUDFLARE_EMAIL" \
    -H "X-Auth-Key: $CLOUDFLARE_API_KEY" \
    -H "Content-Type: multipart/form-data" \
    -F 'metadata={
      "main_module": "worker.js",
      "compatibility_date": "$today$"
    }' \
    -F "worker.js=@worker.js;type=application/javascript+module"

This API worked for creating a basic Worker, uploading all of its code, and deploying it immediately — but came with challenges:

A Worker couldn't exist without code: To create a Worker, you had to upload its code in the same API request. This meant platform teams couldn't provision Workers with the proper settings, and then hand them off to development teams to deploy the actual code.
Several endpoints implicitly created deployments: Simple updates like adding a secret or changing a script's content would implicitly create a new version and immediately deploy it.
Updating a setting was confusing: Configuration was scattered across eight endpoints with overlapping responsibilities. This ambiguity made it difficult for human developers (and even more so for AI agents) to reliably update a Worker via API.
Scripts used names as primary identifiers: This meant simple renames could turn into a risky migration, requiring you to create a brand new Worker and update every reference. If you were using Terraform, this could inadvertently destroy your Worker altogether.

After: Three resources with clear boundaries

The new API introduces cleaner resource management with three core resources: Worker, Versions, and Deployment.

All endpoints now use simple JSON payloads, with script content embedded as base64-encoded strings -- a more consistent and reliable approach than the previous multipart/form-data format.

Worker: The parent resource representing your application. It has a stable UUID and holds persistent settings like name, tags, and logpush. You can now create a Worker to establish its identity and settings before any code is uploaded.
Version: An immutable snapshot of your code and its specific configuration, like bindings and compatibility_date. Creating a new version is a safe action that doesn't affect live traffic.
Deployment: An explicit action that directs traffic to a specific version.

Why this matters

You can now create Workers before uploading code

Workers are now standalone resources that can be created and configured without any code. Platform teams can provision Workers with the right settings, then hand them off to development teams for implementation.

Example: Typescript SDK

// Step 1: Platform team creates the Worker resource (no code needed)
const worker = await client.workers.beta.workers.create({
  name: "payment-service",
  account_id: "...",
  observability: {
    enabled: true,
  },
});

// Step 2: Development team adds code and creates a version later
const version = await client.workers.beta.workers.versions.create(worker.id, {
  account_id: "...",
  main_module: "worker.js",
  compatibility_date: "$today",
  bindings: [ /*...*/ ],
  modules: [
    {
      name: "worker.js",
      content_type: "application/javascript+module",
      content_base64: Buffer.from(scriptContent).toString("base64"),
    },
  ],
});

// Step 3: Deploy explicitly when ready
const deployment = await client.workers.scripts.deployments.create(worker.name, {
  account_id: "...",
  strategy: "percentage",
  versions: [
    {
      percentage: 100,
      version_id: version.id,
    },
  ],
});

Example: Terraform

If you use Terraform, you can now declare the Worker in your Terraform configuration and manage configuration outside of Terraform in your Worker's wrangler.jsonc file and deploy code changes using Wrangler.

resource "cloudflare_worker" "my_worker" {
  account_id = "..."
  name = "my-important-service"
}
# Manage Versions and Deployments here or outside of Terraform
# resource "cloudflare_worker_version" "my_worker_version" {}
# resource "cloudflare_workers_deployment" "my_worker_deployment" {}

Deployments are always explicit, never implicit

Creating a version and deploying it are now always explicit, separate actions - never implicit side effects. To update version-specific settings (like bindings), you create a new version with those changes. The existing deployed version remains unchanged until you explicitly deploy the new one.

# Step 1: Create a new version with updated settings (doesn't affect live traffic)
POST /workers/workers/{id}/versions
{
  "compatibility_date": "$today",
  "bindings": [
    {
      "name": "MY_NEW_ENV_VAR",
      "text": "new_value",
      "type": "plain_text"
    }
  ],
  "modules": [...]
}

# Step 2: Explicitly deploy when ready (now affects live traffic)
POST /workers/scripts/{script_name}/deployments
{
  "strategy": "percentage",
  "versions": [
    {
      "percentage": 100,
      "version_id": "new_version_id"
    }
  ]
}

Settings are clearly organized by scope

Configuration is now logically divided: Worker settings (like name and tags) persist across all versions, while Version settings (like bindings and compatibility_date) are specific to each code snapshot.

# Worker settings (the parent resource)
PUT /workers/workers/{id}
{
  "name": "payment-service",
  "tags": ["production"],
  "logpush": true,
}

# Version settings (the "code")
POST /workers/workers/{id}/versions
{
  "compatibility_date": "$today",
  "bindings": [...],
  "modules": [...]
}

`/workers` API endpoints now support UUIDs (in addition to names)

The /workers/workers/ path now supports addressing a Worker by both its immutable UUID and its mutable name.

# Both work for the same Worker
GET /workers/workers/29494978e03748669e8effb243cf2515  # UUID (stable for automation)
GET /workers/workers/payment-service                  # Name (convenient for humans)

This dual approach means:

Developers can use readable names for debugging.
Automation can rely on stable UUIDs to prevent errors when Workers are renamed.
Terraform can rename Workers without destroying and recreating them.

Learn more

Technical notes

The pre-existing Workers REST API remains fully supported. Once the new API exits beta, we'll provide a migration timeline with ample notice and comprehensive migration guides.
Existing Terraform resources and SDK methods will continue to be fully supported through the current major version.
While the Deployments API currently remains on the /scripts/ endpoint, we plan to introduce a new Deployments endpoint under /workers/ to match the new API structure.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Cloudflare Tunnel and Networks API will no longer return deleted resources by default starting December 1, 2025

Tue, 02 Sep 2025 00:00:00 GMT

Starting December 1, 2025, list endpoints for the Cloudflare Tunnel API and Zero Trust Networks API will no longer return deleted tunnels, routes, subnets and virtual networks by default. This change makes the API behavior more intuitive by only returning active resources unless otherwise specified.

No action is required if you already explicitly set is_deleted=false or if you only need to list active resources.

This change affects the following API endpoints:

List all tunnels: GET /accounts/{account_id}/tunnels
List Cloudflare Tunnels: GET /accounts/{account_id}/cfd_tunnel
List WARP Connector tunnels: GET /accounts/{account_id}/warp_connector
List tunnel routes: GET /accounts/{account_id}/teamnet/routes
List subnets: GET /accounts/{account_id}/zerotrust/subnets
List virtual networks: GET /accounts/{account_id}/teamnet/virtual_networks

What is changing?

The default behavior of the is_deleted query parameter will be updated.

Scenario	Previous behavior (before December 1, 2025)	New behavior (from December 1, 2025)
`is_deleted` parameter is omitted	Returns active & deleted tunnels, routes, subnets and virtual networks	Returns only active tunnels, routes, subnets and virtual networks

Action required

If you need to retrieve deleted (or all) resources, please update your API calls to explicitly include the is_deleted parameter before December 1, 2025.

To get a list of only deleted resources, you must now explicitly add the is_deleted=true query parameter to your request:

# Example: Get ONLY deleted Tunnels
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/tunnels?is_deleted=true" \
     -H "Authorization: Bearer $API_TOKEN"

# Example: Get ONLY deleted Virtual Networks
curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/virtual_networks?is_deleted=true" \
     -H "Authorization: Bearer $API_TOKEN"

Following this change, retrieving a complete list of both active and deleted resources will require two separate API calls: one to get active items (by omitting the parameter or using is_deleted=false) and one to get deleted items (is_deleted=true).

Why we’re making this change

This update is based on user feedback and aims to:

Create a more intuitive default: Aligning with common API design principles where list operations return only active resources by default.
Reduce unexpected results: Prevents users from accidentally operating on deleted resources that were returned unexpectedly.
Improve performance: For most users, the default query result will now be smaller and more relevant.

To learn more, please visit the Cloudflare Tunnel API and Zero Trust Networks API documentation.

Email security - Updated Email security roles

Mon, 01 Sep 2025 23:25:49 GMT

To provide more granular controls, we refined the existing roles for Email security and launched a new Email security role as well.

All Email security roles no longer have read or write access to any of the other Zero Trust products:

Email Configuration Admin
Email Integration Admin
Email security Read Only
Email security Analyst
Email security Policy Admin
Email security Reporting

To configure Data Loss Prevention (DLP) or Remote Browser Isolation (RBI), you now need to be an admin for the Zero Trust dashboard with the Cloudflare Zero Trust role.

Also through customer feedback, we have created a new additive role to allow Email security Analyst to create, edit, and delete Email security policies, without needing to provide access via the Email Configuration Admin role. This role is called Email security Policy Admin, which can read all settings, but has write access to allow policies, trusted domains, and blocked senders.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Cloudflare One Client - Cloudflare One WARP Diagnostic AI Analyzer

Fri, 29 Aug 2025 00:00:00 GMT

We're excited to share a new AI feature, the WARP diagnostic analyzer ↗︎, to help you troubleshoot and resolve WARP connectivity issues faster. This beta feature is now available in the Cloudflare One dashboard ↗︎ to all users. The AI analyzer makes it easier for you to identify the root cause of client connectivity issues by parsing remote captures of WARP diagnostic logs. The WARP diagnostic analyzer provides a summary of impact that may be experienced on the device, lists notable events that may contribute to performance issues, and recommended troubleshooting steps and articles to help you resolve these issues. Refer to WARP diagnostics analyzer (beta) to learn more about how to maximize using the WARP diagnostic analyzer to troubleshoot the WARP client.

Digital Experience Monitoring - DEX MCP Server

Fri, 29 Aug 2025 00:00:00 GMT

Digital Experience Monitoring (DEX) provides visibility into device connectivity and performance across your Cloudflare SASE deployment.

We've released an MCP server (Model Context Protocol) ↗︎ for DEX.

The DEX MCP server is an AI tool that allows customers to ask a question like, "Show me the connectivity and performance metrics for the device used by carly‌@acme.com", and receive an answer that contains data from the DEX API.

Any Cloudflare One customer using a Free, Pay-as-you-go, or Enterprise account can access the DEX MCP Server. This feature is available to everyone.

Customers can test the new DEX MCP server in less than one minute. To learn more, read the DEX MCP server documentation.

Gateway, Cloudflare One - Shadow IT - SaaS analytics dashboard

Wed, 27 Aug 2025 00:00:00 GMT

Zero Trust has significantly upgraded its Shadow IT analytics, providing you with unprecedented visibility into your organizations use of SaaS tools. With this dashboard, you can review who is using an application and volumes of data transfer to the application.

You can review these metrics against application type, such as Artificial Intelligence or Social Media. You can also mark applications with an approval status, including Unreviewed, In Review, Approved, and Unapproved designating how they can be used in your organization.

These application statuses can also be used in Gateway HTTP policies, so you can block, isolate, limit uploads and downloads, and more based on the application status.

Both the analytics and policies are accessible in the Cloudflare Zero Trust dashboard ↗︎, empowering organizations with better visibility and control.

CASB - New CASB integrations for ChatGPT, Claude, and Gemini

Tue, 26 Aug 2025 16:00:00 GMT

Cloudflare CASB ↗︎ now supports three of the most widely used GenAI platforms — OpenAI ChatGPT, Anthropic Claude, and Google Gemini. These API-based integrations give security teams agentless visibility into posture, data, and compliance risks across their organization’s use of generative AI.

Key capabilities

Agentless connections — connect ChatGPT, Claude, and Gemini tenants via API; no endpoint software required
Posture management — detect insecure settings and misconfigurations that could lead to data exposure
DLP detection — identify sensitive data in uploaded chat attachments or files
GenAI-specific insights — surface risks unique to each provider’s capabilities

Learn more

These integrations are available to all Cloudflare One customers today.

Access - Manage and restrict access to internal MCP servers with Cloudflare Access

Tue, 26 Aug 2025 00:00:00 GMT

You can now control who within your organization has access to internal MCP servers, by putting internal MCP servers behind Cloudflare Access.

Self-hosted applications in Cloudflare Access now support OAuth for MCP server authentication. This allows Cloudflare to delegate access from any self-hosted application to an MCP server via OAuth. The OAuth access token authorizes the MCP server to make requests to your self-hosted applications on behalf of the authorized user, using that user's specific permissions and scopes.

For example, if you have an MCP server designed for internal use within your organization, you can configure Access policies to ensure that only authorized users can access it, regardless of which MCP client they use. Support for internal, self-hosted MCP servers also works with MCP server portals, allowing you to provide a single MCP endpoint for multiple MCP servers. For more on MCP server portals, read the blog post ↗︎ on the Cloudflare Blog.

Access - MCP server portals

Tue, 26 Aug 2025 00:00:00 GMT

An MCP server portal centralizes multiple Model Context Protocol (MCP) servers onto a single HTTP endpoint. Key benefits include:

Streamlined access to multiple MCP servers: MCP server portals support both unauthenticated MCP servers as well as MCP servers secured using any third-party or custom OAuth provider. Users log in to the portal URL through Cloudflare Access and are prompted to authenticate separately to each server that requires OAuth.
Customized tools per portal: Admins can tailor an MCP portal to a particular use case by choosing the specific tools and prompt templates that they want to make available to users through the portal. This allows users to access a curated set of tools and prompts — the less external context exposed to the AI model, the better the AI responses tend to be.
Observability: Once the user's AI agent is connected to the portal, Cloudflare Access logs the individual requests made using the tools in the portal.

This is available in an open beta for all customers across all plans! For more information check out our blog ↗︎ for this release.

Data Loss Prevention - New DLP topic based detection entries for AI prompt protection

Mon, 25 Aug 2025 00:00:00 GMT

You now have access to a comprehensive suite of capabilities to secure your organization's use of generative AI. AI prompt protection introduces four key features that work together to provide deep visibility and granular control.

Prompt Detection for AI Applications

DLP can now natively detect and inspect user prompts submitted to popular AI applications, including Google Gemini, ChatGPT, Claude, and Perplexity.

Prompt Analysis and Topic Classification

Our DLP engine performs deep analysis on each prompt, applying topic classification. These topics are grouped into two evaluation categories:

Content: PII, Source Code, Credentials and Secrets, Financial Information, and Customer Data.
Intent: Jailbreak attempts, requests for malicious code, or attempts to extract PII.

To help you apply these topics quickly, we have also released five new predefined profiles (for example, AI Prompt: AI Security, AI Prompt: PII) that bundle these new topics.

Granular Guardrails

You can now build guardrails using Gateway HTTP policies with application granular controls. Apply a DLP profile containing an AI prompt topic detection to individual AI applications (for example, ChatGPT) and specific user actions (for example, SendPrompt) to block sensitive prompts.
Full Prompt Logging

To aid in incident investigation, an optional setting in your Gateway policy allows you to capture prompt logs to store the full interaction of prompts that trigger a policy match. To make investigations easier, logs can be filtered by conversation_id, allowing you to reconstruct the full context of an interaction that led to a policy violation.

AI prompt protection is now available in open beta. To learn more about it, read the blog ↗︎ or refer to AI prompt topics.

Workers - Content type returned in Workers Assets for Javascript files is now `text/javascript`

Mon, 25 Aug 2025 00:00:00 GMT

JavaScript asset responses have been updated to use the text/javascript Content-Type header instead of application/javascript. While both MIME types are widely supported by browsers, the HTML Living Standard explicitly recommends text/javascript as the preferred type going forward.

This change improves:

Standards alignment: Ensures consistency with the HTML spec and modern web platform guidance.
Interoperability: Some developer tools, validators, and proxies expect text/javascript and may warn or behave inconsistently with application/javascript.
Future-proofing: By following the spec-preferred MIME type, we reduce the risk of deprecation warnings or unexpected behavior in evolving browser environments.
Consistency: Most frameworks, CDNs, and hosting providers now default to text/javascript, so this change matches common ecosystem practice.

Because all major browsers accept both MIME types, this update is backwards compatible and should not cause breakage.

Users will see this change on the next deployment of their assets.

Gateway - Gateway BYOIP Dedicated Egress IPs now available.

Thu, 21 Aug 2025 00:00:00 GMT

Enterprise Gateway users can now use Bring Your Own IP (BYOIP) for dedicated egress IPs.

Admins can now onboard and use their own IPv4 or IPv6 prefixes to egress traffic from Cloudflare, delivering greater control, flexibility, and compliance for network traffic.

Get started by following the BYOIP onboarding process. Once your IPs are onboarded, go to Gateway > Egress policies and select or create an egress policy. In Select an egress IP, choose Use dedicated egress IPs (Cloudflare or BYOIP), then select your BYOIP address from the dropdown menu.

For more information, refer to BYOIP for dedicated egress IPs.

Workers - Easier debugging in Workers with improved Wrangler error screen

Tue, 19 Aug 2025 00:00:00 GMT

Wrangler's error screen has received several improvements to enhance your debugging experience!

The error screen now features a refreshed design thanks to youch ↗︎, with support for both light and dark themes, improved source map resolution logic that handles missing source files more reliably, and better error cause display.

Before	After (Light)	After (Dark)

Try it out now with npx wrangler@latest dev in your Workers project.

Access - SFTP support for SSH with Cloudflare Access for Infrastructure

Fri, 15 Aug 2025 00:00:00 GMT

SSH with Cloudflare Access for Infrastructure now supports SFTP. It is compatible with SFTP clients, such as Cyberduck.

Load Balancing - Steer Traffic by AS Number in Load Balancing Custom Rules

Fri, 15 Aug 2025 00:00:00 GMT

You can now create more granular, network-aware Custom Rules in Cloudflare Load Balancing using the Autonomous System Number (ASN) of an incoming request.

This allows you to steer traffic with greater precision based on the network source of a request. For example, you can route traffic from specific Internet Service Providers (ISPs) or enterprise customers to dedicated infrastructure, optimize performance, or enforce compliance by directing certain networks to preferred data centers.

To get started, create a Custom Rule ↗︎ in your Load Balancer and select AS Num from the Field dropdown.

Workers - The Node.js and Web File System APIs in Workers

Fri, 15 Aug 2025 00:00:00 GMT

Implementations of the node:fs module ↗︎ and the Web File System API ↗︎ are now available in Workers.

Using the `node:fs` module

The node:fs module provides access to a virtual file system in Workers. You can use it to read and write files, create directories, and perform other file system operations.

The virtual file system is ephemeral with each individual request havig its own isolated temporary file space. Files written to the file system will not persist across requests and will not be shared across requests or across different Workers.

Workers running with the nodejs_compat compatibility flag will have access to the node:fs module by default when the compatibility date is set to 2025-09-01 or later. Support for the API can also be enabled using the enable_nodejs_fs_module compatibility flag together with the nodejs_compat flag. The node:fs module can be disabled using the disable_nodejs_fs_module compatibility flag.

import fs from "node:fs";

const config = JSON.parse(fs.readFileSync("/bundle/config.json", "utf-8"));

export default {
	async fetch(request) {
		return new Response(`Config value: ${config.value}`);
	},
};

There are a number of initial limitations to the node:fs implementation:

The glob APIs (e.g. fs.globSync(...)) are not implemented.
The file watching APIs (e.g. fs.watch(...)) are not implemented.
The file timestamps (modified time, access time, etc) are only partially supported. For now, these will always return the Unix epoch.

Refer to the Node.js documentation ↗︎ for more information on the node:fs module and its APIs.

The Web File System API

The Web File System API provides access to the same virtual file system as the node:fs module, but with a different API surface. The Web File System API is only available in Workers running with the enable_web_file_system compatibility flag. The nodejs_compat compatibility flag is not required to use the Web File System API.

const root = navigator.storage.getDirectory();

export default {
	async fetch(request) {
		const tmp = await root.getDirectoryHandle("/tmp");
		const file = await tmp.getFileHandle("data.txt", { create: true });
		const writable = await file.createWritable();
		const writer = writable.getWriter();
		await writer.write("Hello, World!");
		await writer.close();

		return new Response("File written successfully!");
	},
};

As there are still some parts of the Web File System API that are not fully standardized, there may be some differences between the Workers implementation and the implementations in browsers.

Workers - Workers Static Assets: Corrected handling of double slashes in redirect rule paths

Fri, 15 Aug 2025 00:00:00 GMT

Static Assets: Fixed a bug in how redirect rules ↗︎ defined in your Worker's _redirects file are processed.

If you're serving Static Assets with a _redirects file containing a rule like /ja/* /:splat, paths with double slashes were previously misinterpreted as external URLs. For example, visiting /ja//example.com would incorrectly redirect to https://example.com instead of /example.com on your domain. This has been fixed and double slashes now correctly resolve as local paths. Note: Cloudflare Pages was not affected by this issue.

Workers - Workers per-branch preview URLs now support long branch names

Thu, 14 Aug 2025 01:00:00 GMT

We've updated preview URLs for Cloudflare Workers to support long branch names.

Previously, branch and Worker names exceeding the 63-character DNS limit would cause alias generation to fail, leaving pull requests without aliased preview URLs. This particularly impacted teams relying on descriptive branch naming.

Now, Cloudflare automatically truncates long branch names and appends a unique hash, ensuring every pull request gets a working preview link.

How it works

63 characters or less: <branch-name>-<worker-name> → Uses actual branch name as is
64 characters or more: <truncated-branch-name>--<hash>-<worker-name> → Uses truncated name with 4-character hash
Hash generation: The hash is derived from the full branch name to ensure uniqueness
Stable URLs: The same branch always generates the same hash across all commits

Requirements and compatibility

Wrangler 4.30.0 or later: This feature requires updating to wrangler@4.30.0+
No configuration needed: Works automatically with existing preview URL setups

Access - Cloudflare Access Logging supports the Customer Metadata Boundary (CMB)

Thu, 14 Aug 2025 00:00:00 GMT

Cloudflare Access logs now support the Customer Metadata Boundary (CMB). If you have configured the CMB for your account, all Access logging will respect that configuration.

Workers - Python Workers handlers now live in an entrypoint class

Thu, 14 Aug 2025 00:00:00 GMT

We are changing how Python Workers are structured by default. Previously, handlers were defined at the top-level of a module as on_fetch, on_scheduled, etc. methods, but now they live in an entrypoint class.

Here's an example of how to now define a Worker with a fetch handler:

from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        return Response("Hello World!")

To keep using the old-style handlers, you can specify the disable_python_no_global_handlers compatibility flag in your wrangler file:

{
	"compatibility_flags": [
		"disable_python_no_global_handlers"
	]
}

compatibility_flags = [ "disable_python_no_global_handlers" ]

Consult the Python Workers documentation for more details.

Workers - Terraform provider improvements — Python Workers support, smaller plan diffs, and API SDK fixes

Thu, 14 Aug 2025 00:00:00 GMT

The recent Cloudflare Terraform Provider ↗︎ and SDK releases (such as cloudflare-typescript ↗︎) bring significant improvements to the Workers developer experience. These updates focus on reliability, performance, and adding Python Workers support.

Terraform Improvements

Fixed Unwarranted Plan Diffs

Resolved several issues with the cloudflare_workers_script resource that resulted in unwarranted plan diffs, including:

Using Durable Objects migrations
Using some bindings such as secret_text
Using smart placement

A resource should never show a plan diff if there isn't an actual change. This fix reduces unnecessary noise in your Terraform plan and is available in Cloudflare Terraform Provider 5.8.0.

Improved File Management

You can now specify content_file and content_sha256 instead of content. This prevents the Workers script content from being stored in the state file which greatly reduces plan diff size and noise. If your workflow synced plans remotely, this should now happen much faster since there is less data to sync. This is available in Cloudflare Terraform Provider 5.7.0.

resource "cloudflare_workers_script" "my_worker" {
  account_id      = "123456789"
  script_name     = "my_worker"
  main_module     = "worker.mjs"
  content_file    = "worker.mjs"
  content_sha256  = filesha256("worker.mjs")
}

Assets Headers and Redirects Support

Fixed the cloudflare_workers_script resource to properly support headers and redirects for Assets:

resource "cloudflare_workers_script" "my_worker" {
  account_id      = "123456789"
  script_name     = "my_worker"
  main_module     = "worker.mjs"
  content_file    = "worker.mjs"
  content_sha256  = filesha256("worker.mjs")
  assets = {
    config = {
      headers = file("_headers")
      redirects = file("_redirects")
    }
    # Completion jwt from:
    # https://developers.cloudflare.com/api/resources/workers/subresources/assets/subresources/upload/
    jwt = "jwt"
  }
}

Available in Cloudflare Terraform Provider 5.8.0.

Python Workers Support

Added support for uploading Python Workers (beta) in Terraform. You can now deploy Python Workers with:

resource "cloudflare_workers_script" "my_worker" {
  account_id       = "123456789"
  script_name      = "my_worker"
  content_file     = "worker.py"
  content_sha256   = filesha256("worker.py")
  content_type     = "text/x-python"
}

Available in Cloudflare Terraform Provider 5.8.0.

SDK Enhancements

Improved File Upload API

Fixed an issue where Workers script versions in the SDK did not allow uploading files. This now works, and also has an improved files upload interface:

const scriptContent = `
  export default {
    async fetch(request, env, ctx) {
      return new Response('Hello World!', { status: 200 });
    }
  };
`;

client.workers.scripts.versions.create('my-worker', {
  account_id: '123456789',
  metadata: {
    main_module: 'my-worker.mjs',
  },
  files: [
    await toFile(
      Buffer.from(scriptContent),
      'my-worker.mjs',
      {
        type: "application/javascript+module",
      }
    )
  ]
});

Will be available in cloudflare-typescript 4.6.0. A similar change will be available in cloudflare-python 4.4.0.

Fixed updating KV values

Previously when creating a KV value like this:

await cf.kv.namespaces.values.update("my-kv-namespace", "key1", {
  account_id: "123456789",
  metadata: "my metadata",
  value: JSON.stringify({
    hello: "world"
  })
});

...and recalling it in your Worker like this:

const value = await c.env.KV.get<{hello: string}>("key1", "json");

You'd get back this: {metadata:'my metadata', value:"{'hello':'world'}"} instead of the correct value of {hello: 'world'}

This is fixed in cloudflare-typescript 4.5.0 and will be fixed in cloudflare-python 4.4.0.

Workers - MessageChannel and MessagePort

Mon, 11 Aug 2025 01:00:00 GMT

A minimal implementation of the MessageChannel API ↗︎ is now available in Workers. This means that you can use MessageChannel to send messages between different parts of your Worker, but not across different Workers.

The MessageChannel and MessagePort APIs will be available by default at the global scope with any worker using a compatibility date of 2025-08-15 or later. It is also available using the expose_global_message_channel compatibility flag, or can be explicitly disabled using the no_expose_global_message_channel compatibility flag.

const { port1, port2 } = new MessageChannel();

port2.onmessage = (event) => {
	console.log('Received message:', event.data);
};

port2.postMessage('Hello from port2!');

Any value that can be used with the structuredClone(...) API can be sent over the port.

Differences

There are a number of key limitations to the MessageChannel API in Workers:

Transfer lists are currently not supported. This means that you will not be able to transfer ownership of objects like ArrayBuffer or MessagePort between ports.
The MessagePort is not yet serializable. This means that you cannot send a MessagePort object through the postMessage method or via JSRPC calls.
The 'messageerror' event is only partially supported. If the 'onmessage' handler throws an error, the 'messageerror' event will be triggered, however, it will not be triggered when there are errors serializing or deserializing the message data. Instead, the error will be thrown when the postMessage method is called on the sending port.
The 'close' event will be emitted on both ports when one of the ports is closed, however it will not be emitted when the Worker is terminated or when one of the ports is garbage collected.

Workers - Wrangler and the Cloudflare Vite plugin support `.env` files in local development

Fri, 08 Aug 2025 01:00:00 GMT

Now, you can use .env files to provide secrets and override environment variables on the env object during local development with Wrangler and the Cloudflare Vite plugin.

Previously in local development, if you wanted to provide secrets or environment variables during local development, you had to use .dev.vars files. This is still supported, but you can now also use .env files, which are more familiar to many developers.

Using `.env` files in local development

You can create a .env file in your project root to define environment variables that will be used when running wrangler dev or vite dev. The .env file should be formatted like a dotenv file, such as KEY="VALUE":

.envbash

TITLE="My Worker"
API_TOKEN="dev-token"

When you run wrangler dev or vite dev, the environment variables defined in the .env file will be available in your Worker code via the env object:

export default {
	async fetch(request, env) {
		const title = env.TITLE; // "My Worker"
		const apiToken = env.API_TOKEN; // "dev-token"
		const response = await fetch(
			`https://api.example.com/data?token=${apiToken}`,
		);
		return new Response(`Title: ${title} - ` + (await response.text()));
	},
};

Multiple environments with `.env` files

If your Worker defines multiple environments, you can set different variables for each environment (ex: production or staging) by creating files named .env.<environment-name>.

When you use wrangler <command> --env <environment-name> or CLOUDFLARE_ENV=<environment-name> vite dev, the corresponding environment-specific file will also be loaded and merged with the .env file.

For example, if you want to set different environment variables for the staging environment, you can create a file named .env.staging:

.env.stagingbash

API_TOKEN="staging-token"

When you run wrangler dev --env staging or CLOUDFLARE_ENV=staging vite dev, the environment variables from .env.staging will be merged onto those from .env.

export default {
	async fetch(request, env) {
		const title = env.TITLE; // "My Worker" (from `.env`)
		const apiToken = env.API_TOKEN; // "staging-token" (from `.env.staging`, overriding the value from `.env`)
		const response = await fetch(
			`https://api.example.com/data?token=${apiToken}`,
		);
		return new Response(`Title: ${title} - ` + (await response.text()));
	},
};

Find out more

For more information on how to use .env files with Wrangler and the Cloudflare Vite plugin, see the following documentation:

Stream - Introducing observability and metrics for Stream Live Inputs

Fri, 08 Aug 2025 00:00:00 GMT

New information about broadcast metrics and events is now available in Cloudflare Stream in the Live Input details of the Dashboard.

You can now easily understand broadcast-side health and performance with new observability, which can help when troubleshooting common issues, particularly for new customers who are just getting started, and platform customers who may have limited visibility into how their end-users configure their encoders.

To get started, start a live stream (just getting started?), then visit the Live Input details page in Dash.

See our new live Troubleshooting guide to learn what these metrics mean and how to use them to address common broadcast issues.

Workers - Directly import `waitUntil` in Workers for easily spawning background tasks

Fri, 08 Aug 2025 00:00:00 GMT

You can now import waitUntil from cloudflare:workers to extend your Worker's execution beyond the request lifecycle from anywhere in your code.

Previously, waitUntil could only be accessed through the execution context (ctx) parameter passed to your Worker's handler functions. This meant that if you needed to schedule background tasks from deeply nested functions or utility modules, you had to pass the ctx object through multiple function calls to access waitUntil.

Now, you can import waitUntil directly and use it anywhere in your Worker without needing to pass ctx as a parameter:

import { waitUntil } from "cloudflare:workers";

export function trackAnalytics(eventData) {
	const analyticsPromise = fetch("https://analytics.example.com/track", {
		method: "POST",
		body: JSON.stringify(eventData),
	});

	// Extend execution to ensure analytics tracking completes
	waitUntil(analyticsPromise);
}

This is particularly useful when you want to:

Schedule background tasks from utility functions or modules
Extend execution for analytics, logging, or cleanup operations
Avoid passing the execution context through multiple layers of function calls

import { waitUntil } from "cloudflare:workers";

export default {
	async fetch(request, env, ctx) {
		// Background task that should complete even after response is sent
		cleanupTempData(env.KV_NAMESPACE);
		return new Response("Hello, World!");
	}
};

function cleanupTempData(kvNamespace) {
	// This function can now use waitUntil without needing ctx
	const deletePromise = kvNamespace.delete("temp-key");
	waitUntil(deletePromise);
}

For more information, see the waitUntil documentation.

Email security - Expanded Email Link Isolation

Thu, 07 Aug 2025 23:22:49 GMT

When you deploy MX or Inline, not only can you apply email link isolation to suspicious links in all emails (including benign), you can now also apply email link isolation to all links of a specified disposition. This provides more flexibility in controlling user actions within emails.

For example, you may want to deliver suspicious messages but isolate the links found within them so that users who choose to interact with the links will not accidentally expose your organization to threats. This means your end users are more secure than ever before.

To isolate all links within a message based on the disposition, select Settings > Link Actions > View and select Configure. As with other other links you isolate, an interstitial will be provided to warn users that this site has been isolated and the link will be recrawled live to evaluate if there are any changes in our threat intel. Learn more about this feature on Configure link actions ↗︎.

This feature is available across these Email security packages:

Enterprise
Enterprise + PhishGuard

Workers - Requests made from Cloudflare Workers can now force a revalidation of their cache with the origin

Thu, 07 Aug 2025 00:00:00 GMT

By setting the value of the cache property to no-cache, you can force Cloudflare's cache to revalidate its contents with the origin when making subrequests from Cloudflare Workers.

index.jsjs

export default {
	async fetch(req, env, ctx) {
		const request = new Request("https://cloudflare.com", {
			cache: "no-cache",
		});
		const response = await fetch(request);
		return response;
	},
};

index.tsts

export default {
  async fetch(req, env, ctx): Promise<Response> {
		const request = new Request("https://cloudflare.com", { cache: 'no-cache'});
		const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When no-cache is set, the Worker request will first look for a match in Cloudflare's cache, then:

If there is a match, a conditional request is sent to the origin, regardless of whether or not the match is fresh or stale. If the resource has not changed, the cached version is returned. If the resource has changed, it will be downloaded from the origin, updated in the cache, and returned.
If there is no match, Workers will make a standard request to the origin and cache the response.

This increases compatibility with NPM packages and JavaScript frameworks that rely on setting the cache property, which is a cross-platform standard part of the Request interface. Previously, if you set the cache property on Request to 'no-cache', the Workers runtime threw an exception.

Learn how the Cache works with Cloudflare Workers
Enable Node.js compatibility for your Cloudflare Worker
Explore Runtime APIs and Bindings available in Cloudflare Workers

Load Balancing - Improvements to Monitoring Using Zone Settings

Wed, 06 Aug 2025 00:00:00 GMT

Cloudflare Load Balancing Monitors support loading and applying settings for a specific zone to monitoring requests to origin endpoints. This feature has been migrated to new infrastructure to improve reliability, performance, and accuracy.

All zone monitors have been tested against the new infrastructure. There should be no change to health monitoring results of currently healthy and active pools. Newly created or re-enabled pools may need validation of their monitor zone settings before being introduced to service, especially regarding correct application of mTLS.

What you can expect:

More reliable application of zone settings to monitoring requests, including
- Authenticated Origin Pulls
- Aegis Egress IP Pools
- Argo Smart Routing
- HTTP/2 to Origin
Improved support and bug fixes for retries, redirects, and proxied origin resolution
Improved performance and reliability of monitoring requests within the Cloudflare network
Unrelated CDN or WAF configuration changes should have no risk of impact to pool health

Workers - Increased disk space for Workers Builds

Mon, 04 Aug 2025 01:00:00 GMT

As part of the ongoing open beta for Workers Builds, we’ve increased the available disk space for builds from 8 GB to 20 GB for both Free and Paid plans.

This provides more space for larger projects, dependencies, and build artifacts while improving overall build reliability.

Metric	Free Plan	Paid Plans
Disk Space	20 GB	20 GB

All other build limits — including CPU, memory, build minutes, and timeout remain unchanged.

Workers - Develop locally with Containers and the Cloudflare Vite plugin

Fri, 01 Aug 2025 00:00:00 GMT

You can now configure and run Containers alongside your Worker during local development when using the Cloudflare Vite plugin. Previously, you could only develop locally when using Wrangler as your local development server.

Configuration

You can simply configure your Worker and your Container(s) in your Wrangler configuration file:

{
  "name": "container-starter",
  "main": "src/index.js",
  "containers": [
    {
      "class_name": "MyContainer",
      "image": "./Dockerfile",
      "instances": 5
    }
  ],
  "durable_objects": {
    "bindings": [
      {
        "class_name": "MyContainer",
        "name": "MY_CONTAINER"
      }
    ]
  },
  "migrations": [
    {
      "new_sqlite_classes": [
        "MyContainer"
      ],
      "tag": "v1"
    }
  ],
}

name = "container-starter"
main = "src/index.js"

[[containers]]
class_name = "MyContainer"
image = "./Dockerfile"
instances = 5

[[durable_objects.bindings]]
class_name = "MyContainer"
name = "MY_CONTAINER"

[[migrations]]
new_sqlite_classes = [ "MyContainer" ]
tag = "v1"

Worker Code

Once your Worker and Containers are configured, you can access the Container instances from your Worker code:

import { Container, getContainer } from "@cloudflare/containers";

export class MyContainer extends Container {
  defaultPort = 4000; // Port the container is listening on
  sleepAfter = "10m"; // Stop the instance if requests not sent for 10 minutes
}

async fetch(request, env) {
  const { "session-id": sessionId } = await request.json();
  // Get the container instance for the given session ID
  const containerInstance = getContainer(env.MY_CONTAINER, sessionId)
  // Pass the request to the container instance on its default port
  return containerInstance.fetch(request);
}

Local development

To develop your Worker locally, start a local dev server by running

vite dev

in your terminal.

Resources

Learn more about Cloudflare Containers ↗︎ or the Cloudflare Vite plugin ↗︎ in our developer docs.

Cloudflare WAN - Terraform V5 support for tunnels and routes

Thu, 31 Jul 2025 00:00:00 GMT

The Cloudflare Terraform provider resources for Cloudflare WAN tunnels and routes now support Terraform provider version 5. Customers using infrastructure-as-code workflows can manage their tunnel and route configuration with the latest provider version.

For more information, refer to the Cloudflare Terraform provider documentation ↗︎.

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

Wed, 30 Jul 2025 00:00:00 GMT

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

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

Tue, 29 Jul 2025 01:00:00 GMT

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.

Gateway - Scam domain category introduced under Security Threats

Mon, 28 Jul 2025 00:00:00 GMT

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.

Gateway - Gateway HTTP Filtering on all ports available in open BETA

Thu, 24 Jul 2025 00:00:00 GMT

Gateway can now apply HTTP filtering to all proxied HTTP requests, not just traffic on standard HTTP (80) and HTTPS (443) ports. This means all requests can now be filtered by A/V scanning, file sandboxing, Data Loss Prevention (DLP), and more.

You can turn this setting on by going to Settings > Network > Firewall and choosing Inspect on all ports.

To learn more, refer to Inspect on all ports (Beta).

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

Tue, 22 Jul 2025 01:00:00 GMT

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.

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

Gateway - Google Bard Application replaced by Gemini

Tue, 22 Jul 2025 00:00:00 GMT

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.

Stream - Audio mode for Media Transformations

Tue, 22 Jul 2025 00:00:00 GMT

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.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Virtual Cloudflare One Appliance with KVM support (open beta)

Mon, 21 Jul 2025 00:00:00 GMT

The KVM-based virtual Cloudflare One Appliance is now in open beta with official support for Proxmox VE.

Customers can deploy the virtual appliance on KVM hypervisors to connect branch or data center networks to Cloudflare WAN without dedicated hardware.

For setup instructions, refer to Configure a virtual Cloudflare One Appliance.

Workers - The Cloudflare Vite plugin now supports Vite 7

Thu, 17 Jul 2025 01:00:00 GMT

Vite 7 ↗︎ is now supported in the Cloudflare Vite plugin. See the Vite changelog ↗︎ for a list of changes.

Note that the minimum Node.js versions supported by Vite 7 are 20.19 and 22.12. We continue to support Vite 6 so you do not need to immediately upgrade.

Data Loss Prevention - New detection entry type: Document Matching for DLP

Thu, 17 Jul 2025 00:00:00 GMT

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.

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.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Faster, more reliable UDP traffic for Cloudflare Tunnel

Tue, 15 Jul 2025 00:00:00 GMT

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.

Cloudflare One - New onboarding guides for Zero Trust

Thu, 10 Jul 2025 00:00:00 GMT

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.

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 ↗︎!

Cloudflare Images - HEIC support in Cloudflare Images

Tue, 08 Jul 2025 00:00:00 GMT

You can use Images to ingest HEIC images and serve them in supported output formats like AVIF, WebP, JPEG, and PNG.

When inputting a HEIC image, dimension and sizing limits may still apply. Refer to our documentation to see limits for uploading to Images or transforming a remote image.

Cloudflare One - Cloudy summaries for Access and Gateway Logs

Mon, 07 Jul 2025 00:00:00 GMT

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.

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

Cloudflare One - New App Library for Zero Trust Dashboard

Mon, 07 Jul 2025 00:00:00 GMT

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.

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 - Workers now supports JavaScript debug terminals in VSCode, Cursor and Windsurf IDEs

Fri, 04 Jul 2025 00:00:00 GMT

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 - Access RDP securely from your browser — now in open beta

Tue, 01 Jul 2025 00:00:00 GMT

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.

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

Workers - Enhanced support for static assets with the Cloudflare Vite plugin

Tue, 01 Jul 2025 00:00:00 GMT

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 Client - Cloudflare One Agent for Android (version 2.4.2)

Mon, 30 Jun 2025 00:00:00 GMT

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 Client - Cloudflare One Agent for iOS (version 1.11)

Mon, 30 Jun 2025 00:00:00 GMT

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.

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

Mon, 30 Jun 2025 00:00:00 GMT

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.

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

Thu, 26 Jun 2025 00:00:00 GMT

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 Loss Prevention, CASB, Cloudflare One - Data Security Analytics in the Zero Trust dashboard

Mon, 23 Jun 2025 09:00:00 GMT

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.

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

Workers - Increased blob size limits in Workers Analytics Engine

Fri, 20 Jun 2025 00:00:00 GMT

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"],
		});
	}
};

D1, Workers, Workers for Platforms - Automate Worker deployments with a simplified SDK and more reliable Terraform provider

Thu, 19 Jun 2025 00:00:00 GMT

Simplified Worker Deployments with our SDKs

We've simplified the programmatic deployment of Workers via our Cloudflare SDKs. This update abstracts away the low-level complexities of the multipart/form-data upload process, allowing you to focus on your code while we handle the deployment mechanics.

This new interface is available in:

cloudflare-typescript ↗︎ (4.4.1)
cloudflare-python ↗︎ (4.3.1)

For complete examples, see our guide on programmatic Worker deployments.

The Old way: Manual API calls

Previously, deploying a Worker programmatically required manually constructing a multipart/form-data HTTP request, packaging your code and a separate metadata.json file. This was more complicated and verbose, and prone to formatting errors.

For example, here's how you would upload a Worker script previously with cURL:

curl https://api.cloudflare.com/client/v4/accounts/<account_id>/workers/scripts/my-hello-world-script \
  -X PUT \
  -H 'Authorization: Bearer <api_token>' \
  -F 'metadata={
        "main_module": "my-hello-world-script.mjs",
        "bindings": [
          {
            "type": "plain_text",
            "name": "MESSAGE",
            "text": "Hello World!"
          }
        ],
        "compatibility_date": "$today"
      };type=application/json' \
  -F 'my-hello-world-script.mjs=@-;filename=my-hello-world-script.mjs;type=application/javascript+module' <<EOF
export default {
  async fetch(request, env, ctx) {
    return new Response(env.MESSAGE, { status: 200 });
  }
};
EOF

After: SDK interface

With the new SDK interface, you can now define your entire Worker configuration using a single, structured object.

This approach allows you to specify metadata like main_module, bindings, and compatibility_date as clearer properties directly alongside your script content. Our SDK takes this logical object and automatically constructs the complex multipart/form-data API request behind the scenes.

Here's how you can now programmatically deploy a Worker via the cloudflare-typescript SDK ↗︎

import Cloudflare from "cloudflare";
import { toFile } from "cloudflare/index";

// ... client setup, script content, etc.

const script = await client.workers.scripts.update(scriptName, {
	account_id: accountID,
	metadata: {
		main_module: scriptFileName,
		bindings: [],
	},
	files: {
		[scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, {
			type: "application/javascript+module",
		}),
	},
});

import Cloudflare from 'cloudflare';
import { toFile } from 'cloudflare/index';

// ... client setup, script content, etc.

const script = await client.workers.scripts.update(scriptName, {
  account_id: accountID,
  metadata: {
    main_module: scriptFileName,
    bindings: [],
  },
  files: {
    [scriptFileName]: await toFile(Buffer.from(scriptContent), scriptFileName, {
      type: 'application/javascript+module',
    }),
  },
});

View the complete example here: https://github.com/cloudflare/cloudflare-typescript/blob/main/examples/workers/script-upload.ts ↗︎

Terraform provider improvements

We've also made several fixes and enhancements to the Cloudflare Terraform provider ↗︎:

Fixed the cloudflare_workers_script ↗︎ resource in Terraform, which previously was producing a diff even when there were no changes. Now, your terraform plan outputs will be cleaner and more reliable.
Fixed the cloudflare_workers_for_platforms_dispatch_namespace ↗︎, where the provider would attempt to recreate the namespace on a terraform apply. The resource now correctly reads its remote state, ensuring stability for production environments and CI/CD workflows.
The cloudflare_workers_route ↗︎ resource now allows for the script property to be empty, null, or omitted to indicate that pattern should be negated for all scripts (see routes docs). You can now reserve a pattern or temporarily disable a Worker on a route without deleting the route definition itself.
Using primary_location_hint in the cloudflare_d1_database ↗︎ resource will no longer always try to recreate. You can now safely change the location hint for a D1 database without causing a destructive operation.

API improvements

We've also properly documented the Workers Script And Version Settings in our public OpenAPI spec and SDKs.

Gateway - Gateway will now evaluate Network policies before HTTP policies from July 14th, 2025

Wed, 18 Jun 2025 00:00:00 GMT

Gateway will now evaluate Network (Layer 4) policies before HTTP (Layer 7) policies. This change preserves your existing security posture and does not affect which traffic is filtered — but it may impact how notifications are displayed to end users.

This change will roll out progressively between July 14–18, 2025. If you use HTTP policies, we recommend reviewing your configuration ahead of rollout to ensure the user experience remains consistent.

Updated order of enforcement

Previous order:

DNS policies
HTTP policies
Network policies

New order:

DNS policies
Network policies
HTTP policies

Action required: Review your Gateway HTTP policies

This change may affect block notifications. For example:

You have an HTTP policy to block example.com and display a block page.
You also have a Network policy to block example.com silently (no client notification).

With the new order, the Network policy will trigger first — and the user will no longer see the HTTP block page.

To ensure users still receive a block notification, you can:

Add a client notification to your Network policy, or
Use only the HTTP policy for that domain.

Why we’re making this change

This update is based on user feedback and aims to:

Create a more intuitive model by evaluating network-level policies before application-level policies.
Minimize 526 connection errors by verifying the network path to an origin before attempting to establish a decrypted TLS connection.

To learn more, visit the Gateway order of enforcement documentation.

Workers - Remote bindings public beta - Connect to remote resources (D1, KV, R2, etc.) during local development

Wed, 18 Jun 2025 00:00:00 GMT

Today we announced the public beta ↗︎ of remote bindings for local development. With remote bindings, you can now connect to deployed resources like R2 buckets and D1 databases while running Worker code on your local machine. This means you can test your local code changes against real data and services, without the overhead of deploying for each iteration.

Example configuration

To enable remote mode, add "experimental_remote" : true to each binding that you want to rely on a remote resource running on Cloudflare:

{
	"name": "my-worker",
	// Set this to today's date
	"compatibility_date": "2026-10-11",

	"r2_buckets": [
		{
			"bucket_name": "screenshots-bucket",
			"binding": "screenshots_bucket",
			"experimental_remote": true,
		},
	],
}

name = "my-worker"
# Set this to today's date
compatibility_date = "2026-10-11"

[[r2_buckets]]
bucket_name = "screenshots-bucket"
binding = "screenshots_bucket"
experimental_remote = true

When remote bindings are configured, your Worker still executes locally, but all binding calls are proxied to the deployed resource that runs on Cloudflare's network.

You can try out remote bindings for local development today with:

Wrangler v4.20.3: Use the wrangler dev --x-remote-bindings command.
The Cloudflare Vite Plugin: Refer to the documentation for how to enable in your Vite config.
The Cloudflare Vitest Plugin: Refer to the documentation for how to enable in your Vitest config.

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

Workers - Control which routes invoke your Worker script for Single Page Applications

Tue, 17 Jun 2025 00:00:00 GMT

For those building Single Page Applications (SPAs) on Workers, you can now explicitly define which routes invoke your Worker script in Wrangler configuration. The run_worker_first config option has now been expanded to accept an array of route patterns, allowing you to more granularly specify when your Worker script runs.

Configuration example:

{
	"name": "my-spa-worker",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"main": "./src/index.ts",
	"assets": {
		"directory": "./dist/",
		"not_found_handling": "single-page-application",
		"binding": "ASSETS",
		"run_worker_first": ["/api/*", "!/api/docs/*"]
	}
}

name = "my-spa-worker"
# Set this to today's date
compatibility_date = "2026-10-11"
main = "./src/index.ts"

[assets]
directory = "./dist/"
not_found_handling = "single-page-application"
binding = "ASSETS"
run_worker_first = [ "/api/*", "!/api/docs/*" ]

This new routing control was done in partnership with our community and customers who provided great feedback on our public proposal ↗︎. Thank you to everyone who brought forward use-cases and feedback on the design!

Prerequisites

To use advanced routing control with run_worker_first, you'll need:

Wrangler v4.20.0 and above
Cloudflare Vite plugin v1.7.0 and above

Workers - SSRF vulnerability in @opennextjs/cloudflare proactively mitigated for all Cloudflare customers

Tue, 17 Jun 2025 00:00:00 GMT

Mitigations have been put in place for all existing and future deployments of sites with the Cloudflare adapter for Open Next in response to an identified Server-Side Request Forgery (SSRF) vulnerability in the @opennextjs/cloudflare package.

The vulnerability stemmed from an unimplemented feature in the Cloudflare adapter for Open Next, which allowed users to proxy arbitrary remote content via the /_next/image endpoint.

This issue allowed attackers to load remote resources from arbitrary hosts under the victim site's domain for any site deployed using the Cloudflare adapter for Open Next. For example: https://victim-site.com/_next/image?url=https://attacker.com. In this example, attacker-controlled content from attacker.com is served through the victim site's domain (victim-site.com), violating the same-origin policy and potentially misleading users or other services.

References: https://www.cve.org/cverecord?id=CVE-2025-6087 ↗︎, https://github.com/opennextjs/opennextjs-cloudflare/security/advisories/GHSA-rvpw-p7vw-wj3m ↗︎

Impact

SSRF via unrestricted remote URL loading
Arbitrary remote content loading
Potential internal service exposure or phishing risks through domain abuse

Mitigation

The following mitigations have been put in place:

Server side updates to Cloudflare's platform to restrict the content loaded via the /_next/image endpoint to images. The update automatically mitigates the issue for all existing and any future sites deployed to Cloudflare using the affected version of the Cloudflare adapter for Open Next

Root cause fix: Pull request #727 ↗︎ to the Cloudflare adapter for Open Next. The patched version of the adapter has been released as @opennextjs/cloudflare@1.3.0

Package dependency update: Pull request cloudflare/workers-sdk#9608 ↗︎ to create-cloudflare (c3) to use the fixed version of the Cloudflare adapter for Open Next. The patched version of create-cloudflare has been published as create-cloudflare@2.49.3.

In addition to the automatic mitigation deployed on Cloudflare's platform, we encourage affected users to upgrade to @opennext/cloudflare v1.3.0 and use the remotePatterns ↗︎ filter in Next config if they need to allow-list external urls with images assets.

Workers - Grant account members read-only access to the Workers Platform

Mon, 16 Jun 2025 00:00:00 GMT

You can now grant members of your Cloudflare account read-only access to the Workers Platform.

The new "Workers Platform (Read-only)" role grants read-only access to all products typically used as part of Cloudflare's Developer Platform, including Workers, Pages, Durable Objects, KV, R2, Zones, Zone Analytics and Page Rules. When Cloudflare introduces new products to the Workers platform, we will add additional read-only permissions to this role.

Additionally, the role previously named "Workers Admin" has been renamed to "Workers Platform Admin". This change ensures that the name more accurately reflects the permissions granted — this role has always granted access to more than just Workers — it grants read and write access to the products mentioned above, and similarly, as new products are added to the Workers platform, we will add additional read and write permissions to this role.

You can review the updated roles in the developer docs.

Stream - Increased limits for Media Transformations

Tue, 10 Jun 2025 00:00:00 GMT

We have increased the limits for Media Transformations:

Input file size limit is now 100MB (was 40MB)
Output video duration limit is now 1 minute (was 30 seconds)

Additionally, we have improved caching of the input asset, resulting in fewer requests to origin storage even when transformation options may differ.

For more information, learn about Transforming Videos.

Workers - Access git commit sha and branch name as environment variables in Workers Builds

Tue, 10 Jun 2025 00:00:00 GMT

Workers Builds connects your Worker to a Git repository, and automates building and deploying your code on each pushed change.

To make CI/CD pipelines even more flexible, Workers Builds now automatically injects default environment variables into your build process (much like the defaults in Cloudflare Pages projects). You can use these variables to customize your build process based on the deployment context, such as the branch or commit.

The following environment variables are injected by default:

Environment Variable	Injected value	Example use-case
`CI`	`true`	Changing build behavior when run on CI versus locally
`WORKERS_CI`	`1`	Changing build behavior when run on Workers Builds versus locally
`WORKERS_CI_BUILD_UUID`	`<build-uuid-of-current-build>`	Passing the Build UUID along to custom workflows
`WORKERS_CI_COMMIT_SHA`	`<sha1-hash-of-current-commit>`	Passing current commit ID to error reporting, for example, Sentry
`WORKERS_CI_BRANCH`	`<branch-name-from-push-event`	Customizing build based on branch, for example, disabling debug logging on `production`

You can override these default values and add your own custom environment variables by navigating to your Worker > Settings > Environment variables.

Learn more in the Build configuration documentation.

Workers - Workers native integrations were removed from the Cloudflare dashboard

Mon, 09 Jun 2025 00:00:00 GMT

Workers native integrations were originally launched in May 2023 ↗︎ to connect to popular database and observability providers with your Worker in just a few clicks. We are changing how developers connect Workers to these external services. The Integrations tab in the dashboard has been removed in favor of a more direct, command-line-based approach using Wrangler secrets.

What's changed

Integrations tab removed: The integrations setup flow is no longer available in the Workers dashboard.
Manual secret configuration: New connections should be configured by adding credentials as secrets to your Workers using npx wrangler secret put commands.

Impact on existing integrations

Existing integrations will continue to work without any changes required. If you have integrations that were previously created through the dashboard, they will remain functional.

Updating existing integrations

If you'd like to modify your existing integration, you can update the secrets, environment variables, or Tail Workers that were created from the original integration setup.

Update secrets: Use npx wrangler secret put <SECRET_NAME> to update credential values.
Modify environment variables: Update variables through the dashboard or Wrangler configuration.
Dashboard management: Access your Worker's settings in the Cloudflare dashboard ↗︎ to modify connections created by our removed native integrations feature.

If you have previously set up an observability integration with Sentry ↗︎, the following environment variables were set and are still modifiable:

BLOCKED_HEADERS: headers to exclude sending to Sentry
EXCEPTION_SAMPLING_RATE: number from 0 - 100, where 0 = no events go through to Sentry, and 100 = all events go through to Sentry
STATUS_CODES_TO_SAMPLING_RATES: a map of status codes -- like 400 or with wildcards like 4xx -- to sampling rates described above

Setting up new database and observability connections

For new connections, refer to our step-by-step guides on connecting to popular database and observability providers including: Sentry, Turso, Neon, Supabase, PlanetScale, Upstash, Xata.

Workers - Performance and size optimization for the Cloudflare adapter for Open Next

Thu, 05 Jun 2025 19:00:00 GMT

With the release of the Cloudflare adapter for Open Next v1.0.0 in May 2025, we already had followups plans to improve performance and size ↗︎.

@opennextjs/cloudflare v1.2 released on June 5, 2025 delivers on these enhancements. By removing babel from the app code and dropping a dependency on @ampproject/toolbox-optimizer, we were able to reduce generated bundle sizes. Additionally, by stopping preloading of all app routes, we were able to improve the cold start time.

This means that users will now see a decrease from 14 to 8MiB (2.3 to 1.6MiB gzipped) in generated bundle size for a Next app created via create-next-app, and typically 100ms faster startup times for their medium-sized apps.

Users only need to update to the latest version of @opennextjs/cloudflare to automatically benefit from these improvements.

Note that we published CVE-2005-6087 ↗︎ for a SSRF vulnerability in the @opennextjs/cloudflare package. The vulnerability has been fixed from @opennextjs/cloudflare v1.3.0 onwards. Please update to any version after this one.

Access, Cloudflare One - Cloudflare One Analytics Dashboards and Exportable Access Report

Thu, 05 Jun 2025 00:00:00 GMT

Cloudflare One now offers powerful new analytics dashboards to help customers easily discover available insights into their application access and network activity. These dashboards provide a centralized, intuitive view for understanding user behavior, application usage, and security posture.

![Cloudflare One Analytics Dashboards](~/assets/images/changelog/cloudflare-one/Analytics Dashboards.png)

Additionally, a new exportable access report is available, allowing customers to quickly view high-level metrics and trends in their application access. A preview of the report is shown below, with more to be found in the report:

Both features are accessible in the Cloudflare Zero Trust dashboard ↗︎, empowering organizations with better visibility and control.

Load Balancing - New Account-Level Load Balancing UI and Private Load Balancers

Wed, 04 Jun 2025 00:00:00 GMT

We've made two large changes to load balancing:

Redesigned the user interface, now centralized at the account level.
Introduced Private Load Balancers to the UI, enabling you to manage traffic for all of your external and internal applications in a single spot.

This update streamlines how you manage load balancers across multiple zones and extends robust traffic management to your private network infrastructure.

Key Enhancements:

Account-Level UI Consolidation:
- Unified Management: Say goodbye to navigating individual zones for load balancing tasks. You can now view, configure, and monitor all your load balancers across every zone in your account from a single, intuitive interface at the account level.
- Improved Efficiency: This centralized approach provides a more streamlined workflow, making it faster and easier to manage both your public-facing and internal traffic distribution.
Private Network Load Balancing:
- Secure Internal Application Access: Create Private Load Balancers to distribute traffic to applications hosted within your private network, ensuring they are not exposed to the public Internet.
- WARP & Magic WAN Integration: Effortlessly direct internal traffic from users connected via Cloudflare WARP or through your Magic WAN infrastructure to the appropriate internal endpoint pools.
- Enhanced Security for Internal Resources: Combine reliable Load Balancing with Zero Trust access controls to ensure your internal services are both performant and only accessible by verified users.

Workers - View an architecture diagram of your Worker directly in the Cloudflare dashboard

Tue, 03 Jun 2025 00:00:00 GMT

You can now visualize, explore and modify your Worker’s architecture directly in the Cloudflare dashboard, making it easier to understand how your application connects to Cloudflare resources like D1 databases, Durable Objects, KV namespaces, and more.

With this new view, you can easily:

Explore existing bindings in a visual, architecture-style diagram
Add and manage bindings directly from the same interface
Discover the full range of compute, storage, AI, and media resources you can attach to your Workers application.

To get started, head to the Cloudflare dashboard ↗︎ and open the Bindings tab of any Workers application.

Workers - Debug, profile, and view logs for your Worker in Chrome Devtools — now supported in the Cloudflare Vite plugin

Fri, 30 May 2025 00:00:00 GMT

You can now debug, profile, view logs, and analyze memory usage for your Worker ↗︎ using Chrome Devtools ↗︎ when your Worker runs locally using the Cloudflare Vite plugin ↗︎.

Previously, this was only possible if your Worker ran locally using the Wrangler CLI ↗︎, and now you can do all the same things if your Worker uses Vite ↗︎.

When you run vite, you'll now see a debug URL in your console:

  VITE v6.3.5  ready in 461 ms

  ➜  Local:   http://localhost:5173/
  ➜  Network: use --host to expose
  ➜  Debug:   http://localhost:5173/__debug
  ➜  press h + enter to show help

Open the URL in Chrome, and an instance of Chrome Devtools will open and connect to your Worker running locally. You can then use Chrome Devtools to debug and introspect performance issues. For example, you can navigate to the Performance tab to understand where CPU time is spent in your Worker:

For more information on how to get the most out of Chrome Devtools, refer to the following docs:

Gateway, Cloudflare One - New Gateway Analytics in the Cloudflare One Dashboard

Thu, 29 May 2025 00:00:00 GMT

Users can now access significant enhancements to Cloudflare Gateway analytics, providing you with unprecedented visibility into your organization's DNS queries, HTTP requests, and Network sessions. These powerful new dashboards enable you to go beyond raw logs and gain actionable insights into how your users are interacting with the Internet and your protected resources.

You can now visualize and explore:

Patterns Over Time: Understand trends in traffic volume and blocked requests, helping you identify anomalies and plan for future capacity.
Top Users & Destinations: Quickly pinpoint the most active users, enabling better policy enforcement and resource allocation.
Actions Taken: See a clear breakdown of security actions applied by Gateway policies, such as blocks and allows, offering a comprehensive view of your security posture.
Geographic Regions: Gain insight into the global distribution of your traffic.

To access the new overview, log in to your Cloudflare Zero Trust dashboard ↗︎ and go to Analytics in the side navigation bar.

Gateway - Gateway Protocol Detection Now Available for Pay-as-you-go and Free Plans

Tue, 27 May 2025 00:00:00 GMT

All Cloudflare One Gateway users can now use Protocol detection logging and filtering, including those on Pay-as-you-go and Free plans.

With Protocol Detection, admins can identify and enforce policies on traffic proxied through Gateway based on the underlying network protocol (for example, HTTP, TLS, or SSH), enabling more granular traffic control and security visibility no matter your plan tier.

This feature is available to enable in your account network settings for all accounts. For more information on using Protocol Detection, refer to the Protocol detection documentation.

Workers - Handle incoming request cancellation in Workers with Request.signal

Thu, 22 May 2025 00:00:00 GMT

In Cloudflare Workers, you can now attach an event listener to Request objects, using the signal property ↗︎. This allows you to perform tasks when the request to your Worker is canceled by the client. To use this feature, you must set the enable_request_signal compatibility flag.

You can use a listener to perform cleanup tasks or write to logs before your Worker's invocation ends. For example, if you run the Worker below, and then abort the request from the client, a log will be written:

index.jsjs

export default {
	async fetch(request, env, ctx) {
		// This sets up an event listener that will be called if the client disconnects from your
		// worker.
		request.signal.addEventListener("abort", () => {
			console.log("The request was aborted!");
		});

		const { readable, writable } = new IdentityTransformStream();
		sendPing(writable);
		return new Response(readable, {
			headers: { "Content-Type": "text/plain" },
		});
	},
};

async function sendPing(writable) {
	const writer = writable.getWriter();
	const enc = new TextEncoder();

	for (;;) {
		// Send 'ping' every second to keep the connection alive
		await writer.write(enc.encode("ping\r\n"));
		await scheduler.wait(1000);
	}
}

index.tsts

export default {
  async fetch(request, env, ctx): Promise<Response> {
    // This sets up an event listener that will be called if the client disconnects from your
    // worker.
    request.signal.addEventListener('abort', () => {
      console.log('The request was aborted!');
    });

    const { readable, writable } = new IdentityTransformStream();
    sendPing(writable);
    return new Response(readable, { headers: { 'Content-Type': 'text/plain' } });
  },
} satisfies ExportedHandler<Env>;

async function sendPing(writable: WritableStream): Promise<void> {
	const writer = writable.getWriter();
	const enc = new TextEncoder();

	for (;;) {
		// Send 'ping' every second to keep the connection alive
		await writer.write(enc.encode('ping\r\n'));
		await scheduler.wait(1000);
	}
}

For more information see the Request documentation.

Cloudflare One - New Applications Added to Zero Trust

Sun, 18 May 2025 00:00:00 GMT

42 new applications have been added for Zero Trust support within the Application Library and Gateway policy enforcement, giving you the ability to investigate or apply inline policies to these applications.

33 of the 42 applications are Artificial Intelligence applications. The others are Human Resources (2 applications), Development (2 applications), Productivity (2 applications), Sales & Marketing, Public Cloud, and Security.

To view all available applications, log in to your Cloudflare Zero Trust dashboard ↗︎, navigate to the App Library under My Team.

For more information on creating Gateway policies, see our Gateway policy documentation.

Access, Cloudflare One - New Access Analytics in the Cloudflare One Dashboard

Fri, 16 May 2025 00:00:00 GMT

A new Access Analytics dashboard is now available to all Cloudflare One customers. Customers can apply and combine multiple filters to dive into specific slices of their Access metrics. These filters include:

Logins granted and denied
Access events by type (SSO, Login, Logout)
Application name (Salesforce, Jira, Slack, etc.)
Identity provider (Okta, Google, Microsoft, onetimepin, etc.)
Users (chris@cloudflare.com, sally@cloudflare.com, rachel@cloudflare.com, etc.)
Countries (US, CA, UK, FR, BR, CN, etc.)
Source IP address
App type (self-hosted, Infrastructure, RDP, etc.)

To access the new overview, log in to your Cloudflare Zero Trust dashboard ↗︎ and find Analytics in the side navigation bar.

Workers, Durable Objects - Durable Objects are now supported in Python Workers

Fri, 16 May 2025 00:00:00 GMT

You can now create Durable Objects using Python Workers. A Durable Object is a special kind of Cloudflare Worker which uniquely combines compute with storage, enabling stateful long-running applications which run close to your users. For more info see here.

You can define a Durable Object in Python in a similar way to JavaScript:

from workers import DurableObject, Response, WorkerEntrypoint

from urllib.parse import urlparse

class MyDurableObject(DurableObject):
    def __init__(self, ctx, env):
        self.ctx = ctx
        self.env = env

    def fetch(self, request):
        result = self.ctx.storage.sql.exec("SELECT 'Hello, World!' as greeting").one()
        return Response(result.greeting)

class Default(WorkerEntrypoint):
    async def fetch(self, request):
        url = urlparse(request.url)
        id = env.MY_DURABLE_OBJECT.idFromName(url.path)
        stub = env.MY_DURABLE_OBJECT.get(id)
        greeting = await stub.fetch(request.url)
        return greeting

Define the Durable Object in your Wrangler configuration file:

{
	"durable_objects": {
		"bindings": [
			{
				"name": "MY_DURABLE_OBJECT",
				"class_name": "MyDurableObject"
			}
		]
	}
}

[[durable_objects.bindings]]
name = "MY_DURABLE_OBJECT"
class_name = "MyDurableObject"

Then define the storage backend for your Durable Object:

{
	"migrations": [
		{
			"tag": "v1", // Should be unique for each entry
			"new_sqlite_classes": [ // Array of new classes
				"MyDurableObject"
			]
		}
	]
}

[[migrations]]
tag = "v1"
new_sqlite_classes = [ "MyDurableObject" ]

Then test your new Durable Object locally by running wrangler dev:

npx wrangler dev

Consult the Durable Objects documentation for more details.

Email security - Open email attachments with Browser Isolation

Thu, 15 May 2025 23:22:49 GMT

You can now safely open email attachments to view and investigate them.

What this means is that messages now have a Attachments section. Here, you can view processed attachments and their classifications (for example, Malicious, Suspicious, Encrypted). Next to each attachment, a Browser Isolation icon allows your team to safely open the file in a clientless, isolated browser with no risk to the analyst or your environment.

To use this feature, you must:

Turn on Allow users to open a remote browser without the device client in your Zero Trust settings.
Have Browser Isolation (BISO) seats assigned.

For more details, refer to our setup guide.

Some attachment types may not render in Browser Isolation. If there is a file type that you would like to be opened with Browser Isolation, reach out to your Cloudflare contact.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Gateway - Domain Categories improvements

Wed, 14 May 2025 00:00:00 GMT

New categories added

Parent ID	Parent Name	Category ID	Category Name
1	Ads	66	Advertisements
3	Business & Economy	185	Personal Finance
3	Business & Economy	186	Brokerage & Investing
21	Security Threats	187	Compromised Domain
21	Security Threats	188	Potentially Unwanted Software
6	Education	189	Reference
9	Government & Politics	190	Charity and Non-profit

Changes to existing categories

Original Name	New Name
Religion	Religion & Spirituality
Government	Government/Legal
Redirect	URL Alias/Redirect

Refer to Gateway domain categories to learn more.

Stream - Introducing Origin Restrictions for Media Transformations

Wed, 14 May 2025 00:00:00 GMT

We are adding source origin restrictions to the Media Transformations beta. This allows customers to restrict what sources can be used to fetch images and video for transformations. This feature is the same as --- and uses the same settings as --- Image Transformations sources.

When transformations is first enabled, the default setting only allows transformations on images and media from the same website or domain being used to make the transformation request. In other words, by default, requests to example.com/cdn-cgi/media can only reference originals on example.com.

Adding access to other sources, or allowing any source, is easy to do in the Transformations tab under Stream. Click each domain enabled for Transformations and set its sources list to match the needs of your content. The user making this change will need permission to edit zone settings.

For more information, learn about Transforming Videos.

Browser Isolation - SAML HTTP-POST bindings support for RBI

Tue, 13 May 2025 00:00:00 GMT

Remote Browser Isolation (RBI) now supports SAML HTTP-POST bindings, enabling seamless authentication for SSO-enabled applications that rely on POST-based SAML responses from Identity Providers (IdPs) within a Remote Browser Isolation session. This update resolves a previous limitation that caused 405 errors during login and improves compatibility with multi-factor authentication (MFA) flows.

With expanded support for major IdPs like Okta and Azure AD, this enhancement delivers a more consistent and user-friendly experience across authentication workflows. Learn how to set up Remote Browser Isolation.

Gateway - New Applications Added for DNS Filtering

Tue, 13 May 2025 00:00:00 GMT

You can now create DNS policies to manage outbound traffic for an expanded list of applications. This update adds support for 273 new applications, giving you more control over your organization's outbound traffic.

With this update, you can:

Create DNS policies for a wider range of applications
Manage outbound traffic more effectively
Improve your organization's security and compliance posture

For more information on creating DNS policies, see our DNS policy documentation.

Data Loss Prevention - Case Sensitive Custom Word Lists

Mon, 12 May 2025 00:00:00 GMT

You can now configure custom word lists to enforce case sensitivity. This setting supports flexibility where needed and aims to reduce false positives where letter casing is critical.

Email security - Open email links with Browser Isolation

Thu, 08 May 2025 23:22:49 GMT

You can now safely open links in emails to view and investigate them.

From Investigation, go to View details, and look for the Links identified section. Next to each link, the Cloudflare dashboard will display an Open in Browser Isolation icon which allows your team to safely open the link in a clientless, isolated browser with no risk to the analyst or your environment. Refer to Open links to learn more about this feature.

To use this feature, you must:

Turn on Allow users to open a remote browser without the device client in your Zero Trust settings.
Have Browser Isolation (RBI) seats assigned.

For more details, refer to our setup guide.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Workers - Improved memory efficiency for WebAssembly Workers

Thu, 08 May 2025 00:00:00 GMT

FinalizationRegistry ↗︎ is now available in Workers. You can opt-in using the enable_weak_ref compatibility flag.

This can reduce memory leaks when using WebAssembly-based Workers, which includes Python Workers and Rust Workers. The FinalizationRegistry works by enabling toolchains such as Emscripten ↗︎ and wasm-bindgen ↗︎ to automatically free WebAssembly heap allocations. If you are using WASM and seeing Exceeded Memory errors and cannot determine a cause using memory profiling, you may want to enable the FinalizationRegistry.

For more information refer to the enable_weak_ref compatibility flag documentation.

Data Loss Prevention - Send forensic copies to storage without DLP profiles

Wed, 07 May 2025 00:00:00 GMT

You can now send DLP forensic copies to third-party storage for any HTTP policy with an Allow or Block action, without needing to include a DLP profile. This change increases flexibility for data handling and forensic investigation use cases.

By default, Gateway will send all matched HTTP requests to your configured DLP Forensic Copy jobs.

Load Balancing - UDP and ICMP Monitor Support for Private Load Balancing Endpoints

Tue, 06 May 2025 00:00:00 GMT

Cloudflare Load Balancing now supports UDP (Layer 4) and ICMP (Layer 3) health monitors for private endpoints. This makes it simple to track the health and availability of internal services that don’t respond to HTTP, TCP, or other protocol probes.

What you can do:

Set up ICMP ping monitors to check if your private endpoints are reachable.
Use UDP monitors for lightweight health checks on non-TCP workloads, such as DNS, VoIP, or custom UDP-based services.
Gain better visibility and uptime guarantees for services running behind Private Network Load Balancing, without requiring public IP addresses.

This enhancement is ideal for internal applications that rely on low-level protocols, especially when used in conjunction with Cloudflare Tunnel, WARP, and Magic WAN to create a secure and observable private network.

Learn more about Private Network Load Balancing or view the full list of supported health monitor protocols.

Browser Isolation - Browser Isolation Overview page for Zero Trust

Thu, 01 May 2025 00:00:00 GMT

A new Browser Isolation Overview page is now available in the Cloudflare Zero Trust dashboard. This centralized view simplifies the management of Remote Browser Isolation (RBI) deployments, providing:

Streamlined Onboarding: Easily set up and manage isolation policies from one location.
Quick Testing: Validate clientless web application isolation with ease.
Simplified Configuration: Configure isolated access applications and policies efficiently.
Centralized Monitoring: Track aggregate usage and blocked actions.

This update consolidates previously disparate settings, accelerating deployment, improving visibility into isolation activity, and making it easier to ensure your protections are working effectively.

To access the new overview, log in to your Cloudflare Zero Trust dashboard ↗︎ and find Browser Isolation in the side navigation bar.

Cloudflare One - Dark Mode for Zero Trust Dashboard

Wed, 30 Apr 2025 00:00:00 GMT

The Cloudflare Zero Trust dashboard ↗︎ now supports Cloudflare's native dark mode for all accounts and plan types.

Zero Trust Dashboard will automatically accept your user-level preferences for system settings, so if your Dashboard appearance is set to 'system' or 'dark', the Zero Trust dashboard will enter dark mode whenever the rest of your Cloudflare account does.

To update your view preference in the Zero Trust dashboard:

Log into the Zero Trust dashboard ↗︎.
Select your user icon.
Select Dark Mode.

To update your view preference in the Core dashboard:

Log into the Cloudflare dashboard ↗︎.
Go to My Profile
For Appearance, choose Dark.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Cloudflare One Appliance supports multiple DNS server IPs

Wed, 30 Apr 2025 00:00:00 GMT

Cloudflare One Appliance DHCP server settings now support specifying multiple DNS server IP addresses in the DHCP pool.

Previously, customers could only configure a single DNS server per DHCP pool. With this update, you can specify multiple DNS servers to provide redundancy for clients at branch locations.

For configuration details, refer to DHCP server.

Gateway - FQDN Filtering For Gateway Egress Policies

Mon, 28 Apr 2025 00:00:00 GMT

Cloudflare One administrators can now control which egress IP is used based on a destination's fully qualified domain name (FDQN) within Gateway Egress policies.

Host, Domain, Content Categories, and Application selectors are now available in the Gateway Egress policy builder in beta.
During the beta period, you can use these selectors with traffic on-ramped to Gateway with the WARP client, proxy endpoints (commonly deployed with PAC files), or Cloudflare Browser Isolation.
- For WARP client support, additional configuration is required. For more information, refer to the WARP client configuration documentation.

This will help apply egress IPs to your users' traffic when an upstream application or network requires it, while the rest of their traffic can take the most performant egress path.

Workers - Cron triggers are now supported in Python Workers

Thu, 24 Apr 2025 00:00:00 GMT

You can now create Python Workers which are executed via a cron trigger.

This is similar to how it's done in JavaScript Workers, simply define a scheduled event listener in your Worker:

from workers import handler

@handler
async def on_scheduled(event, env, ctx):
  print("cron processed")

Define a cron trigger configuration in your Wrangler configuration file:

{
	"triggers": {
		// Schedule cron triggers:
		// - At every 3rd minute
		// - At 15:00 (UTC) on first day of the month
		// - At 23:59 (UTC) on the last weekday of the month
		"crons": [
			"*/3 * * * *",
			"0 15 1 * *",
			"59 23 LW * *"
		]
	}
}

[triggers]
crons = [ "*/3 * * * *", "0 15 1 * *", "59 23 LW * *" ]

Then test your new handler by using Wrangler with the --test-scheduled flag and making a request to /cdn-cgi/local/scheduled?cron=*+*+*+*+*:

npx wrangler dev --test-scheduled

curl "http://localhost:8787/cdn-cgi/local/scheduled?cron=*+*+*+*+*"

Consult the Workers Cron Triggers page for full details on cron triggers in Workers.

Access - Access bulk policy tester

Mon, 21 Apr 2025 00:00:00 GMT

The Access bulk policy tester is now available in the Cloudflare Zero Trust dashboard. The bulk policy tester allows you to simulate Access policies against your entire user base before and after deploying any changes. The policy tester will simulate the configured policy against each user's last seen identity and device posture (if applicable).

Workers, Workers for Platforms - Fixed and documented Workers Routes and Secrets API

Tue, 15 Apr 2025 00:00:00 GMT

Workers Routes API

Previously, a request to the Workers Create Route API always returned null for "script" and an empty string for "pattern" even if the request was successful.

Example requestbash

curl https://api.cloudflare.com/client/v4/zones/$CF_ACCOUNT_ID/workers/routes \
-X PUT \
-H "Authorization: Bearer $CF_API_TOKEN" \
-H 'Content-Type: application/json' \
--data '{ "pattern": "example.com/*", "script": "hello-world-script" }'

Example bad responsejson

{
	"result": {
		"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
		"pattern": "",
		"script": null,
		"request_limit_fail_open": false
	},
	"success": true,
	"errors": [],
	"messages": []
}

Now, it properly returns all values!

Example good responsejson

{
	"result": {
		"id": "bf153a27ba2b464bb9f04dcf75de1ef9",
		"pattern": "example.com/*",
		"script": "hello-world-script",
		"request_limit_fail_open": false
	},
	"success": true,
	"errors": [],
	"messages": []
}

Workers Secrets API

The Workers and Workers for Platforms secrets APIs are now properly documented in the Cloudflare OpenAPI docs. Previously, these endpoints were not publicly documented, leaving users confused on how to directly manage their secrets via the API. Now, you can find the proper endpoints in our public documentation, as well as in our API Library SDKs such as cloudflare-typescript ↗︎ (>4.2.0) and cloudflare-python ↗︎ (>4.1.0).

Note the cloudflare_workers_secret and cloudflare_workers_for_platforms_script_secret Terraform resources ↗︎ are being removed in a future release. This resource is not recommended for managing secrets. Users should instead use the:

Secrets Store with the "Secrets Store Secret" binding on Workers and Workers for Platforms Script Upload
"Secret Text" Binding on Workers Script Upload and Workers for Platforms Script Upload
Workers (and WFP) Secrets API

Data Loss Prevention - New predefined detection entry for ICD-11

Mon, 14 Apr 2025 00:00:00 GMT

You now have access to the World Health Organization (WHO) 2025 edition of the International Classification of Diseases 11th Revision (ICD-11) ↗︎ as a predefined detection entry. The new dataset can be found in the Health Information predefined profile.

ICD-10 dataset remains available for use.

Gateway - HTTP redirect and custom block page redirect

Fri, 11 Apr 2025 00:00:00 GMT

You can now use more flexible redirect capabilities in Cloudflare One with Gateway.

A new Redirect action is available in the HTTP policy builder, allowing admins to redirect users to any URL when their request matches a policy. You can choose to preserve the original URL and query string, and optionally include policy context via query parameters.
For Block actions, admins can now configure a custom URL to display when access is denied. This block page redirect is set at the account level and can be overridden in DNS or HTTP policies. Policy context can also be passed along in the URL.

Learn more in our documentation for HTTP Redirect and Block page redirect.

Stream - Signed URLs and Infrastructure Improvements on Stream Live WebRTC Beta

Fri, 11 Apr 2025 00:00:00 GMT

Cloudflare Stream has completed an infrastructure upgrade for our Live WebRTC beta support which brings increased scalability and improved playback performance to all customers. WebRTC allows broadcasting directly from a browser (or supported WHIP client) with ultra-low latency to tens of thousands of concurrent viewers across the globe.

Additionally, as part of this upgrade, the WebRTC beta now supports Signed URLs to protect playback, just like our standard live stream options (HLS/DASH).

For more information, learn about the Stream Live WebRTC beta.

Access - Cloudflare Zero Trust SCIM User and Group Provisioning Logs

Wed, 09 Apr 2025 00:00:00 GMT

Cloudflare Zero Trust SCIM provisioning now has a full audit log of all create, update and delete event from any SCIM Enabled IdP. The SCIM logs support filtering by IdP, Event type, Result and many more fields. This will help with debugging user and group update issues and questions.

SCIM logs can be found on the Zero Trust Dashboard under Logs -> SCIM provisioning.

Workers - Investigate your Workers with the Query Builder in the new Observability dashboard

Wed, 09 Apr 2025 00:00:00 GMT

The Workers Observability dashboard ↗︎ offers a single place to investigate and explore your Workers Logs.

The Overview tab shows logs from all your Workers in one place. The Invocations view groups logs together by invocation, which refers to the specific trigger that started the execution of the Worker (i.e. fetch). The Events view shows logs in the order they were produced, based on timestamp. Previously, you could only view logs for a single Worker.

The Investigate tab presents a Query Builder, which helps you write structured queries to investigate and visualize your logs. The Query Builder can help answer questions such as:

Which paths are experiencing the most 5XX errors?
What is the wall time distribution by status code for my Worker?
What are the slowest requests, and where are they coming from?
Who are my top N users?

The Query Builder can use any field that you store in your logs as a key to visualize, filter, and group by. Use the Query Builder to quickly access your data, build visualizations, save queries, and share them with your team.

Workers Logs is now Generally Available

Workers Logs is now Generally Available. With a small change to your Wrangler configuration, Workers Logs ingests, indexes, and stores all logs emitted from your Workers for up to 7 days.

We've introduced a number of changes during our beta period, including:

Dashboard enhancements with customizable fields as columns in the Logs view and support for invocation-based grouping
Performance improvements to ensure no adverse impact
Public API endpoints ↗︎ for broader consumption

The API documents three endpoints: list the keys in the telemetry dataset, run a query, and list the unique values for a key. For more, visit our REST API documentation ↗︎.

Visit the docs to learn more about the capabilities and methods exposed by the Query Builder. Start using Workers Logs and the Query Builder today by enabling observability for your Workers:

{
	"observability": {
		"enabled": true,
		"logs": {
			"invocation_logs": true,
			"head_sampling_rate": 1 // optional. default = 1.
		}
	}
}

[observability]
enabled = true

  [observability.logs]
  invocation_logs = true
  head_sampling_rate = 1

Workers - CPU time and Wall time now published for Workers Invocations

Wed, 09 Apr 2025 00:00:00 GMT

You can now observe and investigate the CPU time and Wall time for every Workers Invocations.

For Workers Logs, CPU time and Wall time are surfaced in the Invocation Log..
For Tail Workers, CPU time and Wall time are surfaced at the top level of the Workers Trace Events object.
For Workers Logpush, CPU and Wall time are surfaced at the top level of the Workers Trace Events object. All new jobs will have these new fields included by default. Existing jobs need to be updated to include CPU time and Wall time.

You can use a Workers Logs filter to search for logs where Wall time exceeds 100ms.

You can also use the Workers Observability Query Builder ↗︎ to find the median CPU time and median Wall time for all of your Workers.

Workers - Deploy a Workers application in seconds with one-click

Tue, 08 Apr 2025 00:00:00 GMT

You can now add a Deploy to Cloudflare button to the README of your Git repository containing a Workers application — making it simple for other developers to quickly set up and deploy your project!

The Deploy to Cloudflare button:

Creates a new Git repository on your GitHub/ GitLab account: Cloudflare will automatically clone and create a new repository on your account, so you can continue developing.
Automatically provisions resources the app needs: If your repository requires Cloudflare primitives like a Workers KV namespace, a D1 database, or an R2 bucket, Cloudflare will automatically provision them on your account and bind them to your Worker upon deployment.
Configures Workers Builds (CI/CD): Every new push to your production branch on your newly created repository will automatically build and deploy courtesy of Workers Builds.
Adds preview URLs to each pull request: If you'd like to test your changes before deploying, you can push changes to a non-production branch and preview URLs will be generated and posted back to GitHub as a comment.

To create a Deploy to Cloudflare button in your README, you can add the following snippet, including your Git repository URL:

[![Deploy to Cloudflare](https://deploy.workers.cloudflare.com/button)](https://deploy.workers.cloudflare.com/?url=<YOUR_GIT_REPO_URL>)

Check out our documentation for more information on how to set up a deploy button for your application and best practices to ensure a successful deployment for other developers.

Workers, Workers for Platforms - Full-stack frameworks are now Generally Available on Cloudflare Workers

Tue, 08 Apr 2025 00:00:00 GMT

The following full-stack frameworks now have Generally Available ("GA") adapters for Cloudflare Workers, and are ready for you to use in production:

The following frameworks are now in beta, with GA support coming very soon:

Next.js, supported through @opennextjs/cloudflare ↗︎ is now v1.0-beta.
Angular
SolidJS (SolidStart)

You can also build complete full-stack apps on Workers without a framework:

You can “just use Vite" ↗︎ and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

Get started building today with our framework guides, or read our Developer Week 2025 blog post ↗︎ about all the updates to building full-stack applications on Workers.

Workers - Improved support for Node.js Crypto and TLS APIs in Workers

Tue, 08 Apr 2025 00:00:00 GMT

When using a Worker with the nodejs_compat compatibility flag enabled, the following Node.js APIs are now available:

This make it easier to reuse existing Node.js code in Workers or use npm packages that depend on these APIs.

node:crypto

The full node:crypto ↗︎ API is now available in Workers.

You can use it to verify and sign data:

import { sign, verify } from "node:crypto";

const signature = sign("sha256", "-data to sign-", env.PRIVATE_KEY);
const verified = verify("sha256", "-data to sign-", env.PUBLIC_KEY, signature);

Or, to encrypt and decrypt data:

import { publicEncrypt, privateDecrypt } from "node:crypto";

const encrypted = publicEncrypt(env.PUBLIC_KEY, "some data");
const plaintext = privateDecrypt(env.PRIVATE_KEY, encrypted);

See the node:crypto documentation for more information.

node:tls

The following APIs from node:tls are now available:

This enables secure connections over TLS (Transport Layer Security) to external services.

import { connect } from "node:tls";

// ... in a request handler ...
const connectionOptions = { key: env.KEY, cert: env.CERT };
const socket = connect(url, connectionOptions, () => {
	if (socket.authorized) {
		console.log("Connection authorized");
	}
});

socket.on("data", (data) => {
	console.log(data);
});

socket.on("end", () => {
	console.log("server ends connection");
});

See the node:tls documentation for more information.

Workers - The Cloudflare Vite plugin is now Generally Available

Tue, 08 Apr 2025 00:00:00 GMT

The Cloudflare Vite plugin has reached v1.0 ↗︎ and is now Generally Available ("GA").

When you use @cloudflare/vite-plugin, you can use Vite's local development server and build tooling, while ensuring that while developing, your code runs in workerd ↗︎, the open-source Workers runtime.

This lets you get the best of both worlds for a full-stack app — you can use Hot Module Replacement ↗︎ from Vite right alongside Durable Objects and other runtime APIs and bindings that are unique to Cloudflare Workers.

@cloudflare/vite-plugin is made possible by the new environment API ↗︎ in Vite, and was built in partnership with the Vite team ↗︎.

Framework support

You can build any type of application with @cloudflare/vite-plugin, using any rendering mode, from single page applications (SPA) and static sites to server-side rendered (SSR) pages and API routes.

React Router v7 (Remix) is the first full-stack framework to provide full support for Cloudflare Vite plugin, allowing you to use all parts of Cloudflare's developer platform, without additional build steps.

You can also build complete full-stack apps on Workers without a framework — "just use Vite" ↗︎ and React together, and build a back-end API in the same Worker. Follow our React SPA with an API tutorial to learn how.

Configuration

If you're already using Vite ↗︎ in your build and development toolchain, you can start using our plugin with minimal changes to your vite.config.ts:

vite.config.tsts

import { defineConfig } from "vite";
import { cloudflare } from "@cloudflare/vite-plugin";

export default defineConfig({
	plugins: [cloudflare()],
});

Take a look at the documentation for our Cloudflare Vite plugin for more information!

Workers - Capture up to 256 KB of log events in each Workers Invocation

Mon, 07 Apr 2025 00:00:00 GMT

You can now capture a maximum of 256 KB of log events per Workers invocation, helping you gain better visibility into application behavior.

All console.log() statements, exceptions, request metadata, and headers are automatically captured during the Worker invocation and emitted as JSON object. Workers Logs deserializes this object before indexing the fields and storing them. You can also capture, transform, and export the JSON object in a Tail Worker.

256 KB is a 2x increase from the previous 128 KB limit. After you exceed this limit, further context associated with the request will not be recorded in your logs.

This limit is automatically applied to all Workers.

Email security - CASB and Email security

Tue, 01 Apr 2025 23:22:49 GMT

With Email security, you get two free CASB integrations.

Use one SaaS integration for Email security to sync with your directory of users, take actions on delivered emails, automatically provide EMLs for reclassification requests for clean emails, discover CASB findings and more.

With the other integration, you can have a separate SaaS integration for CASB findings for another SaaS provider.

Refer to Add an integration to learn more about this feature.

This feature is available across these Email security packages:

Enterprise
Enterprise + PhishGuard

Workers - Run Workers for up to 5 minutes of CPU-time

Wed, 26 Mar 2025 00:00:00 GMT

You can now run a Worker for up to 5 minutes of CPU time for each request.

Previously, each Workers request ran for a maximum of 30 seconds of CPU time — that is the time that a Worker is actually performing a task (we still allowed unlimited wall-clock time, in case you were waiting on slow resources). This meant that some compute-intensive tasks were impossible to do with a Worker. For instance, you might want to take the cryptographic hash of a large file from R2. If this computation ran for over 30 seconds, the Worker request would have timed out.

By default, Workers are still limited to 30 seconds of CPU time. This protects developers from incurring accidental cost due to buggy code.

By changing the cpu_ms value in your Wrangler configuration, you can opt in to any value up to 300,000 (5 minutes).

{
	// ...rest of your configuration...
	"limits": {
		"cpu_ms": 300000,
	},
	// ...rest of your configuration...
}

[limits]
cpu_ms = 300_000

For more information on the updates limits, see the documentation on Wrangler configuration for cpu_ms and on Workers CPU time limits.

For building long-running tasks on Cloudflare, we also recommend checking out Workflows and Queues.

Workers - Source Maps are Generally Available

Tue, 25 Mar 2025 00:00:00 GMT

Source maps are now Generally Available (GA). You can now be uploaded with a maximum gzipped size of 15 MB. Previously, the maximum size limit was 15 MB uncompressed.

Source maps help map between the original source code and the transformed/minified code that gets deployed to production. By uploading your source map, you allow Cloudflare to map the stack trace from exceptions onto the original source code making it easier to debug.

With no source maps uploaded: notice how all the Javascript has been minified to one file, so the stack trace is missing information on file name, shows incorrect line numbers, and incorrectly references js instead of ts.

With source maps uploaded: all methods reference the correct files and line numbers.

Uploading source maps and stack trace remapping happens out of band from the Worker execution, so source maps do not affect upload speed, bundle size, or cold starts. The remapped stack traces are accessible through Tail Workers, Workers Logs, and Workers Logpush.

To enable source maps, add the following to your Pages Function's or Worker's wrangler configuration:

{
	"upload_source_maps": true
}

upload_source_maps = true

Workers, Pages, WAF - New Managed WAF rule for Next.js CVE-2025-29927.

Sat, 22 Mar 2025 00:00:00 GMT

Update: Mon Mar 24th, 11PM UTC: Next.js has made further changes to address a smaller vulnerability introduced in the patches made to its middleware handling. Users should upgrade to Next.js versions 15.2.4, 14.2.26, 13.5.10 or 12.3.6. If you are unable to immediately upgrade or are running an older version of Next.js, you can enable the WAF rule described in this changelog as a mitigation.

Update: Mon Mar 24th, 8PM UTC: Next.js has now backported the patch for this vulnerability ↗︎ to cover Next.js v12 and v13. Users on those versions will need to patch to 13.5.9 and 12.3.5 (respectively) to mitigate the vulnerability.

Update: Sat Mar 22nd, 4PM UTC: We have changed this WAF rule to opt-in only, as sites that use auth middleware with third-party auth vendors were observing failing requests.

We strongly recommend updating your version of Next.js (if eligible) to the patched versions, as your app will otherwise be vulnerable to an authentication bypass attack regardless of auth provider.

Enable the Managed Rule (strongly recommended)

This rule is opt-in only for sites on the Pro plan or above in the WAF managed ruleset.

To enable the rule:

Head to Security > WAF > Managed rules in the Cloudflare dashboard for the zone (website) you want to protect.
Click the three dots next to Cloudflare Managed Ruleset and choose Edit
Scroll down and choose Browse Rules
Search for CVE-2025-29927 (ruleId: 34583778093748cc83ff7b38f472013e)
Change the Status to Enabled and the Action to Block. You can optionally set the rule to Log, to validate potential impact before enabling it. Log will not block requests.
Click Next
Scroll down and choose Save

This will enable the WAF rule and block requests with the x-middleware-subrequest header regardless of Next.js version.

Create a WAF rule (manual)

For users on the Free plan, or who want to define a more specific rule, you can create a Custom WAF rule to block requests with the x-middleware-subrequest header regardless of Next.js version.

To create a custom rule:

Head to Security > WAF > Custom rules in the Cloudflare dashboard for the zone (website) you want to protect.
Give the rule a name - e.g. next-js-CVE-2025-29927
Set the matching parameters for the rule match any request where the x-middleware-subrequest header exists per the rule expression below.

(len(http.request.headers["x-middleware-subrequest"]) > 0)

Set the action to 'block'. If you want to observe the impact before blocking requests, set the action to 'log' (and edit the rule later).
Deploy the rule.

Next.js CVE-2025-29927

We've made a WAF (Web Application Firewall) rule available to all sites on Cloudflare to protect against the Next.js authentication bypass vulnerability ↗︎ (CVE-2025-29927) published on March 21st, 2025.

Note: This rule is not enabled by default as it blocked requests across sites for specific authentication middleware.

This managed rule protects sites using Next.js on Workers and Pages, as well as sites using Cloudflare to protect Next.js applications hosted elsewhere.
This rule has been made available (but not enabled by default) to all sites as part of our WAF Managed Ruleset and blocks requests that attempt to bypass authentication in Next.js applications.
The vulnerability affects almost all Next.js versions, and has been fully patched in Next.js 14.2.26 and 15.2.4. Earlier, interim releases did not fully patch this vulnerability.
Users on older versions of Next.js (11.1.4 to 13.5.6) did not originally have a patch available, but this the patch for this vulnerability and a subsequent additional patch have been backported to Next.js versions 12.3.6 and 13.5.10 as of Monday, March 24th. Users on Next.js v11 will need to deploy the stated workaround or enable the WAF rule.

The managed WAF rule mitigates this by blocking external user requests with the x-middleware-subrequest header regardless of Next.js version, but we recommend users using Next.js 14 and 15 upgrade to the patched versions of Next.js as an additional mitigation.

Workers, Pages - Smart Placement is smarter about running Workers and Pages Functions in the best locations

Sat, 22 Mar 2025 00:00:00 GMT

Smart Placement is a unique Cloudflare feature that can make decisions to move your Worker to run in a more optimal location (such as closer to a database). Instead of always running in the default location (the one closest to where the request is received), Smart Placement uses certain “heuristics” (rules and thresholds) to decide if a different location might be faster or more efficient.

Previously, if these heuristics weren't consistently met, your Worker would revert to running in the default location—even after it had been optimally placed. This meant that if your Worker received minimal traffic for a period of time, the system would reset to the default location, rather than remaining in the optimal one.

Now, once Smart Placement has identified and assigned an optimal location, temporarily dropping below the heuristic thresholds will not force a return to default locations. For example in the previous algorithm, a drop in requests for a few days might return to default locations and heuristics would have to be met again. This was problematic for workloads that made requests to a geographically located resource every few days or longer. In this scenario, your Worker would never get placed optimally. This is no longer the case.

Gateway - Secure DNS Locations Management User Role

Fri, 21 Mar 2025 00:00:00 GMT

We're excited to introduce the Cloudflare Zero Trust Secure DNS Locations Write role, designed to provide DNS filtering customers with granular control over third-party access when configuring their Protective DNS (PDNS) solutions.

Many DNS filtering customers rely on external service partners to manage their DNS location endpoints. This role allows you to grant access to external parties to administer DNS locations without overprovisioning their permissions.

Secure DNS Location Requirements:

Mandate usage of Bring your own DNS resolver IP addresses ↗︎ if available on the account.
Require source network filtering for IPv4/IPv6/DoT endpoints; token authentication or source network filtering for the DoH endpoint.

You can assign the new role via Cloudflare Dashboard (Manage Accounts > Members) or via API. For more information, refer to the Secure DNS Locations documentation ↗︎.

Cloudflare One Client - Cloudflare One Agent for Android (version 2.4)

Mon, 17 Mar 2025 00:00:00 GMT

A new GA release for the Android Cloudflare One Agent is now available in the Google Play Store ↗︎. This release includes a new feature allowing team name insertion by URL during enrollment, as well as fixes and minor improvements.

Changes and improvements

Improved in-app error messages.
Improved mobile client login with support for team name insertion by URL.
Fixed an issue preventing admin split tunnel settings taking priority for traffic from certain applications.

Cloudflare One Client - Cloudflare One Agent for iOS (version 1.10)

Mon, 17 Mar 2025 00:00:00 GMT

A new GA release for the iOS Cloudflare One Agent is now available in the iOS App Store ↗︎. This release includes a new feature allowing team name insertion by URL during enrollment, as well as fixes and minor improvements.

Changes and improvements

Improved in-app error messages.
Improved mobile client login with support for team name insertion by URL.
Bug fixes and performance improvements.

Workers - Import `env` to access bindings in your Worker's global scope

Mon, 17 Mar 2025 00:00:00 GMT

You can now access bindings from anywhere in your Worker by importing the env object from cloudflare:workers.

Previously, env could only be accessed during a request. This meant that bindings could not be used in the top-level context of a Worker.

Now, you can import env and access bindings such as secrets or environment variables in the initial setup for your Worker:

import { env } from "cloudflare:workers";
import ApiClient from "example-api-client";

// API_KEY and LOG_LEVEL now usable in top-level scope
const apiClient = ApiClient.new({ apiKey: env.API_KEY });
const LOG_LEVEL = env.LOG_LEVEL || "info";

export default {
	fetch(req) {
		// you can use apiClient or LOG_LEVEL, configured before any request is handled
	},
};

Additionally, env was normally accessed as a argument to a Worker's entrypoint handler, such as fetch. This meant that if you needed to access a binding from a deeply nested function, you had to pass env as an argument through many functions to get it to the right spot. This could be cumbersome in complex codebases.

Now, you can access the bindings from anywhere in your codebase without passing env as an argument:

// helpers.js
import { env } from "cloudflare:workers";

// env is *not* an argument to this function
export async function getValue(key) {
	let prefix = env.KV_PREFIX;
	return await env.KV.get(`${prefix}-${key}`);
}

For more information, see documentation on accessing env.

Workers, Pages - Retry Pages & Workers Builds Directly from GitHub

Mon, 17 Mar 2025 00:00:00 GMT

You can now retry your Cloudflare Pages and Workers builds directly from GitHub. No need to switch to the Cloudflare Dashboard for a simple retry!

Let\u2019s say you push a commit, but your build fails due to a spurious error like a network timeout. Instead of going to the Cloudflare Dashboard to manually retry, you can now rerun the build with just a few clicks inside GitHub, keeping you inside your workflow.

For Pages and Workers projects connected to a GitHub repository:

When a build fails, go to your GitHub repository or pull request
Select the failed Check Run for the build
Select "Details" on the Check Run
Select "Rerun" to trigger a retry build for that commit

Learn more about Pages Builds and Workers Builds.

Cloudflare Network Firewall - Cloudflare IP Ranges List

Thu, 13 Mar 2025 00:00:00 GMT

Magic Firewall now supports a new managed list of Cloudflare IP ranges. This list is available as an option when creating a Magic Firewall policy based on IP source/destination addresses. When selecting "is in list" or "is not in list", the option "Cloudflare IP Ranges" will appear in the dropdown menu.

This list is based on the IPs listed in the Cloudflare IP ranges ↗︎. Updates to this managed list are applied automatically.

Note: IP Lists require a Cloudflare Advanced Network Firewall subscription. For more details about Cloudflare Network Firewall plans, refer to Plans.

Workers - Use the latest JavaScript features with Wrangler CLI v4

Thu, 13 Mar 2025 00:00:00 GMT

We've released the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0. Wrangler v4 is a major release focused on updates to underlying systems and dependencies, along with improvements to keep Wrangler commands consistent and clear.

You can run the following command to install it in your projects:

npm i wrangler@latest

yarn add wrangler@latest

pnpm add wrangler@latest

bun add wrangler@latest

A detailed migration guide is available and if you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub ↗︎.

Going forward, we'll continue supporting Wrangler v3 with bug fixes and security updates until Q1 2026, and with critical security updates until Q1 2027, at which point it will be out of support.

Workers - Set breakpoints and debug your Workers tests with @cloudflare/vitest-pool-workers

Thu, 13 Mar 2025 00:00:00 GMT

You can now debug your Workers tests with our Vitest integration by running the following command:

vitest --inspect --no-file-parallelism

Attach a debugger to the port 9229 and you can start stepping through your Workers tests. This is available with @cloudflare/vitest-pool-workers v0.7.5 or later.

Learn more in our documentation.

Workers - Access your Worker's environment variables from process.env

Tue, 11 Mar 2025 00:00:00 GMT

You can now access environment variables and secrets on process.env when using the nodejs_compat compatibility flag.

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

In Node.js, environment variables are exposed via the global process.env object. Some libraries assume that this object will be populated, and many developers may be used to accessing variables in this way.

Previously, the process.env object was always empty unless written to in Worker code. This could cause unexpected errors or friction when developing Workers using code previously written for Node.js.

Now, environment variables, secrets, and version metadata can all be accessed on process.env.

To opt-in to the new process.env behaviour now, add the nodejs_compat_populate_process_env compatibility flag to your wrangler.json configuration:

{
	// Rest of your configuration
	// Add "nodejs_compat_populate_process_env" to your compatibility_flags array
	"compatibility_flags": ["nodejs_compat", "nodejs_compat_populate_process_env"],
	// Rest of your configuration

compatibility_flags = [ "nodejs_compat", "nodejs_compat_populate_process_env" ]

After April 1, 2025, populating process.env will become the default behavior when both nodejs_compat is enabled and your Worker's compatibility_date is after "2025-04-01".

Digital Experience Monitoring - Cloudflare One Agent now supports Endpoint Monitoring

Fri, 07 Mar 2025 00:00:00 GMT

Digital Experience Monitoring (DEX) provides visibility into device, network, and application performance across your Cloudflare SASE deployment. The latest release of the Cloudflare One agent (v2025.1.861) now includes device endpoint monitoring capabilities to provide deeper visibility into end-user device performance which can be analyzed directly from the dashboard.

Device health metrics are now automatically collected, allowing administrators to:

View the last network a user was connected to
Monitor CPU and RAM utilization on devices
Identify resource-intensive processes running on endpoints

This feature complements existing DEX features like synthetic application monitoring and network path visualization, creating a comprehensive troubleshooting workflow that connects application performance with device state.

For more details refer to our DEX documentation.

Stream - Introducing Media Transformations from Cloudflare Stream

Thu, 06 Mar 2025 00:00:00 GMT

Today, we are thrilled to announce Media Transformations, a new service that brings the magic of Image Transformations to short-form video files, wherever they are stored!

For customers with a huge volume of short video — generative AI output, e-commerce product videos, social media clips, or short marketing content — uploading those assets to Stream is not always practical. Sometimes, the greatest friction to getting started was the thought of all that migrating. Customers want a simpler solution that retains their current storage strategy to deliver small, optimized MP4 files. Now you can do that with Media Transformations.

To transform a video or image, enable transformations for your zone, then make a simple request with a specially formatted URL. The result is an MP4 that can be used in an HTML video element without a player library. If your zone already has Image Transformations enabled, then it is ready to optimize videos with Media Transformations, too.

URL formattext

https://example.com/cdn-cgi/media/<OPTIONS>/<SOURCE-VIDEO>

For example, we have a short video of the mobile in Austin's office. The original is nearly 30 megabytes and wider than necessary for this layout. Consider a simple width adjustment:

Example URLtext

https://example.com/cdn-cgi/media/width=640/<SOURCE-VIDEO>
https://developers.cloudflare.com/cdn-cgi/media/width=640/https://middlecache.ced.cloudflare.com/v1/aus-mobile/aus-mobile.mp4

The result is less than 3 megabytes, properly sized, and delivered dynamically so that customers do not have to manage the creation and storage of these transformed assets.

For more information, learn about Transforming Videos.

Browser Isolation - Gain visibility into user actions in Zero Trust Browser Isolation sessions

Tue, 04 Mar 2025 00:00:00 GMT

We're excited to announce that new logging capabilities for Remote Browser Isolation (RBI) through Logpush are available in Beta starting today!

With these enhanced logs, administrators can gain visibility into end user behavior in the remote browser and track blocked data extraction attempts, along with the websites that triggered them, in an isolated session.

{
	"AccountID": "$ACCOUNT_ID",
	"Decision": "block",
	"DomainName": "www.example.com",
	"Timestamp": "2025-02-27T23:15:06Z",
	"Type": "copy",
	"UserID": "$USER_ID"
}

User Actions available:

Copy & Paste
Downloads & Uploads
Printing

Learn more about how to get started with Logpush in our documentation.

Access - New SAML and OIDC Fields and SAML transforms for Access for SaaS

Mon, 03 Mar 2025 00:00:00 GMT

Access for SaaS applications now include more configuration options to support a wider array of SaaS applications.

SAML and OIDC Field Additions

OIDC apps now include:

Group Filtering via RegEx
OIDC Claim mapping from an IdP
OIDC token lifetime control
Advanced OIDC auth flows including hybrid and implicit flows

SAML apps now include improved SAML attribute mapping from an IdP.

SAML transformations

SAML identities sent to Access applications can be fully customized using JSONata expressions. This allows admins to configure the precise identity SAML statement sent to a SaaS application.

Email security - Use Logpush for Email security detections

Sat, 01 Mar 2025 23:22:49 GMT

You can now send detection logs to an endpoint of your choice with Cloudflare Logpush.

Filter logs matching specific criteria you have set and select from over 25 fields you want to send. When creating a new Logpush job, remember to select Email security alerts as the dataset.

For more information, refer to Enable detection logs.

This feature is available across these Email security packages:

Enterprise
Enterprise + PhishGuard

Workers - Use the latest JavaScript features with Wrangler CLI v4.0.0-rc.0

Fri, 28 Feb 2025 00:00:00 GMT

We've released a release candidate of the next major version of Wrangler, the CLI for Cloudflare Workers — wrangler@4.0.0-rc.0.

You can run the following command to install it and be one of the first to try it out:

npm i wrangler@v4-rc

yarn add wrangler@v4-rc

pnpm add wrangler@v4-rc

bun add wrangler@v4-rc

Unlike previous major versions of Wrangler, which were foundational rewrites ↗︎ and rearchitectures ↗︎ — Version 4 of Wrangler includes a much smaller set of changes. If you use Wrangler today, your workflow is very unlikely to change. Before we release Wrangler v4 and advance past the release candidate stage, we'll share a detailed migration guide in the Workers developer docs. But for the vast majority of cases, you won't need to do anything to migrate — things will just work as they do today. We are sharing this release candidate in advance of the official release of v4, so that you can try it out early and share feedback.

New JavaScript language features that you can now use with Wrangler v4

Version 4 of Wrangler updates the version of esbuild ↗︎ that Wrangler uses internally, allowing you to use modern JavaScript language features, including:

The `using` keyword from Explicit Resource Management

The using keyword from the Explicit Resource Management standard makes it easier to work with the JavaScript-native RPC system built into Workers. This means that when you obtain a stub, you can ensure that it is automatically disposed when you exit scope it was created in:

function sendEmail(id, message) {
  using user = await env.USER_SERVICE.findUser(id);
  await user.sendEmail(message);

  // user[Symbol.dispose]() is implicitly called at the end of the scope.
}

Import attributes

Import attributes ↗︎ allow you to denote the type or other attributes of the module that your code imports. For example, you can import a JSON module, using the following syntax:

import data from "./data.json" with { type: "json" };

Other changes

`--local` is now the default for all CLI commands

All commands that access resources (for example, wrangler kv, wrangler r2, wrangler d1) now access local datastores by default, ensuring consistent behavior.

Clearer policy for the minimum required version of Node.js required to run Wrangler

Moving forward, the active, maintenance, and current versions of Node.js ↗︎ will be officially supported by Wrangler. This means the minimum officially supported version of Node.js you must have installed for Wrangler v4 will be Node.js v18 or later. This policy mirrors how many other packages and CLIs support older versions of Node.js, and ensures that as long as you are using a version of Node.js that the Node.js project itself supports, this will be supported by Wrangler as well.

Features previously deprecated in Wrangler v3 are now removed in Wrangler v4

All previously deprecated features in Wrangler v2 ↗︎ and in Wrangler v3 ↗︎ have now been removed. Additionally, the following features that were deprecated during the Wrangler v3 release have been removed:

Legacy Assets (using wrangler dev/deploy --legacy-assets or the legacy_assets config file property). Instead, we recommend you migrate to Workers assets ↗︎.
Legacy Node.js compatibility (using wrangler dev/deploy --node-compat or the node_compat config file property). Instead, use the nodejs_compat compatibility flag ↗︎. This includes the functionality from legacy node_compat polyfills and natively implemented Node.js APIs.
wrangler version. Instead, use wrangler --version to check the current version of Wrangler.
getBindingsProxy() (via import { getBindingsProxy } from "wrangler"). Instead, use the getPlatformProxy() API ↗︎, which takes exactly the same arguments.
usage_model. This no longer has any effect, after the rollout of Workers Standard Pricing ↗︎.

We'd love your feedback! If you find a bug or hit a roadblock when upgrading to Wrangler v4, open an issue on the cloudflare/workers-sdk repository on GitHub ↗︎.

Email security - Check status of Email security or Area 1

Thu, 27 Feb 2025 23:22:49 GMT

Concerns about performance for Email security or Area 1? You can now check the operational status of both on the Cloudflare Status page ↗︎.

For Email security, look under Cloudflare Sites and Services.

Dashboard is the dashboard for Cloudflare, including Email security
Email security (Zero Trust) is the processing of email
API are the Cloudflare endpoints, including the ones for Email security

For Area 1, under Cloudflare Sites and Services:

Area 1 - Dash is the dashboard for Cloudflare, including Email security
Email security (Area1) is the processing of email
Area 1 - API are the Area 1 endpoints

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Email security - Use DLP Assist for M365

Tue, 25 Feb 2025 23:22:49 GMT

Cloudflare Email security customers who have Microsoft 365 environments can quickly deploy an Email DLP (Data Loss Prevention) solution for free.

Simply deploy our add-in, create a DLP policy in Cloudflare, and configure Outlook to trigger behaviors like displaying a banner, alerting end users before sending, or preventing delivery entirely.

Refer to Outbound Data Loss Prevention to learn more about this feature.

In GUI alert:

Alert before sending:

Prevent delivery:

This feature is available across these Email security packages:

Enterprise
Enterprise + PhishGuard

Cloudflare Images - Bind the Images API to your Worker

Mon, 24 Feb 2025 00:00:00 GMT

You can now interact with the Images API directly in your Worker.

This allows more fine-grained control over transformation request flows and cache behavior. For example, you can resize, manipulate, and overlay images without requiring them to be accessible through a URL.

The Images binding can be configured in the Cloudflare dashboard for your Worker or in the Wrangler configuration file in your project's directory:

{
	"images": {
		"binding": "IMAGES", // i.e. available in your Worker on env.IMAGES
	},
}

[images]
binding = "IMAGES"

Within your Worker code, you can interact with this binding by using env.IMAGES.

Here's how you can rotate, resize, and blur an image, then output the image as AVIF:

const info = await env.IMAGES.info(stream);
// stream contains a valid image, and width/height is available on the info object

const response = (
	await env.IMAGES.input(stream)
		.transform({ rotate: 90 })
		.transform({ width: 128 })
		.transform({ blur: 20 })
		.output({ format: "image/avif" })
).response();

return response;

For more information, refer to Images Bindings.

Workers - Autofix Worker name configuration errors at build time

Thu, 20 Feb 2025 00:00:00 GMT

Small misconfigurations shouldn’t break your deployments. Cloudflare is introducing automatic error detection and fixes in Workers Builds, identifying common issues in your wrangler.toml or wrangler.jsonc and proactively offering fixes, so you spend less time debugging and more time shipping.

Here's how it works:

Before running your build, Cloudflare checks your Worker's Wrangler configuration file (wrangler.toml or wrangler.jsonc) for common errors.
Once you submit a build, if Cloudflare finds an error it can fix, it will submit a pull request to your repository that fixes it.
Once you merge this pull request, Cloudflare will run another build.

We're starting with fixing name mismatches between your Wrangler file and the Cloudflare dashboard, a top cause of build failures.

This is just the beginning, we want your feedback on what other errors we should catch and fix next. Let us know in the Cloudflare Developers Discord, #workers-and-pages-feature-suggestions ↗︎.

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Configure your Magic WAN Connector to connect via static IP assignment

Fri, 14 Feb 2025 00:00:00 GMT

You can now locally configure your Magic WAN Connector to work in a static IP configuration.

This local method does not require having access to a DHCP Internet connection. However, it does require being comfortable with using tools to access the serial port on Magic WAN Connector as well as using a serial terminal client to access the Connector's environment.

For more details, refer to WAN with a static IP address.

Stream - Rewind, Replay, Resume: Introducing DVR for Stream Live

Fri, 14 Feb 2025 00:00:00 GMT

Previously, all viewers watched "the live edge," or the latest content of the broadcast, synchronously. If a viewer paused for more than a few seconds, the player would automatically "catch up" when playback started again. Seeking through the broadcast was only available once the recording was available after it concluded.

Starting today, customers can make a small adjustment to the player embed or manifest URL to enable the DVR experience for their viewers. By offering this feature as an opt-in adjustment, our customers are empowered to pick the best experiences for their applications.

When building a player embed code or manifest URL, just add dvrEnabled=true as a query parameter. There are some things to be aware of when using this option. For more information, refer to DVR for Live.

Email security - Open email links with Security Center

Fri, 07 Feb 2025 23:22:49 GMT

You can now investigate links in emails with Cloudflare Security Center to generate a report containing a myriad of technical details: a phishing scan, SSL certificate data, HTTP request and response data, page performance data, DNS records, what technologies and libraries the page uses, and more.

From Investigation, go to View details, and look for the Links identified section. Select Open in Security Center next to each link. Open in Security Center allows your team to quickly generate a detailed report about the link with no risk to the analyst or your environment.

For more details, refer to Open links.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Workers - Create and deploy Workers from Git repositories

Fri, 07 Feb 2025 00:00:00 GMT

You can now create a Worker by:

Importing a Git repository: Choose an existing Git repo on your GitHub/GitLab account and set up Workers Builds to deploy your Worker.
Deploying a template with Git: Choose from a brand new selection of production ready examples ↗︎ to help you get started with popular frameworks like Astro ↗︎, Remix ↗︎ and Next ↗︎ or build stateful applications with Cloudflare resources like D1 databases, Workers AI or Durable Objects! When you're ready to deploy, Cloudflare will set up your project by cloning the template to your GitHub/GitLab account, provisioning any required resources and deploying your Worker.

With every push to your chosen branch, Cloudflare will automatically build and deploy your Worker.

To get started, go to the Workers dashboard ↗︎.

These new features are available today in the Cloudflare dashboard to a subset of Cloudflare customers, and will be coming to all customers in the next few weeks. Don't see it in your dashboard, but want early access? Add your Cloudflare Account ID to this form ↗︎.

Data Loss Prevention, Gateway - Block files that are password-protected, compressed, or otherwise unscannable.

Mon, 03 Feb 2025 00:00:00 GMT

Gateway HTTP policies can now block files that are password-protected, compressed, or otherwise unscannable.

These unscannable files are now matched with the Download and Upload File Types traffic selectors for HTTP policies:

Password-protected Microsoft Office document
Password-protected PDF
Password-protected ZIP archive
Unscannable ZIP archive

To get started inspecting and modifying behavior based on these and other rules, refer to HTTP filtering.

Workers - Revamped Workers Metrics

Mon, 03 Feb 2025 00:00:00 GMT

We've revamped the Workers Metrics dashboard ↗︎.

Now you can easily compare metrics across Worker versions, understand the current state of a gradual deployment, and review key Workers metrics in a single view. This new interface enables you to:

Drag-and-select using a graphical timepicker for precise metric selection.

Use histograms to visualize cumulative metrics, allowing you to bucket and compare rates over time.
Focus on Worker versions by directly interacting with the version numbers in the legend.

Monitor and compare active gradual deployments.
Track error rates across versions with grouping both by version and by invocation status.
Measure how Smart Placement improves request duration.

Learn more about metrics.

Workers - Transform HTML quickly with streaming content

Fri, 31 Jan 2025 00:00:00 GMT

You can now transform HTML elements with streamed content using HTMLRewriter.

Methods like replace, append, and prepend now accept Response and ReadableStream values as Content.

This can be helpful in a variety of situations. For instance, you may have a Worker in front of an origin, and want to replace an element with content from a different source. Prior to this change, you would have to load all of the content from the upstream URL and convert it into a string before replacing the element. This slowed down overall response times.

Now, you can pass the Response object directly into the replace method, and HTMLRewriter will immediately start replacing the content as it is streamed in. This makes responses faster.

index.jsjs

class ElementRewriter {
	async element(element) {
		// able to replace elements while streaming content
		// the fetched body is not buffered into memory as part
		// of the replace
		let res = await fetch("https://upstream-content-provider.example");
		element.replace(res);
	}
}

export default {
	async fetch(request, env, ctx) {
		let response = await fetch("https://site-to-replace.com");
		return new HTMLRewriter()
			.on("[data-to-replace]", new ElementRewriter())
			.transform(response);
	},
};

index.tsts

class ElementRewriter {
	async element(element: any) {
		// able to replace elements while streaming content
		// the fetched body is not buffered into memory as part
		// of the replace
		let res = await fetch('https://upstream-content-provider.example');
		element.replace(res);
	}
}

export default {
	async fetch(request, env, ctx): Promise<Response> {
		let response = await fetch('https://site-to-replace.com');
		return new HTMLRewriter().on('[data-to-replace]', new ElementRewriter()).transform(response);
	},
} satisfies ExportedHandler<Env>;

For more information, see the HTMLRewriter documentation.

Stream - Expanded language support for Stream AI Generated Captions

Thu, 30 Jan 2025 00:00:00 GMT

Stream's generated captions leverage Workers AI to automatically transcribe audio and provide captions to the player experience. We have added support for these languages:

cs - Czech
nl - Dutch
fr - French
de - German
it - Italian
ja - Japanese
ko - Korean
pl - Polish
pt - Portuguese
ru - Russian
es - Spanish

For more information, learn about adding captions to videos.

Workers - Support for Node.js DNS, Net, and Timer APIs in Workers

Tue, 28 Jan 2025 00:00:00 GMT

When using a Worker with the nodejs_compat compatibility flag enabled, you can now use the following Node.js APIs:

node:net

You can use node:net ↗︎ to create a direct connection to servers via a TCP sockets with net.Socket ↗︎.

index.jsjs

import net from "node:net";

const exampleIP = "127.0.0.1";

export default {
	async fetch(req) {
		const socket = new net.Socket();
		socket.connect(4000, exampleIP, function () {
			console.log("Connected");
		});

		socket.write("Hello, Server!");
		socket.end();

		return new Response("Wrote to server", { status: 200 });
	},
};

index.tsts

import net from "node:net";

const exampleIP = "127.0.0.1";

export default {
  async fetch(req): Promise<Response> {
    const socket = new net.Socket();
    socket.connect(4000, exampleIP, function () {
      console.log("Connected");
    });

    socket.write("Hello, Server!");
    socket.end();

    return new Response("Wrote to server", { status: 200 });
  },
} satisfies ExportedHandler;

Additionally, you can now use other APIs including net.BlockList ↗︎ and net.SocketAddress ↗︎.

Note that net.Server ↗︎ is not supported.

node:dns

You can use node:dns ↗︎ for name resolution via DNS over HTTPS using Cloudflare DNS ↗︎ at 1.1.1.1.

index.jsjs

import dns from "node:dns";

let response = await dns.promises.resolve4("cloudflare.com", "NS");

index.tsts

import dns from 'node:dns';

let response = await dns.promises.resolve4('cloudflare.com', 'NS');

All node:dns functions are available, except lookup, lookupService, and resolve which throw "Not implemented" errors when called.

node:timers

You can use node:timers ↗︎ to schedule functions to be called at some future period of time.

This includes setTimeout ↗︎ for calling a function after a delay, setInterval ↗︎ for calling a function repeatedly, and setImmediate ↗︎ for calling a function in the next iteration of the event loop.

index.jsjs

import timers from "node:timers";

console.log("first");
timers.setTimeout(() => {
	console.log("last");
}, 10);

timers.setTimeout(() => {
	console.log("next");
});

index.tsts

import timers from "node:timers";

console.log("first");
timers.setTimeout(() => {
  console.log("last");
}, 10);

timers.setTimeout(() => {
  console.log("next");
});

Data Loss Prevention - Detect source code leaks with Data Loss Prevention

Mon, 20 Jan 2025 00:00:00 GMT

You can now detect source code leaks with Data Loss Prevention (DLP) with predefined checks against common programming languages.

The following programming languages are validated with natural language processing (NLP).

C
C++
C#
Go
Haskell
Java
JavaScript
Lua
Python
R
Rust
Swift

DLP also supports confidence level for source code profiles.

For more details, refer to DLP profiles.

Access - Export SSH command logs with Access for Infrastructure using Logpush

Wed, 15 Jan 2025 00:00:00 GMT

Cloudflare now allows you to send SSH command logs to storage destinations configured in Logpush, including third-party destinations. Once exported, analyze and audit the data as best fits your organization! For a list of available data fields, refer to the SSH logs dataset.

To set up a Logpush job, refer to Logpush integration.

Workers - Faster Workers Builds with Build Caching and Watch Paths

Sun, 29 Dec 2024 00:00:00 GMT

Workers Builds, the integrated CI/CD system for Workers (currently in beta), now lets you cache artifacts across builds, speeding up build jobs by eliminating repeated work, such as downloading dependencies at the start of each build.

Build Caching: Cache dependencies and build outputs between builds with a shared project-wide cache, ensuring faster builds for the entire team.
Build Watch Paths: Define paths to include or exclude from the build process, ideal for monorepos to target only the files that need to be rebuilt per Workers project.

To get started, select your Worker on the Cloudflare dashboard ↗︎ then go to Settings > Builds, and connect a GitHub or GitLab repository. Once connected, you'll see options to configure Build Caching and Build Watch Paths.

Email security - Escalate user submissions

Thu, 19 Dec 2024 23:22:49 GMT

After you triage your users' submissions (that are machine reviewed), you can now escalate them to our team for reclassification (which are instead human reviewed). User submissions from the submission alias, PhishNet, and our API can all be escalated.

From Reclassifications, go to User submissions. Select the three dots next to any of the user submissions, then select Escalate to create a team request for reclassification. The Cloudflare dashboard will then show you the submissions on the Team Submissions tab.

Refer to User submissions to learn more about this feature.

This feature is available across these Email security packages:

Advantage
Enterprise
Enterprise + PhishGuard

Email security - Increased transparency for phishing email submissions

Thu, 19 Dec 2024 00:00:00 GMT

You now have more transparency about team and user submissions for phishing emails through a Reclassification tab in the Zero Trust dashboard.

Reclassifications happen when users or admins submit a phish to Email security. Cloudflare reviews and - in some cases - reclassifies these emails based on improvements to our machine learning models.

This new tab increases your visibility into this process, allowing you to view what submissions you have made and what the outcomes of those submissions are.

Cloudflare Tunnel, Cloudflare Tunnel for SASE - Troubleshoot tunnels with diagnostic logs

Thu, 19 Dec 2024 00:00:00 GMT

The latest cloudflared build 2024.12.2 ↗︎ introduces the ability to collect all the diagnostic logs needed to troubleshoot a cloudflared instance.

A diagnostic report collects data from a single instance of cloudflared running on the local machine and outputs it to a cloudflared-diag file.

For more information, refer to Diagnostic logs.

Magic Transit, Cloudflare WAN, Network Interconnect - Establish BGP peering over Direct CNI circuits

Tue, 17 Dec 2024 00:00:00 GMT

Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using a Direct CNI on-ramp.

Using BGP peering allows customers to:

Automate the process of adding or removing networks and subnets.
Take advantage of failure detection and session recovery features.

With this functionality, customers can:

Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via CNI.
Secure the session by MD5 authentication to prevent misconfigurations.
Exchange routes dynamically between their devices and their Magic routing table.

Refer to Magic WAN BGP peering or Magic Transit BGP peering to learn more about this feature and how to set it up.

Multi-Cloud Networking - Generate customized terraform files for building cloud network on-ramps

Thu, 05 Dec 2024 00:00:00 GMT

You can now generate customized terraform files for building cloud network on-ramps to Magic WAN.

Magic Cloud can scan and discover existing network resources and generate the required terraform files to automate cloud resource deployment using their existing infrastructure-as-code workflows for cloud automation.

You might want to do this to:

Review the proposed configuration for an on-ramp before deploying it with Cloudflare.
Deploy the on-ramp using your own infrastructure-as-code pipeline instead of deploying it with Cloudflare.

For more details, refer to Set up with Terraform.

CASB - Find security misconfigurations in your AWS cloud environment

Fri, 22 Nov 2024 00:00:00 GMT

You can now use CASB to find security misconfigurations in your AWS cloud environment using Data Loss Prevention.

You can also connect your AWS compute account to extract and scan your S3 buckets for sensitive data while avoiding egress fees. CASB will scan any objects that exist in the bucket at the time of configuration.

To connect a compute account to your AWS integration:

In Cloudflare One ↗︎, go to Cloud & SaaS findings > Integrations.
Find and select your AWS integration.
Select Open connection instructions.
Follow the instructions provided to connect a new compute account.
Select Refresh.

Browser Isolation - Improved non-English keyboard support

Thu, 21 Nov 2024 00:00:00 GMT

You can now type in languages that use diacritics (like á or ç) and character-based scripts (such as Chinese, Japanese, and Korean) directly within the remote browser. The isolated browser now properly recognizes non-English keyboard input, eliminating the need to copy and paste content from a local browser or device.

Workers - Bypass caching for subrequests made from Cloudflare Workers, with Request.cache

Mon, 11 Nov 2024 00:00:00 GMT

You can now use the cache property of the Request interface to bypass Cloudflare's cache when making subrequests from Cloudflare Workers, by setting its value to no-store.

index.jsjs

export default {
	async fetch(req, env, ctx) {
		const request = new Request("https://cloudflare.com", {
			cache: "no-store",
		});
		const response = await fetch(request);
		return response;
	},
};

index.tsts

export default {
  async fetch(req, env, ctx): Promise<Response> {
		const request = new Request("https://cloudflare.com", { cache: 'no-store'});
		const response = await fetch(request);
    return response;
  }
} satisfies ExportedHandler<Environment>

When you set the value to no-store on a subrequest made from a Worker, the Cloudflare Workers runtime will not check whether a match exists in the cache, and not add the response to the cache, even if the response includes directives in the Cache-Control HTTP header that otherwise indicate that the response is cacheable.

If you've tried to use @planetscale/database, redis-js, stytch-node, supabase, axiom-js or have seen the error message The cache field on RequestInitializerDict is not implemented in fetch — you should try again, making sure that the Compatibility Date of your Worker is set to on or after 2024-11-11, or the cache_option_enabled compatibility flag is enabled for your Worker.

Learn how the Cache works with Cloudflare Workers
Enable Node.js compatibility for your Cloudflare Worker
Explore Runtime APIs and Bindings available in Cloudflare Workers

Email security - Use Logpush for Email security user actions

Thu, 07 Nov 2024 23:22:49 GMT

You can now send user action logs for Email security to an endpoint of your choice with Cloudflare Logpush.

Filter logs matching specific criteria you have set or select from multiple fields you want to send. For all users, we will log the date and time, user ID, IP address, details about the message they accessed, and what actions they took.

When creating a new Logpush job, remember to select Audit logs as the dataset and filter by:

Field: "ResourceType"
Operator: "starts with"
Value: "email_security".

For more information, refer to Enable user action logs.

This feature is available across all Email security packages:

Enterprise
Enterprise + PhishGuard

Cloudflare Network Firewall - Search for custom rules using rule name and/or ID

Wed, 02 Oct 2024 00:00:00 GMT

The Magic Firewall dashboard now allows you to search custom rules using the rule name and/or ID.

Log into the Cloudflare dashboard ↗︎ and select your account.
Go to Analytics & Logs > Network Analytics.
Select Magic Firewall.
Add a filter for Rule ID.

Additionally, the rule ID URL link has been added to Network Analytics.

Access - Eliminate long-lived credentials and enhance SSH security with Cloudflare Access for Infrastructure

Tue, 01 Oct 2024 00:00:00 GMT

Organizations can now eliminate long-lived credentials from their SSH setup and enable strong multi-factor authentication for SSH access, similar to other Access applications, all while generating access and command logs.

SSH with Access for Infrastructure uses short-lived SSH certificates from Cloudflare, eliminating SSH key management and reducing the security risks associated with lost or stolen keys. It also leverages a common deployment model for Cloudflare One customers: WARP-to-Tunnel.

SSH with Access for Infrastructure enables you to:

Author fine-grained policy to control who may access your SSH servers, including specific ports, protocols, and SSH users.
Monitor infrastructure access with Access and SSH command logs, supporting regulatory compliance and providing visibility in case of security breach.
Preserve your end users' workflows. SSH with Access for Infrastructure supports native SSH clients and does not require any modifications to users’ SSH configs.

To get started, refer to SSH with Access for Infrastructure.

Risk Score - Exchange user risk scores with Okta

Mon, 17 Jun 2024 00:00:00 GMT

Beyond the controls in Zero Trust, you can now exchange user risk scores with Okta to inform SSO-level policies.

First, configure Cloudflare One to send user risk scores to Okta.

Set up the Okta SSO integration.
In the Cloudflare dashboard ↗︎, go to Zero Trust > Integrations > Identity providers.
In Your identity providers, locate your Okta integration and select Edit.
Turn on Send risk score to Okta.
Select Save.
Upon saving, Cloudflare One will display the well-known URL for your organization. Copy the value.

Next, configure Okta to receive your risk scores.

On your Okta admin dashboard, go to Security > Device Integrations.
Go to Receive shared signals, then select Create stream.
Name your integration. In Set up integration with, choose Well-known URL.
In Well-known URL, enter the well-known URL value provided by Cloudflare One.
Select Create.

Access, Browser Isolation, CASB, Cloudflare Tunnel for SASE, Digital Experience Monitoring, Data Loss Prevention, Email security, Gateway, Multi-Cloud Networking, Cloudflare Network Firewall, Network Flow, Magic Transit, Cloudflare WAN, Network Interconnect, Risk Score, Cloudflare One Client - Explore product updates for Cloudflare One

Sun, 16 Jun 2024 00:00:00 GMT

Welcome to your new home for product updates on Cloudflare One.

Our new changelog lets you read about changes in much more depth, offering in-depth examples, images, code samples, and even gifs.

If you are looking for older product updates, refer to the following locations.

Older product updates

Cloudflare changelogs

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.2100.0)

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2100.0)

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.8.2100.0)

Cloudflare Fundamentals, Cloudflare One, Gateway, Organizations - Cloudflare Organizations is generally available

CASB - Detect organization-specific risks with CASB custom finding types

Key capabilities

Get started

Learn more

Cloudflare WAN, Magic Transit, Cloudflare One - BGP over IPsec and GRE tunnels generally available

Access, Cloudflare One - New strict service token authentication setting for Access

Cloudflare Tunnel - Protect Quick Tunnels with email authentication

Cloudflare One, Access - Simplified permissions for tagging targets with Access for Infrastructure

Workers - Web Crypto adds ML-KEM and ML-DSA support

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2033.1)

Browser Isolation, Gateway, Cloudflare One - Role-based access control for Browser Isolation policies

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.2028.1)

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.2028.1)

Cloudflare Mesh, Cloudflare Tunnel, Cloudflare One, Gateway, Workers VPC - Identify Mesh, Workers VPC, and Cloudflare Tunnel replicas in network logs

Gateway network logs

Network Session Logs

See which tunnel and replica received a session

Workers - Workers Cache — mark cached responses stale with invalidate()

Workers, Cloudflare CLI - Cloudflare CLI is now in beta

Cloudflare Network Firewall, Magic Transit, Cloudflare WAN - Managed Rulesets supported in Unified Routing

Workers - Workers tracing — new getActiveSpan(), recordException(), startSpan(), and setAttributes() APIs

Workers - See every release and gradual deployment on Workers Metrics charts

Access, Cloudflare One - MCP server portals are now generally available

Gateway, Cloudflare One - Traffic Destination selector in Gateway policies

Available traffic destination values

Cloudflare Images - View transformation analytics in Images

Cloudflare One, Cloudflare Mesh - Add Mesh participants with guided onboarding

Access - Automatically manage inactive Access service tokens

Cloudflare One, Access - Private MCP server support for MCP server portals

Workers - Workers Builds now supports Cursor Origin

Workers - Test every pull request in an isolated environment with Worker Previews

Configure each Preview

Deploy and share every change

Inspect and revise before production

Use production-like hostnames

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.1755.1)

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.1755.1)

Workers - Give teammates access to specific Workers directly from the dashboard

Cloudflare WAN, Magic Transit, Cloudflare One - Unified Routing generally available

Cloudflare Tunnel, Cloudflare Tunnel for SASE - cloudflared to deprecate 32-bit Windows and Intel-based macOS builds in 2027

Workers, Durable Objects - Workers traces now automatically include JavaScript RPC session spans

Cloudflare One, Access - Access for Infrastructure now supports tagged targets and tag-based target criteria

Workers - Grant teammates and agents access to specific Workers

Roles designed for how teams build

Durable Objects

Grant access to members and User Groups

Create a scoped API token

Access - Require fresh authentication for SAML identity providers

Data Loss Prevention - Discover where sensitive data goes before you create a Data Loss Prevention policy

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.8.1290.1)

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.8.1290.1)

Browser Isolation, Cloudflare One - Improved iOS tap-to-type experience for Browser Isolation

CASB - New CASB integration for Zoom

Key capabilities

Learn more

Workers - Miniflare v5 prepares local development for the cf CLI

Workers - Python 3.14 for Python Workers

Cloudflare Fundamentals, Workers - Enterprise customers can self-serve CDN upload limits up to 5 GB

Workers - Deploy larger Workers — up to 64 MiB for both free and paid plans

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Define custom applications for breakout and prioritized traffic from the Cloudflare One Appliance dashboard

Cloudflare One Appliance, Cloudflare One, Cloudflare WAN - Configure DHCP options from the dashboard on Cloudflare One Appliance

Cloudflare Images - New in Images: text rasterization and updates to the binding

Cloudflare Tunnel, Cloudflare One, Cloudflare WAN, Cloudflare Mesh - Create multiple Cloudflare Tunnel and Cloudflare Mesh routes at once

Workers - Python Workers now support WSGI web frameworks like Django and Flask

Using web frameworks with Python Workers

WSGI frameworks

ASGI frameworks

Load Balancing - Load Balancing now supports pool sets

Cloudflare One Client - Cloudflare One Client for macOS (version 2026.7.1376.0)

Cloudflare One Client - Cloudflare One Client for Windows (version 2026.7.1376.0)

Cloudflare One Client - Cloudflare One Client for Linux (version 2026.7.1377.0)

Workers, Durable Objects - Durable Objects can use up to ten Dynamic Workers concurrently

Access - Access service token secrets use a scannable format

Access - Grace periods for service token rotation

Access - Temporarily turn off Access service tokens