Changelog

You can now deploy any existing project to Cloudflare Workers — even without a Wrangler configuration file — and wrangler deploy will just work.

Starting with Wrangler 4.68.0, running wrangler deploy automatically configures your project by detecting your framework, installing required adapters, and deploying it to Cloudflare Workers.

npx wrangler deploy

When you run wrangler deploy in a project without a configuration file, Wrangler:

1. Detects your framework from package.json
2. Prompts you to confirm the detected settings
3. Installs any required adapters
4. Generates a wrangler.jsonc configuration file
5. Deploys your project to Cloudflare Workers

You can also use wrangler setup to configure without deploying, or pass --yes to skip prompts.

When you connect a repository through the Workers dashboard ↗︎, a pull request is generated for you with all necessary files, and a preview deployment to check before merging.

In December 2025, we introduced automatic configuration as an experimental feature. It is now generally available and the default behavior.

If you have questions or run into issues, join the GitHub discussion ↗︎.

A new GA release for the Windows WARP client is now available on the stable releases downloads page.

This release contains minor fixes, improvements, and new features.

Changes and improvements

• Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
• Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for the Windows client certificate posture check to ensure logged results are from checks that run once users log in.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
• Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
• Fixed an issue causing DNS requests to fail with clients in Traffic and DNS mode.
• Improved service shutdown behavior in cases where the daemon is unresponsive.

Known issues

• For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.

• Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.

• DNS resolution may be broken when the following conditions are all true:

  • WARP is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
  • A custom DNS server address is configured on the primary network adapter.
  • The custom DNS server address on the primary network adapter is changed while WARP is connected.

  To work around this issue, reconnect the WARP client by toggling off and back on.

A new GA release for the macOS WARP client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
• Fixed an issue with DNS server configuration failures that caused tunnel connection delays.
• Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
• Fixed an issue causing DNS requests to fail with clients in Traffic and DNS mode.

A new GA release for the Linux WARP client is now available on the stable releases downloads page.

This release contains minor fixes and improvements.

WARP client version 2025.8.779.0 introduced an updated public key for Linux packages. The public key must be updated if it was installed before September 12, 2025 to ensure the repository remains functional after December 4, 2025. Instructions to make this update are available at pkg.cloudflareclient.com.

Changes and improvements

• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.
• Fixed an issue where misconfigured DEX HTTP tests prevented new registrations.
• Fixed issues causing DNS requests to fail with clients in Traffic and DNS mode or DNS only mode.

You can now disable a live input to reject incoming RTMPS and SRT connections. When a live input is disabled, any broadcast attempts will fail to connect.

This gives you more control over your live inputs:

• Temporarily pause an input without deleting it
• Programmatically end creator broadcasts
• Prevent new broadcasts from starting on a specific input

To disable a live input via the API, set the enabled property to false:

curl --request PUT \
https://api.cloudflare.com/client/v4/accounts/{account_id}/stream/live_inputs/{input_id} \
--header "Authorization: Bearer <API_TOKEN>" \
--data '{"enabled": false}'

You can also disable or enable a live input from the Live inputs list page or the live input detail page in the Dashboard.

All existing live inputs remain enabled by default. For more information, refer to Start a live stream.

You can now easily understand your SaaS security posture findings and why they were detected with Cloudy Summaries in CASB. This feature integrates Cloudflare's Cloudy AI directly into your CASB Posture Findings to automatically generate clear, plain-language summaries of complex security misconfigurations, third-party app risks, and data exposures.

This allows security teams and IT administrators to drastically reduce triage time by immediately understanding the context, potential impact, and necessary remediation steps for any given finding—without needing to be an expert in every connected SaaS application.

To view a summary, simply navigate to your Posture Findings in the Cloudflare One dashboard (under Cloud and SaaS findings) and open the finding details of a specific instance of a Finding.

Cloudy Summaries are supported on all available integrations, including Microsoft 365, Google Workspace, Salesforce, GitHub, AWS, Slack, and Dropbox. See the full list of supported integrations here.

