Changelog

Starting today, you can create custom applications in the Application Library and reference them in Gateway DNS, Network, and HTTP policies. You can define an application with hostnames, IP subnets, or both. Then, optionally add TCP or UDP ports or port ranges to restrict HTTP and Network matching.

This release also improves search and filtering in the Application Library, updates the interfaces, data, and metrics used to review applications, and makes it easier to select and manage applications in the Gateway policy builder.

For more information, refer to Custom applications and Applications and app types.

Data loss prevention (DLP) custom pattern entries can use Cloudflare Workers in your account to validate matches with organization-specific logic. Your Worker can adjust a match's confidence or reject the match.

For setup steps and the Worker contract, refer to Validate data loss prevention matches with Cloudflare Workers.

Cloudflare WAN and Magic Transit IPsec and GRE tunnels now support BGP import and export filtering.

Create reusable filter profiles that specify an allow or deny action and a list of Classless Inter-Domain Routing (CIDR) targets with exact, more-specific, or prefix-length matching. Each tunnel supports one import filter and one export filter.

You can create and assign profiles through the dashboard, API, or Terraform. Profile changes apply without resetting the BGP session.

For configuration details, refer to:

• Filter BGP routes for Cloudflare WAN
• Filter BGP routes for Magic Transit

Cloudflare Gateway now integrates with Cloudflare Workers in public beta on all Zero Trust plans. You can use the Forward action in Gateway HTTP policies to run your own code on matching, permitted traffic without managing a separate proxy.

The Forward action lets you transform HTTP requests and responses, return a coaching page, or run background tasks such as Slack notifications and R2 captures. Your Worker receives the request and Gateway context, including connection metadata, user identity, and device posture when available.

Gateway handles the proxy connection, TLS decryption, and upstream routing. It evaluates HTTP request policies before Forward policies and inspects the final response before returning it to the user.

Gateway inspects the original request body before delivering it to your Worker. A body-inspection Block decision can interrupt the Worker.

To get started, deploy a Worker and configure a Forward policy, or adapt one of the Worker templates.

Stream WebRTC support ↗︎ lets you deliver high quality live video to thousands of concurrent viewers in milliseconds. WebRTC is compatible with native Web APIs and standard protocols, so creators can go live from a browser ↗︎ without needing a separate broadcast application. This powers platforms to build custom experiences with deep feature integration for creators as well as viewers. Here's how to get started with a Stream live input and a browser.

Usage-based billing for WebRTC begins today, October 15, 2026 and follows the standard rates for minutes of video delivered. Refer to pricing ↗︎ for rates.

While in beta, Stream’s WebRTC support was rebuilt from the ground up to leverage Cloudflare Realtime ↗︎’s primitives for stability and scale while managing these components in Stream’s familiar, unified API that makes it easy to build. We also adopted the latest WHIP and WHEP protocol standards for Trickle ICE, server and client offer modes, and counter-offer support for improved player library compatibility and network traversal adaptability. Finally, WebRTC delivery will now be visible in Stream’s analytics ↗︎ and billable usage charts.

Realtime exposes a set of tools and primitives to build applications that connect people, AI systems, and devices together in many-to-many experiences powered by WebRTC. Stream leverages these building-blocks to deliver one-to-many broadcast capabilities, controlled and managed by a single, unified API with features like the built-in player ↗︎ and analytics ↗︎ that make it easy to get started.

First, create a live input ↗︎ using cf ↗︎, the API, or in the Stream Dashboard ↗︎:

# Using cf, the new Cloudflare CLI
cf stream live-inputs create

# Using an API request,
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/stream/live_inputs \
    -H 'Content-Type: application/json' \
    -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
    -X POST

The response will include webRTC and webRTCPlayback properties, each containing a url for WHIP (broadcast) and WHEP (playback) respectively.

Next, you can go live using WHIP directly from a browser or supported broadcast software. Refer to our new tutorial ↗︎ that shows a dependency-free way to broadcast live video with browser-native JavaScript.

