Skip to content

Changelog

New updates and improvements at Cloudflare.

Network session analytics dashboard

The new Network session analytics dashboard is now available in Cloudflare One. This dashboard provides visibility into your network traffic patterns, helping you understand how traffic flows through your Cloudflare One infrastructure.

Cloudflare One Network Session Analytics

What you can do with Network session analytics

  • Analyze geographic distribution: View a world map showing where your network traffic originates, with a list of top locations by session count.
  • Monitor key metrics: Track session count, total bytes transferred, and unique users.
  • Identify connection issues: Analyze connection close reasons to troubleshoot network problems.
  • Review protocol usage: See which network protocols (TCP, UDP, ICMP) are most used.

Dashboard features

  • Summary metrics: Session count, bytes total, and unique users
  • Traffic by location: World map visualization and location list with top traffic sources
  • Top protocols: Breakdown of TCP, UDP, ICMP, and ICMPv6 traffic
  • Connection close reasons: Insights into why sessions terminated (client closed, origin closed, timeouts, errors)

How to access

  1. Log in to Cloudflare One ↗︎.
  2. Go to Zero Trust > Insights > Dashboards.
  3. Select Network session analytics.

For more information, refer to the Network session analytics documentation.

Homepage and sign-out for MCP server portals

MCP server portals display a homepage when users visit the portal domain in a browser.

MCP server portal homepage showing connection status and setup instructions

The homepage shows:

  • The portal name and organization branding
  • The MCP endpoint URL with a copy button
  • Per-client connection instructions for Claude Desktop, Workers AI Playground, OpenCode, Windsurf, and other MCP clients

Authenticated users see their email address and a Sign out button. Selecting Sign out revokes all portal-level OAuth grants, deletes upstream server OAuth states, and redirects through Cloudflare Access logout. A confirmation page shows a summary of the revoked sessions.

For more information, refer to MCP server portals.

Independent MFA for Access applications

Cloudflare Access now supports independent multi-factor authentication (MFA), allowing you to enforce MFA requirements without relying on your identity provider (IdP). With per-application and per-policy configuration, you can enforce stricter authentication methods like hardware security keys on sensitive applications without requiring them across your entire organization. This reduces the risk of MFA fatigue for your broader user population while adding additional security where it matters most.

This feature also addresses common gaps in IdP-based MFA, such as inconsistent MFA policies across different identity providers or the need for additional security layers beyond what the IdP provides.

Independent MFA supports the following authenticator types:

  • Authenticator application — Time-based one-time passwords (TOTP) using apps like Google Authenticator, Microsoft Authenticator, or Authy.
  • Security key — Hardware security keys such as YubiKeys.
  • Biometrics — Built-in device authenticators including Apple Touch ID, Apple Face ID, and Windows Hello.

Configuration levels

You can configure MFA requirements at three levels:

Level Description
Organization Enforce MFA by default for all applications in your account.
Application Require or turn off MFA for a specific application.
Policy Require or turn off MFA for users who match a specific policy.

Settings at lower levels (policy) override settings at higher levels (organization), giving you granular control over MFA enforcement.

User enrollment

Users enroll their authenticators through the App Launcher. To help with onboarding, administrators can share a direct enrollment link: <your-team-name>.cloudflareaccess.com/AddMfaDevice.

To get started with Independent MFA, refer to Independent MFA.

New, streamlined creation experience for Access Applications and Gateway Policies

The Cloudflare One dashboard now features redesigned builders for two core workflows: creating Gateway policies and configuring self-hosted Access applications.

Gateway rule builder

The Gateway rule builder now features a redesigned user experience, bringing it in line with the Access policy builder experience. Improvements include:

  • Streamlined UX with clearer states and improved user interactions
  • Wirefilter editing for viewing and editing Gateway rules directly from wirefilter expressions
  • Preview state to review the impact of your policy in a simple graphic
New Gateway rule builder

For more information, refer to Traffic policies.

Access application builder for self-hosted apps

The self-hosted Access application builder now offers a simplified creation workflow with fewer steps from setup to save. Improvements include:

  • New application selection experience that makes choosing the right application type before you begin easier.
  • Streamlined creation flow with fewer clicks to build and save an application
  • Inline policy creation for building Access policies directly within the application creation flow
  • Preview state to understand how your policies enforce user access before saving
New Access application builder

For more information, refer to self-hosted applications.

