Changelog

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.

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

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)"
        }
      }
    }
  }'

For more information, refer to the concat() function reference and HTTP request header modification.

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.

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:

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.

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.

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

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/

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 Run browser bindings now provide typed methods for session management and DevTools operations. You can acquire a session, connect a browser client, create Live View URLs, manage targets, and close sessions without constructing HTTP requests.

The new acquire() and launch() methods also accept outboundByHost. This lets you route requests for selected hostnames through another Worker, including a Worker that adds authentication or reaches a private service.

const connection = await env.BROWSER.launch({
	outboundByHost: {
		"private.example.test": env.OUTBOUND,
	},
});

const connection = await env.BROWSER.launch({
	outboundByHost: {
		"private.example.test": env.OUTBOUND,
	},
});

Use connectSession(sessionId) when you need to acquire and connect in separate steps. The method returns a session-pinned webSocket Fetcher for a CDP client.

The binding also includes session methods for Live View, active sessions, session history, limits, session details, and cleanup. The nested devtools binding provides typed methods for browser version information, protocol descriptions, and target operations such as listing, creating, activating, and closing targets.

Refer to the Browser binding API documentation for method signatures and the outbound Worker feature guide for routing examples.

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.

Browser Run Session Recordings now include an Inspect panel, giving you more context to understand what happened during a browser session without having to reproduce it.

The Logs tab lets you search captured console output and filter messages by level. The Network tab shows each request's method, status, headers, payload, response, and timing waterfall, with the option to download the session's network activity as a HAR file.

You can also retrieve recorded network activity via API as raw JSON or a HAR file for use in your own debugging and analysis workflows.

The DOM tab provides an expandable view of the page structure at the end of the recording and lets you copy the reconstructed HTML. For sessions with multiple browser tabs, the Inspect panel updates to show data for the tab selected in the recording viewer.

To get started, enable recording when launching a browser session. After the session closes, open Browser Run > Runs in the Cloudflare dashboard ↗ and select the recording icon next to the session.

Refer to the Session recording documentation for setup instructions and current limits.

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.

Logpush jobs can now exclude identified distributed denial-of-service (DDoS) attack traffic. This option reduces attack traffic in delivered logs.

It supports the http_requests, firewall_events, and network_analytics_logs datasets.

In the dashboard, select Exclude DDoS attack traffic under Advanced Options. With the API, add this field to a job request:

{
	"filter_attack_traffic": true
}

For more information, refer to API configuration.

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.

You can now delete one or up to 100 Workflow instances and their stored state via the Workflows API or Wrangler 4.125.0 and later. Deleting an instance frees its stored state and stops its current execution. Storage billing is based on the average daily peak.

Delete one instance by calling delete() on its handle:

const instance = await env.MY_WORKFLOW.get("instance-abc");
await instance.delete();

If a Workflow deletes its own instance, execution stops during await instance.delete(). Code after the call does not run.

Delete multiple instances by calling deleteBatch() on the Workflow binding:

const result = await env.MY_WORKFLOW.deleteBatch([
	"instance-abc",
	"instance-def",
]);

console.log(result.deleted);
console.log(result.errors);

The batch result contains { id } entries for successful deletions and per-instance errors. IDs that do not exist are returned as errors. Duplicate IDs count toward the limit and are deleted once, with the result repeated for each input position.

Wrangler accepts positional instance IDs, a file containing a top-level JSON array of strings, or both, up to 100 IDs total. Use latest to delete the most recently created instance. Use --local against a local wrangler dev session:

["instance-abc", "instance-def"]

npx wrangler workflows instances delete my-workflow <INSTANCE_ID>
npx wrangler workflows instances delete my-workflow <INSTANCE_ID> <INSTANCE_ID>
npx wrangler workflows instances delete my-workflow latest
npx wrangler workflows instances delete my-workflow --filename ./instance-ids.json
npx wrangler workflows instances delete my-workflow <INSTANCE_ID> --local

For more information, refer to Delete Workflow instances, delete, and deleteBatch.

We're expanding how customers create accounts across Cloudflare, making it easier to self-serve account creation in the dashboard, automate standalone account creation with user-owned API tokens or OAuth access tokens, and create Free accounts directly within Enterprise Organizations.

Dashboard account creation: All cloudflare customers can create additional Free accounts directly through self-serve flows in the Cloudflare dashboard.

Enterprise Organization account creation: Super Administrators can now create up to five Free accounts directly within an Enterprise Organization. This makes it easier to provision and manage additional accounts and directly associate them with your Organization.

API and OAuth account creation: Customers can now create standalone Free accounts programmatically via User-owned API tokens or OAuth access tokens.

For more information:

• Create a Free account in the dashboard
• Create an account via the API
• Create Free accounts in an Enterprise Organization