Finally, you can play using WHEP using Stream’s built-in player ↗︎, a supported player app/library, or simple JavaScript:

	const pc = new RTCPeerConnection();

	// 1. Ask to receive one audio track and one video track.
	pc.addTransceiver("video", { direction: "recvonly" });
	pc.addTransceiver("audio", { direction: "recvonly" });

	// 2. Attach incoming media to the video element as it arrives.
	const stream = new MediaStream();
	document.getElementById("playback-video").srcObject = stream;
	pc.ontrack = (event) => stream.addTrack(event.track);

	// 3. Create the SDP offer and set it as the local description.
	const offer = await pc.createOffer();
	await pc.setLocalDescription(offer);

	// 4. POST the offer to the WHEP endpoint.
	const response = await fetch(WHEP_URL, {
		method: "POST",
		headers: { "Content-Type": "application/sdp" },
		body: offer.sdp,
	});

	// 5. Apply the SDP answer returned by Cloudflare.
	const answer = await response.text();
	await pc.setRemoteDescription({ type: "answer", sdp: answer });

Learn more in the Stream WebRTC ↗︎ docs or try the all-in-one tutorial ↗︎ for yourself.

@cf/daily-co/phonellm-mini-alpha-2, a model from the Pipecat ↗︎ team at Daily, is now available on Workers AI. PhoneLLM is built for voice agents and other realtime AI applications, where a model has to reply quickly and call the right tool mid-conversation.

In a voice agent, the language model sits between speech-to-text and text-to-speech, so every second it takes adds to the caller's wait. Developers usually choose between a fast model without reasoning mode, which can miss instructions or tool calls, and a slower model in reasoning mode, which handles both well. Pipecat post-trained NVIDIA Nemotron 3 Nano 30B on phone and customer support scenarios so PhoneLLM follows instructions and calls tools better without reasoning mode.

You can use PhoneLLM through the Workers AI binding (env.AI.run()) or the REST API at /ai/run. Pipecat recommends temperature: 0. Also set chat_template_kwargs: { enable_thinking: false }.

Pipecat ↗︎ is an open-source Python framework for building voice agents. Now that Python Workers are generally available, you can run a Pipecat voice agent on Cloudflare.

Our Pipecat voice agent example ↗︎ runs in a Durable Object and uses WebRTC as the voice transport through the Realtime SFU. It uses DeepSeek V4 Flash by default. To deploy it with PhoneLLM, give this prompt to your coding agent:

Copy promptPrompt copied!

For more information, refer to the PhoneLLM Mini model page, Pipecat's model card ↗︎, and Workers AI pricing.

App-aware Cloudflare Access deny redirects include an account_id query parameter when account context is available. Custom block pages can use it to identify the account that owns the application represented by kid.

For example, a custom redirect can include:

https://denied.example.com/?kid=<APP_AUD>&account_id=<ACCOUNT_ID>&original_url=app.example.com%2Fadmin

The account ID helps block-page integrations look up applications through account-scoped APIs. It is context, not proof of authentication or authorization.

For parameter descriptions and an example, refer to Custom redirect URL parameters.

Infrastructure applications now have a configurable session duration with a default value of 24 hours. You can set the session duration when creating or editing an infrastructure application in the dashboard or via the API.

When the session duration elapses, any active SSH connections through that application will be closed, and users will need to reconnect. Previously, infrastructure applications did not enforce a session duration limit. Sessions could persist beyond 24 hours in some cases, but were never guaranteed beyond 10 hours due to Gateway connection limits.

When a target matches multiple infrastructure applications, the shortest session duration applies.

For more information, refer to Session duration.

Nameserver sets are now available in beta to Enterprise accounts. A nameserver set groups two to five custom nameserver names with Cloudflare-assigned IP addresses. You can assign the set to zones in the same account.

Enterprise customers using Cloudflare DNS can create Advanced Custom Nameserver sets. These sets distribute addresses across Advanced anycast network groups to improve resiliency.

Compared to legacy custom_ns sets, modern nameserver sets offer several advantages:

• Sets are reusable objects. Accounts are no longer limited to 5 numbered sets. Create a set once and assign it to one or more zones in the same account.
• Custom address counts. Assign each nameserver up to 3 IPv4 and 3 IPv6 addresses. This allows for more flexible setups.
• Diverse addresses. IPv4 and IPv6 addresses are now both selected from a diverse set of prefixes for increased redundancy.
• Support for Advanced Custom Nameservers. Set advanced to true to allocate addresses from Advanced anycast network groups, providing the same benefits as Cloudflare branded Advanced nameservers to your custom nameservers.
• Explicit changes. Sets are immutable, so adding or removing a nameserver name never changes the configuration of zones that already use a set.