• Contextual explanations — Quickly understand the specifics of a finding with plain-language summaries detailing exactly what was detected, from publicly shared sensitive files to risky third-party app scopes.
• Clear risk assessment — Instantly grasp the potential security impact of the finding, such as data breach risks, unauthorized account access, or email spoofing vulnerabilities.
• Actionable guidance — Get clear recommendations and next steps on how to effectively remediate the issue and secure your environment.
• Built-in feedback — Help improve future AI summarization accuracy by submitting feedback directly using the thumbs-up and thumbs-down buttons.

• Learn more about managing CASB Posture Findings in Cloudflare.

Cloudy Summaries in CASB are available to all Cloudflare CASB users today.

Cloudflare Tunnel is now available in the main Cloudflare Dashboard at Networking > Tunnels ↗︎, bringing first-class Tunnel management to developers using Tunnel for securing origin servers.

This new experience provides everything you need to manage Tunnels for public applications, including:

• Full Tunnel lifecycle management: Create, configure, delete, and monitor all your Tunnels in one place.
• Native integrations: View Tunnels by name when configuring DNS records and Workers VPC — no more copy-pasting UUIDs.
• Real-time visibility: Monitor replicas and Tunnel health status directly in the dashboard.
• Routing map: Manage all ingress routes for your Tunnel, including public applications, private hostnames, private CIDRs, and Workers VPC services, from a single interactive interface.

Core Dashboard: Navigate to Networking > Tunnels ↗︎ to manage Tunnels for:

• Securing origin servers and public applications with CDN, WAF, Load Balancing, and DDoS protection
• Connecting Workers to private services via Workers VPC

Cloudflare One Dashboard: Navigate to Zero Trust > Networks > Connectors ↗︎ to manage Tunnels for:

• Securing your public applications with Zero Trust access policies
• Connecting users to private applications
• Building a private mesh network

Both dashboards provide complete Tunnel management capabilities — choose based on your primary workflow.

New to Tunnel? Learn how to get started with Cloudflare Tunnel or explore advanced use cases like securing SSH servers or running Tunnels in Kubernetes.

Digital Experience Monitoring (DEX) provides visibility into WARP device connectivity and performance to any internal or external application.

Now, all DEX logs are fully compatible with Cloudflare's Customer Metadata Boundary (CMB) setting for the 'EU' (European Union), which ensures that DEX logs will not be stored outside the 'EU' when the option is configured.

If a Cloudflare One customer using DEX enables CMB 'EU', they will not see any DEX data in the Cloudflare One dashboard. Customers can ingest DEX data via LogPush, and build their own analytics and dashboards.

If a customer enables CMB in their account, they will see the following message in the Digital Experience dashboard: "DEX data is unavailable because Customer Metadata Boundary configuration is on. Use Cloudflare LogPush to export DEX datasets."

A new Allow clientless access setting makes it easier to connect users without a device client to internal applications, without using public DNS.