Cloudflare Rules now validates ruleset changes before deployment, helping you catch invalid expressions, action parameters, permission issues, unavailable features, and quota limits without publishing the configuration.

The Cloudflare dashboard performs this validation automatically when you create or update rules from Security > Security rules or Rules > Overview.

Supported Rulesets API mutation endpoints now also accept the dry_run=true query parameter. A dry run performs the same authorization and server-side validation checks as the requested change, but does not persist or publish it. Successful operations that normally return a 200 response return result: null. Operations that normally return 204 continue to do so.

Add dry_run=true to a Rulesets API request to validate it without creating the ruleset:

curl --request POST \
  "https://api.cloudflare.com/client/v4/zones/$ZONE_ID/rulesets?dry_run=true" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "name": "Custom firewall rules",
    "kind": "zone",
    "phase": "http_request_firewall_custom",
    "rules": [
      {
        "action": "block",
        "expression": "ip.src.country eq \"GB\"",
        "description": "Block requests from the United Kingdom",
        "enabled": true
      }
    ]
  }'

For more information, refer to Validate rule changes before deployment.

The rejectIfBusy option lets synchronous Workers AI inference requests fail when capacity is unavailable. Use it when your application should not wait in a capacity queue.

Pass the option as the third argument to the Workers AI binding:

const response = await env.AI.run(
	"@cf/google/gemma-4-26b-a4b-it",
	{
		messages: [{ role: "user", content: "Explain capacity queues." }],
	},
	{ rejectIfBusy: true },
);

const response = await env.AI.run(
	"@cf/google/gemma-4-26b-a4b-it",
	{
		messages: [{ role: "user", content: "Explain capacity queues." }],
	},
	{ rejectIfBusy: true },
);

For the native REST API, add the option to the request body:

curl --request POST \
  --url "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/ai/run/@cf/google/gemma-4-26b-a4b-it" \
  --header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
  --header "Content-Type: application/json" \
  --data '{
    "messages": [{ "role": "user", "content": "Explain capacity queues." }],
    "options": { "rejectIfBusy": true }
  }'

Refer to Reject busy requests for OpenAI-compatible usage and error behavior.

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.

Python Workers can now connect to PostgreSQL and MySQL through Hyperdrive.

For setup, code examples, and limitations, refer to Use Hyperdrive from Python Workers.

R2 Data Catalog now provides table-level maintenance visibility and manual compaction queueing in the Cloudflare dashboard. These updates make it easier to understand when maintenance is eligible to run, inspect completed operations, and request maintenance without leaving the table view.

To view table maintenance details:

The updated dashboard includes:

• Maintenance tab — View compaction and snapshot expiration settings, schedules, and next eligibility alongside the table's Schema and Metadata tabs.
• Recent runs — Review a paginated audit log with job status, duration, and expandable details for manifest rewrites, compaction, and snapshot expiration. Expanded rows include operation metrics for each maintenance operation.
• Manual queueing — Select Queue maintenance to request compaction during normal scheduler polling. The dashboard checks permissions and explains when another maintenance job conflicts with the request or the daily accepted-request limit has been reached.
• Updated catalog layout — Find catalog metrics in the Metrics tab, use the renamed Explorer tab to browse data, and switch between table details using tabs instead of a scroll-to-section sidebar.
• Improved schema browser — For accounts with the schema browser enabled, select a namespace to open its tables in the right pane while also expanding the namespace tree. The tree can now be collapsed to provide more space for table details.

For more information about compaction and snapshot expiration, refer to Table maintenance.

You can now stream Workflow instance events via WorkflowInstance.subscribe() and the GET /subscribe API endpoint. Workers and HTTP clients can react to workflow and step events, including attempts, sleeps, waits, and rollbacks, without polling for instance status.

A subscription first streams the entire event history of the Workflow instance. After streaming past events, the subscription waits for new events as the instance runs. You can use filter to receive only specific event types or cursor to start a subscription at a specific event.

Use .subscribe() to update Workflow status in user-facing dashboards, send notifications when steps complete, or trigger follow-up work for specific events.

const instance = await env.MY_WORKFLOW.get("report-123");

using subscription = await instance.subscribe();

while (true) {
	const { value, done } = await subscription.next();
	if (done) {
		break;
	}

	console.log(value.type, value);
}

const instance = await env.MY_WORKFLOW.get("report-123");

using subscription = await instance.subscribe();

while (true) {
	const { value, done } = await subscription.next();
	if (done) {
		break;
	}

	console.log(value.type, value);
}

For event types, available fields, and subscription options, refer to Subscribe to events.

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.

This release introduces new threat detections to enhance protection against command injection attempts, Server-Side Request Forgery (SSRF) targeting cloud metadata, and information disclosure within version control history.

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.

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.

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.

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.

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.