Create a set by sending a POST request to /accounts/{account_id}/dns_settings/nameserver_sets with the following body:

{
	"advanced": true,
	"ip_set": 1,
	"nameservers": [
		{ "name": "ns1.example.com" },
		{ "name": "ns2.example.com" },
		{ "name": "ns3.example.com" }
	]
}

Then, send a PATCH request to /zones/{zone_id}/dns_settings with the returned nameserver set ID:

{
	"nameservers": {
		"type": "custom",
		"nameserver_set_id": "0123456789abcdef0123456789abcdef"
	}
}

This configures the zone to use the nameserver set.

For more information, including other setup steps, refer to Nameserver sets.

Legacy custom_ns sets remain supported. A single account can use both.

Cloudflare Rules supports three new functions for removing surrounding bytes. Use them to remove whitespace before comparing request values. All HTTP products support these functions on all plans:

• trim() removes bytes from both ends.
• trim_start() removes bytes from the start.
• trim_end() removes bytes from the end.

By default, these functions remove ASCII whitespace. An optional constant string specifies a custom set of bytes.

If the input value is nil, these functions return nil.

For example, this expression removes surrounding whitespace before comparing a header value:

trim(http.request.headers["x-label"][0]) eq "approved"

For details, refer to the trim(), trim_start(), and trim_end() function references.

This emergency release adds a new managed rule to block active exploitation of a critical remote code execution (RCE) vulnerability found in popular web frameworks.

Key Findings

Key Findings

• Generic Rules - Remote Code Execution: Attackers can execute arbitrary system commands with web server privileges by sending malicious input containing invalid path sequences during request processing.

Workers Issues provides built-in error monitoring for Cloudflare Workers. It detects production failures and groups related failures into issues without an SDK or application wrapper.

The Cloudflare API MCP server now sends these issues as MCP Events ↗︎, the first event it exposes. MCP clients discover cloudflare.alert.workers_observability_real_time_issue with events/list and subscribe with events/subscribe, scoped to an account or a single Worker. When Issues detects a new or recurring issue, the server posts a signed event to the client's webhook, so an agent can start investigating without polling.

To use it, enable Issues on your Worker and connect https://mcp.cloudflare.com/mcp with the Notifications Write and Workers Observability Write permissions to a client that supports MCP Events webhooks.

The Cloudflare Agents SDK now provides a browserTool that gives your agent a Browser Run browser it can return to on later turns. Your agent can open a website, inspect a page, and come back to it with its tabs, cookies, and login session intact while the browser session remains alive.

When you give browserTool to your agent, the model writes code that drives the browser through the Chrome DevTools Protocol (CDP). Screenshots return as images that an image-capable model can inspect and your UI can display.

To use browserTool, make sure you have Agents SDK v0.28.0 ↗︎ or greater installed. Create a Browser, register it with your object's Lifecycle, and add the tool to a Pi Durable extension registry before opening the harness:

import { Browser, browserRun } from "agents/browser";
import { browserTool } from "agents/browser/pi";

export class MyAgent extends DurableObject {
	// ...

	browser = new Browser({ provider: browserRun(this.env.BROWSER) });

	harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "browser",
				tools: [
					browserTool({
						ctx: this.ctx,
						browser: this.browser,
						loader: this.env.LOADER,
					}),
				],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});

	lifecycle = Lifecycle.install(this).use(this.browser).use(this.harness);
}

import { Browser, browserRun } from "agents/browser";
import { browserTool } from "agents/browser/pi";

export class MyAgent extends DurableObject<Env> {
	// ...

	browser = new Browser({ provider: browserRun(this.env.BROWSER) });

	harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "browser",
				tools: [
					browserTool({
						ctx: this.ctx,
						browser: this.browser,
						loader: this.env.LOADER,
					}),
				],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});

	lifecycle = Lifecycle.install(this).use(this.browser).use(this.harness);
}

Each Pi conversation gets its own active tab by default. Cookies and logins remain shared within the browser.