DLP account-level settings

Account-level DLP settings are now available in Cloudflare One. You can now configure advanced DLP settings at the account level, including OCR, AI context analysis, and payload masking. This provides consistent enforcement across all DLP profiles and simplifies configuration management.

Key changes:

  • Consistent enforcement: Settings configured at the account level apply to all DLP profiles
  • Simplified migration: Settings enabled on any profile are automatically migrated to account level
  • Deprecation notice: Profile-level advanced settings will be deprecated in a future release

Migration details:

During the migration period, if a setting is enabled on any profile, it will automatically be enabled at the account level. This means profiles that previously had a setting disabled may now have it enabled if another profile in the account had it enabled.

Settings are evaluated using OR logic - a setting is enabled if it is turned on at either the account level or the profile level. However, profile-level settings cannot be enabled when the account-level setting is off.

For more details, refer to the DLP settings documentation.

Introducing Cloudflare Mesh

Cloudflare Mesh is now available (blog post ↗︎). Mesh connects your services and devices with post-quantum encrypted networking, allowing you to route traffic privately between servers, laptops, and phones over TCP, UDP, and ICMP.

Cloudflare Mesh network map showing nodes and devices connected through Cloudflare

What Cloudflare Mesh does

  • Assigns a private Mesh IP to every enrolled device and node.
  • Enables any participant to reach any other participant by IP — including client-to-client, without deploying any infrastructure.
  • Supports CIDR routes for subnet routing through Mesh nodes.
  • Supports high availability with active-passive replicas for nodes with routes.
  • All traffic flows through Cloudflare, so Gateway network policies, device posture checks, and access rules apply to every connection.

What changed

  • WARP Connector is now Cloudflare Mesh. Existing WARP Connectors are now called mesh nodes. All existing deployments continue to work — no migration required.
  • Peer-to-peer connectivity is now called Mesh connectivity and is part of the Cloudflare Mesh documentation.
  • Mesh node limit increased from 10 to 50 per account.
  • New dashboard experience ↗︎ at Networking > Mesh with an interactive network map, node management, route configuration, diagnostics, and a setup wizard.

Get started

Refer to the Cloudflare Mesh documentation to set up your first Mesh network.

Detect Cloudflare API tokens with DLP

The Credentials and Secrets DLP profile now includes three new predefined entries for detecting Cloudflare API credentials:

Entry name Token prefix Detects
Cloudflare User API Key cfk_ User-scoped API keys
Cloudflare User API Token cfut_ User-scoped API tokens
Cloudflare Account Owned API Token cfat_ Account-scoped API tokens

These detections target the new Cloudflare API credential format, which uses a structured prefix and a CRC32 checksum suffix. The identifiable prefix makes it possible to detect leaked credentials with high confidence and low false positive rates — no surrounding context such as Authorization: Bearer headers is required.

Credentials generated before this format change will not be matched by these entries.

How to enable Cloudflare API token detections

  1. In the Cloudflare dashboard ↗︎, go to Zero Trust > DLP > DLP Profiles.
  2. Select the Credentials and Secrets profile.
  3. Turn on one or more of the new Cloudflare API token entries.
  4. Use the profile in a Gateway HTTP policy to log or block traffic containing these credentials.

Example policy:

Selector Operator Value Action
DLP Profile in Credentials and Secrets Block

You can also enable individual entries to scope detection to specific credential types — for example, enabling Account Owned API Token detection without enabling User API Key detection.

For more information, refer to predefined DLP profiles.

Configure how sensitive data appears in DLP payload logs

You can now configure how sensitive data matches are displayed in your DLP payload match logs — giving your incident response team the context they need to validate alerts without compromising your security posture.

To get started, go to the Cloudflare dashboard ↗︎, select Zero Trust > Data loss prevention > DLP settings and find the Payload log masking card.

Previously, all DLP payload logs used a single masking mode that obscured matched data entirely and hid the original character count, making it difficult to distinguish true positives from false positives. This update introduces three options:

  • Full Mask (default): Masks the match while preserving character count and visual formatting (for example, ***-**-**** for a Social Security Number). This is an improvement over the previous default, which did not preserve character count.
  • Partial Mask: Reveals 25% of the matched content while masking the remainder (for example, ***-**-6789).
  • Clear Text: Stores the full, unmasked violation for deep investigation (for example, 123-45-6789).