Previously, to provide clientless access to a private hostname or IP without a published application, you had to create a separate bookmark application pointing to a prefixed Clientless Web Isolation URL (for example, https://<your-teamname>.cloudflareaccess.com/browser/https://10.0.0.1/). This bookmark was visible to all users in the App Launcher, regardless of whether they had access to the underlying application.

Now, you can manage clientless access directly within your private self-hosted application. When Allow clientless access is turned on, users who pass your Access application policies will see a tile in their App Launcher pointing to the prefixed URL. Users must have remote browser permissions to open the link.

You can now assign Access policies to bookmark applications. This lets you control which users see a bookmark in the App Launcher based on identity, device posture, and other policy rules.

Previously, bookmark applications were visible to all users in your organization. With policy support, you can now:

• Tailor the App Launcher to each user — Users only see the applications they have access to, reducing clutter and preventing accidental clicks on irrelevant resources.
• Restrict visibility of sensitive bookmarks — Limit who can view bookmarks to internal tools or partner resources based on group membership, identity provider, or device posture.

Bookmarks support all Access policy configurations except purpose justification, temporary authentication, and application isolation. If no policy is assigned, the bookmark remains visible to all users (maintaining backwards compatibility).

For more information, refer to Add bookmarks.

We are updating naming related to some of our Networking products to better clarify their place in the Zero Trust and Secure Access Service Edge (SASE) journey.

We are retiring some older brand names in favor of names that describe exactly what the products do within your network. We are doing this to help customers build better, clearer mental models for comprehensive SASE architecture delivered on Cloudflare.

• Magic WAN → Cloudflare WAN
• Magic WAN IPsec → Cloudflare IPsec
• Magic WAN GRE → Cloudflare GRE
• Magic WAN Connector → Cloudflare One Appliance
• Magic Firewall → Cloudflare Network Firewall
• Magic Network Monitoring → Network Flow
• Magic Cloud Networking → Cloudflare One Multi-cloud Networking

No action is required by you — all functionality, existing configurations, and billing will remain exactly the same.

For more information, visit the Cloudflare One documentation.

Cloudflare has deprecated the Workers Quick Editor dev tools inspector and replaced it with a lightweight log viewer.

This aligns our logging with wrangler tail and gives us the opportunity to focus our efforts on bringing benefits from the work we have invested in observability, which would not be possible otherwise.

We have made improvements to this logging viewer based on your feedback such that you can log object and array types, and easily clear the list of logs. This does not include class instances. Limitations are documented in the Workers Playground docs.

If you do need to develop your Worker with a remote inspector, you can still do this using Wrangler locally. Cloning a project from your quick editor to your computer for local development can be done with the wrangler init --from-dash command. For more information, refer to Wrangler commands.

A new Workers Best Practices guide provides opinionated recommendations for building fast, reliable, observable, and secure Workers. The guide draws on production patterns, Cloudflare internal usage, and best practices observed from developers building on Workers.

Key guidance includes:

• Keep your compatibility date current and enable nodejs_compat — Ensure you have access to the latest runtime features and Node.js built-in modules.

{
	"name": "my-worker",
	"main": "src/index.ts",
	// Set this to today's date
	"compatibility_date": "2026-10-11",
	"compatibility_flags": ["nodejs_compat"],
}

name = "my-worker"
main = "src/index.ts"
# Set this to today's date
compatibility_date = "2026-10-11"
compatibility_flags = [ "nodejs_compat" ]

• Generate binding types with wrangler types — Never hand-write your Env interface. Let Wrangler generate it from your actual configuration to catch mismatches at compile time.
• Stream request and response bodies — Avoid buffering large payloads in memory. Use TransformStream and pipeTo to stay within the 128 MB memory limit and improve time-to-first-byte.
• Use bindings, not REST APIs — Bindings to KV, R2, D1, Queues, and other Cloudflare services are direct, in-process references with no network hop and no authentication overhead.
• Use Queues and Workflows for background work — Move long-running or retriable tasks out of the critical request path. Use Queues for simple fan-out and buffering, and Workflows for multi-step durable processes.
• Enable Workers Logs and Traces — Configure observability before deploying to production so you have data when you need to debug.
• Avoid global mutable state — Workers reuse isolates across requests. Storing request-scoped data in module-level variables causes cross-request data leaks.
• Always await or waitUntil your Promises — Floating promises cause silent bugs and dropped work.
• Use Web Crypto for secure token generation — Never use Math.random() for security-sensitive operations.

To learn more, refer to Workers Best Practices.

Fine-grained permissions for Access policies and Access service tokens are available. These new resource-scoped roles expand the existing RBAC model, enabling administrators to grant permissions scoped to individual resources.

• Cloudflare Access policy admin: Can edit a specific Access policy in an account.
• Cloudflare Access service token admin: Can edit a specific Access service token in an account.

These roles complement the existing resource-scoped roles for Access applications, identity providers, and infrastructure targets.

For more information:

• Resource-scoped roles
• Role scopes

Cloudflare WAN now displays your Anycast IP addresses directly in the dashboard when you configure IPsec or GRE tunnels.

Previously, customers received their Anycast IPs during onboarding or had to retrieve them with an API call. The dashboard now pre-loads these addresses, reducing setup friction and preventing configuration errors.

No action is required. All Cloudflare WAN customers can see their Anycast IPs in the tunnel configuration form automatically.

For more information, refer to Configure tunnel endpoints.

Cloudflare One Appliance version 2026.2.0 adds post-quantum encryption support using hybrid ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism).