The browser stays alive between turns, including when the Durable Object hibernates. Its default idle timeout is 10 minutes. If the session expires or crashes, the tool creates a fresh browser and reports restarted: true. The old tabs and login state are gone.

You can also use the persistent browser with the AI SDK and TanStack AI adapters, or connect another harness through the public Browser and CDP APIs.

Refer to persistent browser tools for the complete Pi Durable example, required bindings, and behavior when a tool call is interrupted.

Audit Logs v2 now records view actions for supported endpoints, providing visibility into read activity across Cloudflare products. These actions correspond to GET requests and provide additional context for security investigations and forensic analysis.

The Audit Logs v2 dashboard excludes view actions by default to reduce noise. Remove the default Action type is not view filter to include them, or set Action type to view to show only view actions.

View actions are always available through the Audit Logs v2 API and Logpush, regardless of the dashboard filter.

For more information, refer to the Audit Logs v2 documentation.

You can now request DNS64 through Cloudflare Gateway DNS location settings or Extension Mechanisms for DNS (EDNS) options.

DNS64 synthesizes AAAA records from A records for IPv6-only networks. These networks require network address translation from IPv6 to IPv4 (NAT64).

Turn on Enable DNS64 for a location, or include an empty EDNS option 65051 in individual queries. Both mechanisms support UDP, TCP, DNS over TLS (DoT), and DNS over HTTPS (DoH).

For example, request DNS64 through EDNS with dig:

dig @"<DNS_RESOLVER_IP>" ipv4only.arpa AAAA +ednsopt=65051 +short

The existing cf-dns-options: dns64 DoH header remains supported independently. DNS64 is off by default. Each mechanism independently requests synthesis.

For configuration, API update behavior, and request examples, refer to DNS64.

The Core Web Vitals tell you whether a page is slow but beyond perceived load time, layout instability, or responsiveness they do not guide you to the problematic area directly. To help you with this, Real User Monitoring (RUM) in Web Analytics now breaks Largest Contentful Paint (LCP) and Interaction to Next Paint (INP) into their respective sub-parts. It also splits connection time into TCP and TLS. You can see this visualised in the dashboard or query it through the GraphQL Analytics API.

LCP is broken into four phases, so you can see which one is impacting your perceived load time:

1. Time to First Byte: how long the browser waits for the HTML document (timeToFirstByte in GraphQL).
2. Resource load delay: how long the browser takes to discover the LCP resource after the document starts arriving (lcpResourceLoadDelay).
3. Resource load duration: how long it takes to download that resource (lcpResourceLoadTime).
4. Element render delay: the gap between the resource arriving and the element appearing on screen (lcpElementRenderDelay).

You do not have to remember all this detail, there are tooltips available to guide you next to each sub-part metric in the dashboard.

INP is broken into three phases, guiding you to the area slowing down responsiveness:

1. Input delay: how long an interaction (click, tap or key press) is blocked before it can be processed (inpInputDelay).
2. Processing duration: how long your event handlers take to run (inpProcessingDuration).
3. Presentation delay: how long the browser takes to render the next frame after the handlers finish (inpPresentationDelay).

The page load timing breakdown now separates connection setup from the TLS handshake, so you can tell a slow network path from a slow TLS negotiation:

• Connection time (excluding TLS) (connectionTimeWithoutTLS)
• TLS handshake time: (tlsTime).

Note: we've retained connectionTime in the GraphQL API so you can still analyze the combined time.

The sub-parts are available on rumWebVitalsEventsAdaptiveGroups as percentiles, for example: lcpResourceLoadDelayP50 or inpInputDelayP50. The connection split is available on rumPerformanceEventsAdaptiveGroups as connectionTimeWithoutTLSP50 and tlsTimeP50, and so on for the other percentiles.

The percentiles available are: P25, P50, P75, P90, P95, P99, P999. All values are in microseconds. A negative value means the data is not available.

Head to the 'Core Web Vitals' section, here you can scroll down the report to see the sub-parts. The 'Page Load' section contains the Connection and TLS negotiation durations.

For more on the data, refer to the Web Analytics docs and the GraphQL Analytics API docs.

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