Important: The masking level you select is applied at detection time, before the payload is encrypted. This means the chosen format is what your team will see after decrypting the log with your private key — the existing encryption workflow is unchanged.

Applies to all enabled detections: When a masking level other than Full Mask is selected, it applies to all sensitive data matches found within a payload window — not just the match that triggered the policy. Any data matched by your enabled DLP detection entries will be masked at the selected level.

For more information, refer to DLP logging options.

Local Explorer for local resource data

Local Explorer is a browser-based interface and REST API for viewing and editing local resource data during development. It removes the need to write throwaway scripts or dig through .wrangler/state to understand what data your Worker has stored locally.

Local Explorer is available in Wrangler 4.82.1+ and the Cloudflare Vite plugin 1.32.0+. Start a local development session and press e in your terminal, or navigate to /cdn-cgi/local/explorer on your local dev server.

Supported resources

Local Explorer supports five resource types and works across multiple workers running locally:

  • KV — Browse keys, view values and metadata, create, update, and delete key-value pairs.
  • R2 — List objects, view metadata, upload files, and delete objects. Supports directory views and multi-select.
  • D1 — Browse tables and rows, run arbitrary SQL queries, and edit schemas in a full data studio.
  • Durable Objects (SQLite storage) — Browse individual object SQLite tables, run SQL queries, and edit schemas.
  • Workflows — List instances, view status and step history, trigger new runs, and pause, resume, restart, or terminate instances.

OpenAPI-powered REST API

Local Explorer exposes a REST API at /cdn-cgi/local/explorer/api that provides programmatic access to the same operations available in the browser. The root endpoint returns an OpenAPI specification ↗︎ describing all available endpoints, parameters, and response formats.

curl http://localhost:8787/cdn-cgi/local/explorer/api

Point an AI coding agent at /cdn-cgi/local/explorer/api and it can discover and interact with your local resources without manual setup. This enables iterative development loops where an agent can populate test data in KV or D1, inspect Durable Object state, trigger Workflow runs, or upload files to R2.

For more details, refer to the Local Explorer documentation.

Canvas Remoting optimizes performance for productivity applications

Remote Browser Isolation now supports Canvas Remoting, improving performance for HTML5 Canvas applications by sending vector draw commands instead of rasterized bitmaps.

Key improvements

  • 10x bandwidth reduction: Microsoft Word and other Office apps use 90% less bandwidth
  • Smooth performance: Google Sheets maintains consistent 30fps rendering
  • Responsive terminals: Web-based development environments and AI notebooks work in real-time
  • Zero configuration: Enabled by default for all Browser Isolation customers

How it works

Instead of sending rasterized bitmaps for every Canvas update, Browser Isolation now:

  1. Captures Canvas draw commands at the source
  2. Converts them to lightweight vector instructions
  3. Renders Canvas content on the client

This reduces bandwidth from hundreds of kilobytes per second to tens of kilobytes per second.

Managing Canvas Remoting

To temporarily disable for troubleshooting:

  • Right-click the isolated webpage background
  • Select Disable Canvas Remoting
  • Re-enable the same way by selecting Enable Canvas Remoting

Limitations

Currently supports 2D Canvas contexts only. WebGL and 3D graphics applications continue using bitmap rendering. For more information, refer to Canvas Remoting.

Send CASB posture finding instances with webhooks

You can now use CASB webhooks in Cloudflare One to send posture finding instances to external systems such as chat platforms, ticketing systems, SIEMs, SOAR tools, and custom automation services.

This gives security teams a simple way to route CASB posture findings into the tools and workflows they already use for triage and response.

To get started, go to Integrations > Webhooks in the Cloudflare One dashboard to create a webhook destination. After you configure a webhook, open a posture finding instance and select Send webhook to send it.

Key capabilities

  • Flexible authentication — Configure destinations using None, Basic Auth, Bearer Auth, Static Headers, or HMAC-Signing.
  • Built-in testing — Use Test delivery to send a test request before sending a live finding instance.
  • Posture finding workflows — Send posture finding instances directly from the finding details workflow in Cloud & SaaS findings.
  • HTTPS destinations — Configure webhook destinations with public https:// URLs.

Learn more

CASB webhooks are now available in Cloudflare One.

Relaxed simultaneous connection limiting for Workers