The appliance now uses TLS 1.3 with hybrid ML-KEM for its connection to the Cloudflare edge. During the TLS handshake, the appliance and the edge share a symmetric secret over the TLS connection and inject it into the ESP layer of IPsec. This protects IPsec data plane traffic against harvest-now, decrypt-later attacks.

This upgrade deploys automatically to all appliances during their configured interrupt windows with no manual action required.

For more information, refer to Cloudflare One Appliance.

Workers no longer have a limit of 1000 subrequests per invocation, allowing you to make more fetch() calls or requests to Cloudflare services on every incoming request. This is especially important for long-running Workers requests, such as open websockets on Durable Objects or long-running Workflows, as these could often exceed this limit and error.

By default, Workers on paid plans are now limited to 10,000 subrequests per invocation, but this limit can be increased up to 10 million by setting the new subrequests limit in your Wrangler configuration file.

{
	"limits": {
		"subrequests": 50000,
	},
}

[limits]
subrequests = 50_000

Workers on the free plan remain limited to 50 external subrequests and 1000 subrequests to Cloudflare services per invocation.

To protect against runaway code or unexpected costs, you can also set a lower limit for both subrequests and CPU usage.

{
	"limits": {
		"subrequests": 10,
		"cpu_ms": 1000,
	},
}

[limits]
subrequests = 10
cpu_ms = 1_000

For more information, refer to the Wrangler configuration documentation for limits and subrequest limits.

The Cloudflare Vite plugin now integrates seamlessly @vitejs/plugin-rsc ↗︎, the official Vite plugin for React Server Components ↗︎.

A childEnvironments option has been added to the plugin config to enable using multiple environments within a single Worker. The parent environment can then import modules from a child environment in order to access a separate module graph. For a typical RSC use case, the plugin might be configured as in the following example:

export default defineConfig({
	plugins: [
		cloudflare({
			viteEnvironment: {
				name: "rsc",
				childEnvironments: ["ssr"],
			},
		}),
	],
});

@vitejs/plugin-rsc provides the lower level functionality that frameworks, such as React Router ↗︎, build upon. The GitHub repository includes a basic Cloudflare example ↗︎.

The Workers Observability dashboard ↗︎ has some major updates to make it easier to debug your application's issues and share findings with your team.

You can now:

• Create visualizations — Build charts from your Worker data directly in a Worker's Observability tab
• Export data as JSON or CSV — Download logs and traces for offline analysis or to share with teammates
• Share events and traces — Generate direct URLs to specific events, invocations, and traces that open standalone pages with full context
• Customize table columns — Improved field picker to add, remove, and reorder columns in the events table
• Expandable event details — Expand events inline to view full details without leaving the table
• Keyboard shortcuts — Navigate the dashboard with hotkey support

These updates are now live in the Cloudflare dashboard, both in a Worker's Observability tab and in the account-level Observability dashboard for a unified experience. To get started, go to Workers & Pages > select your Worker > Observability.

We have updated the Monitoring page to provide a more streamlined and insightful experience for administrators, improving both data visualization and dashboard accessibility.

• Enhanced Visual Layout: Optimized contrast and the introduction of stacked bar charts for clearer data visualization and trend analysis.
• Improved Accessibility & Usability:
  • Widget Search: Added search functionality to multiple widgets, including Policies, Submitters, and Impersonation.
  • Actionable UI: All available actions are now accessible via dedicated buttons.
  • State Indicators: Improved UI states to clearly communicate loading, empty datasets, and error conditions.
• Granular Data Breakdowns: New views for dispositions by month, malicious email details, link actions, and impersonations.

This applies to all Email Security packages:

• Advantage
• Enterprise
• Enterprise + PhishGuard