This hotfix resolves an issue where the client could repeatedly disconnect and reconnect when a split tunnel configuration with hostname-based entries failed to apply.

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 the client could repeatedly disconnect and reconnect when a split tunnel configuration with hostname-based entries failed to apply.

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 the client could repeatedly disconnect and reconnect when a split tunnel configuration with hostname-based entries failed to apply.

The Cloudflare Agents SDK now provides a web_fetch tool that reads webpages, PDFs, and supported Office documents, using Workers AI Markdown Conversion to turn them into text the model can read. The tool requests Markdown directly from sites that support Markdown for Agents and formats JSON for the model.

When you give the web_fetch tool to your agent, the model provides a URL and receives back the page content, along with the final URL, HTTP status, and content type. Long pages come back in smaller sections, with an offset the model can use to continue reading. You control which hosts the agent can fetch, response size, timeouts, and redirects.

When you also provide the web_search tool to your agent, the model is told to use web_fetch to read the pages that web_search returns.

To use the web_fetch tool, make sure you have Agents SDK v0.28.0 ↗︎ or greater installed, and add it to a Pi Durable extension registry before opening the harness:

import { webFetchTool } from "agents/webfetch/pi";

export class MyAgent extends DurableObject {
	// ...

	harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "web-tools",
				tools: [webFetchTool({ binding: this.env.AI })],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});
}

import { webFetchTool } from "agents/webfetch/pi";

export class MyAgent extends DurableObject<Env> {
	// ...

	readonly harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "web-tools",
				tools: [webFetchTool({ binding: this.env.AI })],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});
}

The web_fetch tool works with any harness. The SDK includes AI SDK and TanStack AI adapters. If you use a different harness, or need to fetch a page without calling a model, use fetchWeb(), windowWebFetchPage(), and renderWebFetchPage() from agents/webfetch. Direct fetching does not require a Durable Object or browser.

For setup, examples, and request controls, refer to Web fetch.

The Agents SDK now supports OpenCode 2.0 ↗︎ through the experimental OpenCodeHarness. Run OpenCode inside a plain Durable Object, with sessions stored in SQLite and Lifecycle jobs that wake interrupted work after eviction.

The agents/models/opencode provider connects OpenCode to Workers AI through the AI binding. OpenCode plugins extend the harness with custom tools, remote MCP servers, and skills. Refer to OpenCode's Cloudflare SDK documentation ↗︎ for the embedded host API.

Copy promptPrompt copied!

Install Agents SDK 0.28.0 or later with the OpenCode packages:

npm i agents@latest @opencode/sdk@2 @opencode/plugin@2

yarn add agents@latest @opencode/sdk@2 @opencode/plugin@2

pnpm add agents@latest @opencode/sdk@2 @opencode/plugin@2

bun add agents@latest @opencode/sdk@2 @opencode/plugin@2

Create a harness and install a Lifecycle on your Durable Object:

import { DurableObject } from "cloudflare:workers";
import { Lifecycle } from "agents/lifecycle";
import { OpenCodeWorkerd } from "@opencode/sdk/workerd";
import { OpenCodeHarness } from "agents/harness/opencode";
import { createAI } from "agents/models/opencode";
import workerTools from "./worker-tools";

export class Assistant extends DurableObject {
	ai = createAI({ binding: this.env.AI });
	harness = new OpenCodeHarness({
		opencode: ({ storage }) =>
			OpenCodeWorkerd.create({
				storage,
				models: { fetch: false },
				plugins: [this.ai.plugin, workerTools],
			}),
		defaults: {
			model: this.ai("@cf/moonshotai/kimi-k2.7-code", {
				reasoningEffort: "low",
			}),
			agent: "build",
		},
	});

	lifecycle = Lifecycle.install(this).use(this.harness);

	async ask(prompt) {
		const { status, text, reason } = await this.harness.prompt(prompt);
		return { status, text, reason };
	}
}

import { DurableObject } from "cloudflare:workers";
import { Lifecycle } from "agents/lifecycle";
import { OpenCodeWorkerd } from "@opencode/sdk/workerd";
import { OpenCodeHarness } from "agents/harness/opencode";
import { createAI } from "agents/models/opencode";
import workerTools from "./worker-tools";