The simultaneous open connections limit has been relaxed. Previously, each Worker invocation was limited to six open connections at a time for the entire lifetime of each connection, including while reading the response body. Now, a connection is freed as soon as response headers arrive, so the six-connection limit only constrains how many connections can be in the initial "waiting for headers" phase simultaneously.

Before: New connections are blocked until an earlier connection fully completes

A 7th fetch is queued until an earlier connection fully completes, including reading its entire response body

After: New connections can start as soon as response headers arrive

A 7th fetch starts as soon as any earlier connection receives its response headers

This means Workers can now have many more connections open at the same time without queueing, as long as no more than six are waiting for their initial response. This eliminates the Response closed due to connection limit exception that could previously occur when the runtime canceled stalled connections to prevent deadlocks.

Previously, the runtime used a deadlock avoidance algorithm that watched each open connection for I/O activity. If all six connections appeared idle — even momentarily — the runtime would cancel the least-recently-used connection to make room for new requests. In practice, this heuristic was fragile. For example, when a response used Content-Encoding: gzip, the runtime's internal decompression created brief gaps between read and write operations. During these gaps, the connection appeared stalled despite being actively read by the Worker. If multiple connections hit these gaps at the same time, the runtime could spuriously cancel a connection that was working correctly. By only counting connections during the waiting-for-headers phase — where the runtime is fully in control and there is no ambiguity about whether the connection is active — this class of bug is eliminated entirely.

Before: Connections could be canceled during brief internal pauses

A connection with gaps from gzip decompression appears idle and is canceled by the runtime

After: Connections complete normally regardless of internal pauses

The same connection completes normally because the body phase is no longer counted against the limit

User risk scoring for high risk browsing activity

Cloudflare One's User Risk Scoring now incorporates direct signals from Gateway DNS traffic patterns. This update allows security teams to automatically elevate a user's risk score when they visit high-risk or malicious domains, providing a more holistic view of internal threats.

Why this matters

Browsing activity is a primary indicator of potential compromise. By tying Gateway DNS logs to specific users, administrators can now flag individuals interacting with:

  • Security threats: Domains associated with malware, phishing, or command-and-control (C2) centers.
  • High-risk content: Categories such as questionable content or violence that may violate corporate compliance.

Even if a Gateway policy is set to Block the traffic, the interaction is still captured as a "hit" to ensure the user's risk profile reflects the attempted activity.

New risk behaviors

Two new behaviors are now available in the dashboard:

  • Suspicious Security Domain Visited: Triggers when a user visits a domain in the security threats or security risk categories.
  • High risk domain visited: Triggers when a user visits domains categorized as questionable content, violence, or CIPA.

To learn more and get started, refer to the User Risk Scoring documentation.

Cloudflare One Client for Windows (version 2026.3.851.0)

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

This release contains minor fixes and improvements.

The next stable release for Windows will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

  • Fixed an issue causing Windows client tunnel interface initialization failure which prevented clients from establishing a tunnel for connection.
  • Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
  • Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
  • Added monitoring for tunnel statistics collection timeouts.
  • Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
  • Fixed packet capture failing on tunnel interface when the tunnel interface is renamed by SCCM VPN boundary support.
  • Fixed unnecessary registration deletion caused by RDP connections in multi-user mode.
  • Fixed increased tunnel interface start-up time due to a race between duplicate address detection (DAD) and disabling NetBT.
  • Fixed tunnel failing to connect when the system DNS search list contains unexpected characters.
  • Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
  • Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
  • Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
  • Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.
  • Fixed an issue where degraded Windows Management Instrumentation (WMI) state could put the client in a failed connection state loop during initialization.

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 version KB5062553 or higher for resolution. This warning will be omitted from future release notes. This Windows update was released in July 2025.

  • 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. This warning will be omitted from future release notes. This Microsoft Security Intelligence update was released in May 2025.

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

    • The client 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 the client is connected.

    To work around this issue, reconnect the client by selecting Disconnect and then Connect in the client user interface.

User Submission Triage Status Tracking

Cloudflare Email security now supports Triage Status Tracking for User Submissions. This enhancement gives SOC teams a streamlined way to track, manage, and prioritize user-submitted emails directly within the Cloudflare One dashboard.

  • The User Submissions table now includes a Status column with three states: Unreviewed (new submissions awaiting triage), Reviewed (submissions assessed by the SOC team), and Escalated (submissions escalated to team submissions for further investigation). Analysts can quickly update statuses and filter the table to focus on what needs attention.
  • SOC teams can now organize their triage workflows, avoid duplicate reviews, and make sure critical threats get escalated for deeper investigation—bringing order to the chaos of high-volume submission management.

