Core Platform Release Notes

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

Note

Organizations is in Public Beta. You must have an Enterprise account to create an organization, but once created, you can add accounts of any plan type where you are a Super Administrator.

For more info:

Get started with Organizations

Set up your Organization

Review limitations

Original source Report a problem

Two new fields are now available in rule expressions that surface Layer 4 transport telemetry from the client connection. Together with the existing cf.timings.client_tcp_rtt_msec field, these fields give you a complete picture of connection quality for both TCP and QUIC traffic — enabling transport-aware rules without requiring any client-side changes.

Previously, QUIC RTT and delivery rate data was only available via the Server-Timing: cfL4 response header. These new fields make the same data available directly in rule expressions, so you can use them in Transform Rules, WAF Custom Rules, and other phases that support dynamic fields.

New fields

Field Type Description cf.timings.client_quic_rtt_msec Integer The smoothed QUIC round-trip time (RTT) between Cloudflare and the client in milliseconds. Only populated for QUIC (HTTP/3) connections. Returns 0 for TCP connections. cf.edge.l4.delivery_rate Integer The most recent data delivery rate estimate for the client connection, in bytes per second. Returns 0 when L4 statistics are not available for the request.

Example: Route slow connections to a lightweight origin

Use a request header transform rule to tag requests from high-latency connections, so your origin can serve a lighter page variant:

Rule expression

cf.timings.client_tcp_rtt_msec > 200 or cf.timings.client_quic_rtt_msec > 200

Header modifications

Operation Header name Value Set X-High-Latency true

Example: Match low-bandwidth connections

cf.edge.l4.delivery_rate > 0 and cf.edge.l4.delivery_rate < 100000

For more information, refer to Request Header Transform Rules and the fields reference.

Original source Report a problem

Logpush now supports higher-precision timestamp formats for log output. You can configure jobs to output timestamps at millisecond or nanosecond precision. This is available in both the Logpush UI in the Cloudflare dashboard and the Logpush API.

To use the new formats, set timestamp_format in your Logpush job's output_options:

• rfc3339ms — 2024-02-17T23:52:01.123Z
• rfc3339ns — 2024-02-17T23:52:01.123456789Z

Default timestamp formats apply unless explicitly set. The dashboard defaults to rfc3339 and the API defaults to unixnano.

For more information, refer to the Log output options documentation.

Original source Report a problem

Cloudflare now exposes four new fields in the Transform Rules phase that encode client certificate data in RFC 9440 format. Previously, forwarding client certificate information to your origin required custom parsing of PEM-encoded fields or non-standard HTTP header formats. These new fields produce output in the standardized Client-Cert and Client-Cert-Chain header format defined by RFC 9440, so your origin can consume them directly without any additional decoding logic.

Each certificate is DER-encoded, Base64-encoded, and wrapped in colons. For example, :MIIDsT...Vw==:. A chain of intermediates is expressed as a comma-separated list of such values.

New fields

Field Type Description cf.tls_client_auth.cert_rfc9440 String The client leaf certificate in RFC 9440 format. Empty if no client certificate was presented. cf.tls_client_auth.cert_rfc9440_too_large Boolean true if the leaf certificate exceeded 16 KB and was omitted. In practice this will almost always be false. cf.tls_client_auth.cert_chain_rfc9440 String The intermediate certificate chain in RFC 9440 format as a comma-separated list. Empty if no intermediate certificates were sent or if the chain exceeded 16 KB. cf.tls_client_auth.cert_chain_rfc9440_too_large Boolean true if the intermediate chain exceeded 16 KB and was omitted.

The chain encoding follows the same ordering as the TLS handshake: the certificate closest to the leaf appears first, working up toward the trust anchor. The root certificate is not included.

Example: Forwarding client certificate headers to your origin server

Add a request header transform rule to set the Client-Cert and Client-Cert-Chain headers on requests forwarded to your origin server. For example, to forward headers for verified, non-revoked certificates:

Rule expression:

cf.tls_client_auth.cert_verified and not cf.tls_client_auth.cert_revoked

Header modifications:

Operation Header name Value Set Client-Cert cf.tls_client_auth.cert_rfc9440 Set Client-Cert-Chain cf.tls_client_auth.cert_chain_rfc9440

To get the most out of these fields, upload your client CA certificate to Cloudflare so that Cloudflare validates the client certificate at the edge and populates cf.tls_client_auth.cert_verified and cf.tls_client_auth.cert_revoked.

For more information, refer to Mutual TLS authentication, Request Header Transform Rules, and the fields reference.

Original source Report a problem

AI Crawl Control now supports extending the underlying WAF rule with custom modifications. Any changes you make directly in the WAF custom rules editor — such as adding path-based exceptions, extra user agents, or additional expression clauses — are preserved when you update crawler actions in AI Crawl Control.

If the WAF rule expression has been modified in a way AI Crawl Control cannot parse, a warning banner appears on the Crawlers page with a link to view the rule directly in WAF.

For more information, refer to WAF rule management.

Original source Report a problem

In the Cloudflare One dashboard, the overview page for a specific Cloudflare Tunnel now shows all replicas of that tunnel and supports streaming logs from multiple replicas at once.

Previously, you could only stream logs from one replica at a time. With this update:

Replicas on the tunnel overview

All active replicas for the selected tunnel now appear on that tunnel's overview page under Connectors. Select any replica to stream its logs.

Multi-connector log streaming

Stream logs from multiple replicas simultaneously, making it easier to correlate events across your infrastructure during debugging or incident response. To try it out, log in to Cloudflare One and go to Networks > Connectors > Cloudflare Tunnels. Select View logs next to the tunnel you want to monitor.

For more information, refer to Tunnel log streams and Deploy replicas.

Original source Report a problem

Service Key authentication for the Cloudflare API is deprecated. Service Keys will stop working on September 30, 2026.

API Tokens replace Service Keys with fine-grained permissions, expiration, and revocation.

What you need to do

Replace any use of the X-Auth-User-Service-Key header with an API Token scoped to the permissions your integration requires.

If you use cloudflared, update to a version from November 2022 or later. These versions already use API Tokens.

If you use origin-ca-issuer, update to a version that supports API Token authentication.

For more information, refer to API deprecations.

Original source Report a problem

You can now manage Cloudflare Tunnels directly from Wrangler, the CLI for the Cloudflare Developer Platform. The new wrangler tunnel commands let you create, run, and manage tunnels without leaving your terminal.

Available commands

• wrangler tunnel create — Create a new remotely managed tunnel.
• wrangler tunnel list — List all tunnels in your account.
• wrangler tunnel info — Display details about a specific tunnel.
• wrangler tunnel delete — Delete a tunnel.
• wrangler tunnel run — Run a tunnel using the cloudflared daemon.
• wrangler tunnel quick-start — Start a free, temporary tunnel without an account using Quick Tunnels.

Wrangler handles downloading and managing the cloudflared binary automatically. On first use, you will be prompted to download cloudflared to a local cache directory.

These commands are currently experimental and may change without notice.

To get started, refer to the Wrangler tunnel commands documentation.

Original source Report a problem