Magic WAN and Magic Transit customers can use the Cloudflare dashboard to configure and manage BGP peering between their networks and their Magic routing table when using IPsec and GRE tunnel on-ramps (beta).

Using BGP peering allows customers to:

• Automate the process of adding or removing networks and subnets.
• Take advantage of failure detection and session recovery features.

With this functionality, customers can:

• Establish an eBGP session between their devices and the Magic WAN / Magic Transit service when connected via IPsec and GRE tunnel on-ramps.
• Secure the session by MD5 authentication to prevent misconfigurations.
• Exchange routes dynamically between their devices and their Magic routing table.

For configuration details, refer to:

• Configure BGP routes for Magic WAN
• Configure BGP routes for Magic Transit

A new Beta release for the Windows WARP client is now available on the beta releases downloads page.

This release contains minor fixes, improvements, and new features.

Changes and improvements

• Improvements to multi-user mode. Fixed an issue where when switching from a pre-login registration to a user registration, Mobile Device Management (MDM) configuration association could be lost.
• Added a new feature to manage NetBIOS over TCP/IP functionality on the Windows client. NetBIOS over TCP/IP on the Windows client is now disabled by default and can be enabled in device profile settings.
• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for the Windows client certificate posture check to ensure logged results are from checks that run once users log in.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

Known issues

• For Windows 11 24H2 users, Microsoft has confirmed a regression that may lead to performance issues like mouse lag, audio cracking, or other slowdowns. Cloudflare recommends users experiencing these issues upgrade to a minimum Windows 11 24H2 KB5062553 or higher for resolution.

• Devices with KB5055523 installed may receive a warning about Win32/ClickFix.ABA being present in the installer. To resolve this false positive, update Microsoft Security Intelligence to version 1.429.19.0 or later.

• DNS resolution may be broken when the following conditions are all true:

  • WARP is in Secure Web Gateway without DNS filtering (tunnel-only) mode.
  • A custom DNS server address is configured on the primary network adapter.
  • The custom DNS server address on the primary network adapter is changed while WARP is connected.

  To work around this issue, reconnect the WARP client by toggling off and back on.

A new Beta release for the macOS WARP client is now available on the beta releases downloads page.

This release contains minor fixes and improvements.

Changes and improvements

• Fixed an issue causing failure of the local network exclusion feature when configured with a timeout of 0.
• Improvement for more accurate reporting of device colocation information in the Cloudflare One dashboard.

Cloudflare source IPs are the IP addresses used by Cloudflare services (such as Load Balancing, Gateway, and Browser Isolation) when sending traffic to your private networks.

For customers using legacy mode routing, traffic to private networks is sourced from public Cloudflare IPs, which may cause IP conflicts. For customers using Unified Routing mode (beta), traffic to private networks is sourced from dedicated, non-Internet-routable private IPv4 range to ensure:

• Symmetric routing over private network connections
• Proper firewall state preservation
• Private traffic stays on secure paths

Key details:

• IPv4: Sourced from 100.64.0.0/12 by default, configurable to any /12 CIDR
• IPv6: Sourced from 2606:4700:cf1:5000::/64 (not configurable)
• Affected connectors: GRE, IPsec, CNI, WARP Connector, and WARP Client (Cloudflare Tunnel is not affected)

Configuring Cloudflare source IPs requires Unified Routing (beta) and the Cloudflare One Networks Write permission.

For configuration details, refer to Configure Cloudflare source IPs.

You can now require Cloudflare Access protection for all hostnames in your account. When enabled, traffic to any hostname that does not have a matching Access application is automatically blocked.

This deny-by-default approach prevents accidental exposure of internal resources to the public Internet. If a developer deploys a new application or creates a DNS record without configuring an Access application, the traffic is blocked rather than exposed.

• Blocked by default: Traffic to all hostnames in the account is blocked unless an Access application exists for that hostname.
• Explicit access required: To allow traffic, create an Access application with an Allow or Bypass policy.
• Hostname exemptions: You can exempt specific hostnames from this requirement.

To turn on this feature, refer to Require Access protection.