Triage Status Tracking is automatically available for all Email security customers using the user submissions feature. No additional configuration is required; customers just need to make sure user submissions are being sent to their user submission aliases.

This applies to all Email security packages:

  • Advantage
  • Enterprise
  • Enterprise + PhishGuard

Link aggregation (LACP) support for Cloudflare One Appliance

Cloudflare One Appliance now supports Link Aggregation Control Protocol (LACP), allowing you to bundle up to six physical LAN ports into a single logical interface. Link aggregation increases available bandwidth and eliminates single points of failure on the LAN side of the appliance.

This feature is available in beta on physical appliance hardware with the latest OS. No entitlement is required.

To configure a Link Aggregation Group, refer to Configure link aggregation groups.

WebSockets now automatically reply to Close frames

The Workers runtime now automatically sends a reciprocal Close frame when it receives a Close frame from the peer. The readyState transitions to CLOSED before the close event fires. This matches the WebSocket specification ↗︎ and standard browser behavior.

This change is enabled by default for Workers using compatibility dates on or after 2026-04-07 (via the web_socket_auto_reply_to_close compatibility flag). Existing code that manually calls close() inside the close event handler will continue to work — the call is silently ignored when the WebSocket is already closed.

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
	// readyState is already CLOSED — no need to call server.close().
	console.log(server.readyState); // WebSocket.CLOSED
	console.log(event.code); // 1000
	console.log(event.wasClean); // true
});

Half-open mode for WebSocket proxying

The automatic close behavior can interfere with WebSocket proxying, where a Worker sits between a client and a backend and needs to coordinate the close on both sides independently. To support this use case, pass { allowHalfOpen: true } to accept():

const [client, server] = Object.values(new WebSocketPair());

server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
	// readyState is still CLOSING here, giving you time
	// to coordinate the close on the other side.
	console.log(server.readyState); // WebSocket.CLOSING

	// Manually close when ready.
	server.close(event.code, "done");
});

For more information, refer to WebSockets Close behavior.

DANE Support for MX Deployments

Cloudflare Email Security now supports DANE (DNS-based Authentication of Named Entities) for MX deployments. This enhancement strengthens email transport security by enabling DNSSEC-backed certificate verification for our regional MX records.

  • Regional MX hostnames now publish DANE TLSA records backed by DNSSEC, enabling DANE-capable SMTP senders to cryptographically validate certificate identities before establishing TLS connections—moving beyond opportunistic encryption to verified encrypted delivery.
  • DANE support is automatically available for all customers using regional MX deployments. No additional configuration is required; DANE-capable mail infrastructure will automatically validate MX certificates using the published records.

This applies to all Email Security packages:

  • Advantage
  • Enterprise
  • Enterprise + PhishGuard

Organizations is now in public beta for enterprises

We're announcing the public beta of Organizations for enterprise customers, a new top-level Cloudflare container that lets Cloudflare customers manage multiple accounts, members, analytics, and shared policies from one centralized location.

What's New

Organizations [BETA]: Organizations are a new top-level container for centrally managing multiple accounts. Each Organization supports up to 500 accounts and 5000 zones, giving larger teams a single place to administer resources at scale.

Self-serve onboarding: Enterprise customers can create an Organization in the dashboard and assign accounts where they are already Super Administrators.

Centralized Account Management: At launch, every Organization member has the Organization Super Admin role. Organization Super Admins can invite other users and manage any child account under the Organization implicitly. Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management. Implicit access: Members of an Organization automatically receive Super Administrator permissions across child accounts, removing the need for explicit membership on each account. Additional Org-level roles will be available over the course of the year.

Unified analytics: View, filter, and download aggregate HTTP analytics across all Organization child accounts from a single dashboard for centralized visibility into traffic patterns and security events.

Terraform provider support: Manage Organizations with infrastructure as code from day one. Provision organizations, assign accounts, and configure settings programmatically with the Cloudflare Terraform provider ↗︎.

Shared policies: Share WAF or Gateway policies across multiple accounts within your Organization to simplify centralized policy management.

For more info:

Cloudflare One Client for macOS (version 2026.3.846.0)

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

This release contains minor fixes and improvements.

