Cloudflare Release Notes

Browser Run Queues

Browser Run crawl jobs can publish lifecycle events to Cloudflare Queues. Subscribe to started, updated, and finished events to track progress or trigger downstream processing without polling.

To create an account-level subscription, run the following command:

npmyarnpnpm

npx wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

yarn wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

pnpm wrangler queues subscription create <QUEUE_NAME> --source browserRun --events crawl.started,crawl.updated,crawl.finished

For payload examples, refer to the Browser Run event schemas.

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 …

New R2 product-level Metrics page in the Cloudflare dashboard shows bandwidth usage. You can view usage across all buckets or per bucket.

Go to R2 Metrics ↗ R2 upload and download throughput across all buckets over 24 hours

Bandwidth throughput is split by object upload and download. The GraphQL Analytics API exposes the same bandwidth usage metrics that power the dashboard for your queries and analytics.

For more information, refer to R2 metrics and analytics.

You can now declare the Workflows a Worker defines in the exports field of your Wrangler configuration file. Previously, a Worker could only define a Workflow through a workflows binding, even when the Worker never called the Workflow itself.

Key each entry by the name of the class that extends WorkflowEntrypoint:

{
	"exports": {
		"MyWorkflow": {
			"type": "workflow",
			"name": "my-workflow",
			"limits": {
				"steps": 25000,
			},
			"schedules": ["0 * * * *"],
		},
	},
}

[exports.MyWorkflow]
type = "workflow"
name = "my-workflow"
schedules = [ "0 * * * *" ]

  [exports.MyWorkflow.limits]
  steps = 25_000

A workflow export accepts the same settings as a workflows binding: limits, schedules, and default_retention. When you run wrangler deploy, Wrangler creates or updates the Workflow with these settings.

You can declare a Workflow as both a binding and an export. Both declarations must use the same class, and cannot set the same setting to different values.

A workflows binding to a Workflow in another Worker cannot use the same name as a Workflow export in this Worker. Workflow names are unique per account.

Workflow exports require Wrangler 4.139.0 or above.

For more information, refer to Declare Workflows in exports.

R2

New R2 product-level Metrics page in the Cloudflare dashboard shows bandwidth usage. You can view usage across all buckets or per bucket.

Go to R2 Metrics ↗ R2 upload and download throughput across all buckets over 24 hours

Bandwidth throughput is split by object upload and download. The GraphQL Analytics API exposes the same bandwidth usage metrics that power the dashboard for your queries and analytics.

For more information, refer to R2 metrics and analytics.

Durable Objects

Durable Object name searches in the Cloudflare dashboard now accept up to 128 characters, up from 20.

Search results and recent invocation lists show up to 128 characters before being truncated with an ellipsis. This limit applies to the object filter on the Metrics tab and object search in Data Studio.

For more information, refer to Metrics and analytics and Data Studio.

You can now declare the Workflows a Worker defines in the exports field of your Wrangler configuration file. Previously, a Worker could only define a Workflow through a workflows binding, even when the Worker never called the Workflow itself.

Key each entry by the name of the class that extends WorkflowEntrypoint:

{
	"exports": {
		"MyWorkflow": {
			"type": "workflow",
			"name": "my-workflow",
			"limits": {
				"steps": 25000,
			},
			"schedules": ["0 * * * *"],
		},
	},
}

[exports.MyWorkflow]
type = "workflow"
name = "my-workflow"
schedules = [ "0 * * * *" ]

  [exports.MyWorkflow.limits]
  steps = 25_000

A workflow export accepts the same settings as a workflows binding: limits, schedules, and default_retention. When you run wrangler deploy, Wrangler creates or updates the Workflow with these settings.

You can declare a Workflow as both a binding and an export. Both declarations must use the same class, and cannot set the same setting to different values.

A workflows binding to a Workflow in another Worker cannot use the same name as a Workflow export in this Worker. Workflow names are unique per account.

Workflow exports require Wrangler 4.139.0 or above.

For more information, refer to Declare Workflows in exports.

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 …

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.

Adding a Cloudflare Mesh node through the guided dashboard workflow

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. …

Cloudflare Images

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 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.

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. …

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.

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. …

This release introduces new threat detections to enhance protection against Server-Side Request Forgery (SSRF) attempts using non-standard IP notations or jar loopback payloads, alongside new defenses against Server-Side Template Injection (SSTI) targeting Jinja environments.

Ruleset

Rule ID

Legacy Rule ID

Description

Previous Action

New Action

Comments

Cloudflare Managed Ruleset

...5f21b651

N/A

SSRF - Cloud,Link-Local non-standard IP notation

Log

Block

This is a new detection.

Cloudflare Managed Ruleset

...0f0313d6

N/A

SSRF - Block jar HTTP loopback payload

Log

Block

This is a new detection.

Cloudflare Managed Ruleset

...75cd912a

N/A

SSRF - Local non-standard IP notation

Log

Block

This is a new detection.

Cloudflare Managed Ruleset

...a1ba83f6

N/A

SSTI - Jinja Dangerous Globals Chain

Log

Block

This is a new detection.

The concat() function in Cloudflare Rules now accepts up to 32 arguments, increased from 16. This allows you to build richer dynamic values directly in Rules expressions and simplify configurations that combine request data.

A common use case is adding a request header that sends context to your origin. The following Rulesets API request adds a Request Header Transform Rule to an existing http_request_late_transform phase ruleset. Its 18-argument expression combines request and network information into one header value:

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets/$RULESET_ID/rules" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "ref": "add_request_context_header",
    "description": "Add request context for the origin",
    "expression": "true",
    "action": "rewrite",
    "action_parameters": {
      "headers": {
        "X-Request-Context": {
          "operation": "set",
          "expression": "concat(\"ip=\", to_string(ip.src), \";country=\", ip.src.country, \";host=\", http.host, \";method=\", http.request.method, \";path=\", http.request.uri.path, \";query=\", http.request.uri.query, \";ray-id=\", cf.ray_id, \";asn=\", to_string(ip.src.asnum), \";user-agent=\", http.user_agent)"
        }
      }
    }
  }'
``` …

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. …