Changelog

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

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

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.

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.

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

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.

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.

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.

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.

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

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

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

For setup steps, refer to Add routes.