export class Assistant extends DurableObject<Env> {
	ai = createAI({ binding: this.env.AI });
	harness = new OpenCodeHarness({
		opencode: ({ storage }) =>
			OpenCodeWorkerd.create({
				storage,
				models: { fetch: false },
				plugins: [this.ai.plugin, workerTools],
			}),
		defaults: {
			model: this.ai("@cf/moonshotai/kimi-k2.7-code", {
				reasoningEffort: "low",
			}),
			agent: "build",
		},
	});

	lifecycle = Lifecycle.install(this).use(this.harness);

	async ask(prompt: string) {
		const { status, text, reason } = await this.harness.prompt(prompt);
		return { status, text, reason };
	}
}

The OpenCode harness guide includes the workerTools plugin, Wrangler configuration, and session APIs. The working example ↗︎ adds a browser UI, WebSocket streaming, and Workspace tools from @cloudflare/computer for files and code execution.

The Cloudflare Agents SDK now provides a web_search tool that searches the public web through the Cloudflare Web Search API, powered by ceramic.ai, Exa, and Linkup.

When you give the web_search tool to your agent, the model provides a query and max results, and receives back a short numbered list of titles, URLs, and trimmed descriptions. When you also provide the web_fetch tool to your agent, the model is told to use it to read the pages that the web_search tool returns.

To use the web_search tool, make sure you have Agents SDK v0.27.0 ↗︎ or greater installed, and add it to a Pi Durable extension registry before opening the harness:

import { webSearchTool } from "agents/websearch/pi";

export class MyAgent extends DurableObject {
	// ...

	harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "web-tools",
				tools: [webSearchTool({ binding: this.env.AI, provider: "exa" })],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});
}

import { webSearchTool } from "agents/websearch/pi";

export class MyAgent extends DurableObject<Env> {
	// ...

	readonly harness = new PiHarness({
		harness: async ({ storage, context }) => {
			this.registry.install({
				name: "web-tools",
				tools: [webSearchTool({ binding: this.env.AI, provider: "exa" })],
			});

			// ...

			return Harness.open(
				storage,
				{ models, registry: this.registry },
				context,
			);
		},
	});
}

The SDK also includes AI SDK and TanStack AI adapters. To search without a model, such as from a scheduled job, use createAIWebSearch() or createHTTPWebSearch() from agents/websearch.

For setup, options, and error handling, refer to Web search.

You can now manually request an API Shield schema learning run without waiting for the weekly schedule. Use this during testing after sending representative traffic to your API.

In Web Assets > Operations, open the More options menu for the operations table and select Ad-hoc learn schema. In the Schema learning dialog, select Run learning. The run covers the entire zone and uses observed traffic. Existing learning thresholds still apply.

The dialog shows the learning status and last completed run for the zone. The Learned schema view shows the learning result and last learning run for each operation. You can review individual results while the zone-wide run continues.

For instructions and traffic requirements, refer to Run schema learning manually.

The Cloudflare dashboard now combines Zero Trust and main dashboard navigation. You can move between Cloudflare products from the same navigation.

All customers can browse Zero Trust products from the primary navigation.

Zero Trust customers can also access other services from this navigation. These include the developer platform, account memberships, and resource tagging.

As part of this change, the Zero Trust Network items were removed in favor of the new experiences available under Networking navigation, and Resolvers & Proxies was moved under Traffic Controls (previously Traffic Policies).

This update is available to all customers starting today.

For more information, refer to the Cloudflare One documentation.

You can now create Cloudflare Queues with jurisdictional restrictions, ensuring that messages published to a queue are stored and processed only within a specific jurisdiction. This helps you comply with data residency requirements such as the GDPR ↗︎ or FedRAMP ↗︎.

To create a jurisdiction-restricted queue with the Cloudflare CLI (cf), use the --jurisdiction flag:

cf queues create --queue-name my-eu-queue --jurisdiction eu

You can also pass a jurisdiction parameter when calling the Create Queue endpoint:

curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/queues \
  --request POST \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "queue_name": "my-eu-queue",
    "jurisdiction": "eu"
  }'

Supported jurisdictions are eu (European Union), us (United States), and fedramp (FedRAMP-Moderate data centers). Jurisdiction can only be set when a queue is created and cannot be changed afterwards.

For more information, refer to Queues data location.