The next stable release for macOS will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

  • Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
  • Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
  • Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
  • Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
  • Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
  • Added monitoring for tunnel statistics collection timeouts.
  • Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
  • Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

Cloudflare One Client for Linux (version 2026.3.846.0)

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

This release contains minor fixes and improvements.

The next stable release for Linux will introduce the new Cloudflare One Client UI, providing a cleaner and more intuitive design as well as easier access to common actions and information.

Changes and improvements

  • Empty MDM files are now rejected instead of being incorrectly accepted as a single MDM config.
  • Fixed an issue in local proxy mode where the client could become unresponsive due to upstream connection timeouts.
  • Fixed an issue where the emergency disconnect status of a prior organization persisted after a switch to a different organization.
  • Consumer-only CLI commands are now clearly distinguished from Zero Trust commands.
  • Added detailed QUIC connection metrics to diagnostic logs for better troubleshooting.
  • Added monitoring for tunnel statistics collection timeouts.
  • Switched tunnel congestion control algorithm for local proxy mode to Cubic for improved reliability across platforms.
  • Fixed initiating managed network detections checks when no network is available, which caused device profile flapping.

Session management for MCP server portals

MCP server portals support in-session management of upstream MCP server connections. Users can return to the server selection page at any time to enable or disable servers, reauthenticate, or change which data a server has access to — all without leaving their MCP client.

To return to the server selection page, ask your AI agent with a prompt like "take me back to the server selection page." The portal responds with an authorization URL via MCP elicitation ↗︎ that you open in your browser:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

From the server selection page you can:

  • Enable or disable servers — Toggle individual upstream MCP servers on or off. Disabling a server removes its tools from the active session, which reduces context window usage.
  • Log out and reauthenticate — Log out of a server and log back in to change which data the server has access to, or to reauthenticate with different permissions.

Users can also enable or disable a server inline by asking their AI agent directly, for example "enable the wiki server" or "disable my Jira server."

The portal also automatically prompts connected users to authorize new servers when an admin adds them to the portal. This requires the use of managed OAuth.

For more information, refer to Manage portal sessions.

Logs UI refresh

Access authentication logs and Gateway activity logs (DNS, Network, and HTTP) now feature a refreshed user interface that gives you more flexibility when viewing and analyzing your logs.

Screenshot of the new logs UI showing DNS query logs with customizable columns and filtering options

The updated UI includes:

  • Filter by field - Select any field value to add it as a filter and narrow down your results.
  • Customizable fields - Choose which fields to display in the log table. Querying for fewer fields improves log loading performance.
  • View details - Select a timestamp to view the full details of a log entry.
  • Switch to classic view - Return to the previous log viewer interface if needed.

For more information, refer to Access authentication logs and Gateway activity logs.

Deploy Hooks are now available for Workers Builds

Workers Builds now supports Deploy Hooks — trigger builds from your headless CMS, a Cron Trigger, a Slack bot, or any system that can send an HTTP request.

Each Deploy Hook is a unique URL tied to a specific branch. Send it a POST and your Worker builds and deploys.

curl -X POST "https://api.cloudflare.com/client/v4/workers/builds/deploy_hooks/<DEPLOY_HOOK_ID>"

To create one, go to Workers & Pages > your Worker > Settings > Builds > Deploy Hooks.

Since a Deploy Hook is a URL, you can also call it from another Worker. For example, a Worker with a Cron Trigger can rebuild your project on a schedule:

export default {
	async scheduled(event, env, ctx) {
		ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
	},
};
export default {
  async scheduled(event: ScheduledEvent, env: Env, ctx: ExecutionContext): Promise<void> {
    ctx.waitUntil(fetch(env.DEPLOY_HOOK_URL, { method: "POST" }));
  },
} satisfies ExportedHandler<Env>;

You can also use Deploy Hooks to rebuild when your CMS publishes new content or deploy from a Slack slash command.

Built-in optimizations

  • Automatic deduplication: If a Deploy Hook fires multiple times before the first build starts running, redundant builds are automatically skipped. This keeps your build queue clean when webhooks retry or CMS events arrive in bursts.
  • Last triggered: The dashboard shows when each hook was last triggered.
  • Build source: Your Worker's build history shows which Deploy Hook started each build by name.

Deploy Hooks are rate limited to 10 builds per minute per Worker and 100 builds per minute per account. For all limits, see Limits & pricing.

To get started, read the Deploy Hooks documentation.