With Workflows, you can configure built-in retry behavior for each step. Previously, you could configure step retries with fixed delay durations, such as seconds, minutes, or hours, and backoff strategies such as
constant,linear, orexponential.Step retries now support dynamic delay functions. Instead of choosing only a base delay and backoff strategy, pass a function to
retries.delayand calculate the next delay from the failed attempt and thrown error.This is useful when retries should depend on the failure. Your Workflow may need to wait longer after a rate-limit error, but retry sooner after a short network failure. The delay function can also accommodate provider guidance if, for example, a downstream API returns a
Retry-Aftervalue in its error messaging.JavaScript await step.do("sync customer",{retries: {limit: 5,delay: ({ ctx, error }) => {if (error.message.includes("rate limit")) {return `${ctx.attempt * 30} seconds`;}return "10 seconds";},},},async () => {await syncCustomer();},);TypeScript await step.do("sync customer",{retries: {limit: 5,delay: ({ ctx, error }) => {if (error.message.includes("rate limit")) {return `${ctx.attempt * 30} seconds`;}return "10 seconds";},},},async () => {await syncCustomer();},);Dynamic delay functions can return a duration string, a number, or a promise that resolves to a duration. Use them to add adaptive retry behavior without writing separate queue or scheduling logic. For more information, refer to Sleeping and retrying.
The DNS Firewall page in the Cloudflare dashboard has been refreshed, bringing several settings that were previously API-only into the UI and modernizing how you view and manage your DNS Firewall clusters.
- More settings in the dashboard: cluster options that were previously only configurable through the API — such as attack mitigation, rate limiting, negative TTL, and resolver subnet — are now available directly in the dashboard.
- Better table experience: the DNS Firewall cluster table has been revised to surface cluster details at a glance, with resizable columns and the option to show or hide columns to tailor the view to your workflow.
- New create and edit UX: adding and editing clusters now uses a modernized form that groups related settings together, making configuration faster and clearer.
Available to all DNS Firewall customers as part of their existing subscription.
In the Cloudflare dashboard, go to the DNS Firewall page.
Go to ClustersFor more information, refer to DNS Firewall.
On October 5, 2026, two changes take effect across the Zero Trust Networks API and Cloudflare Tunnel API: the CIDR-encoded route endpoints are removed, and tunnel list and get responses no longer include the
connectionsfield. If you manage private network routes or read tunnel connection details through the API,cloudflared, Terraform, or another integration, review the changes in the following sections and migrate before the removal date.The CIDR-encoded route endpoints are deprecated in favor of the standard,
route_id-based endpoints that already exist today. Both sets of endpoints route a private network through Cloudflare Tunnel or Cloudflare Mesh (the API still refers to Mesh nodes aswarp_connector) — only the request shape changes.Deprecated endpoints (removed October 5, 2026):
- Create a tunnel route (CIDR Endpoint):
POST /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded} - Update a tunnel route (CIDR Endpoint):
PATCH /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded} - Delete a tunnel route (CIDR Endpoint):
DELETE /accounts/{account_id}/teamnet/routes/network/{ip_network_encoded}
Replacement endpoints:
- Create a tunnel route:
POST /accounts/{account_id}/teamnet/routes - Update a tunnel route:
PATCH /accounts/{account_id}/teamnet/routes/{route_id} - Delete a tunnel route:
DELETE /accounts/{account_id}/teamnet/routes/{route_id}
Deprecated (CIDR-encoded path) Replacement Route identifier URL-encoded CIDR in the path ( /network/{ip_network_encoded})route_idin the path (networkmoves to the request body on create)Create POST .../teamnet/routes/network/{ip_network_encoded}POST .../teamnet/routeswithnetworkandtunnel_idin the bodyUpdate PATCH .../teamnet/routes/network/{ip_network_encoded}PATCH .../teamnet/routes/{route_id}Delete DELETE .../teamnet/routes/network/{ip_network_encoded}DELETE .../teamnet/routes/{route_id}- Capture each route's
route_idby calling List tunnel routes, or read it from the response the first time you create a route with the replacement endpoint. - Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
- If you manage routes with the
cloudflared tunnel route ip add | deletecommands, upgradecloudflaredto the latest version ↗. - If you manage routes with Terraform, make sure you are on a current version of the
cloudflare_zero_trust_tunnel_cloudflared_route↗ resource and the Cloudflare Terraform provider ↗.
Terminal window # Before: create a route by URL-encoding the CIDR into the pathcurl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/network/172.16.0.0%2F16 \-H 'Content-Type: application/json' \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \-d '{"tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'# After: create a route with the network in the request bodycurl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes \-H 'Content-Type: application/json' \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \-d '{"network": "172.16.0.0/16", "tunnel_id": "'$TUNNEL_ID'", "comment": "Example comment for this route."}'# After: update or delete a route using its route_idcurl -X PATCH https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \-H 'Content-Type: application/json' \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \-d '{"comment": "Updated comment for this route."}'curl -X DELETE https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"Starting the same day, the
connectionsarray is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (thecfd_tunnelandwarp_connectorAPI resources). Query the dedicated connections endpoint instead of reading the field off the tunnel or node object.This affects:
GET /accounts/{account_id}/cfd_tunnel—connectionsremoved from each item inresultGET /accounts/{account_id}/cfd_tunnel/{tunnel_id}—connectionsremoved fromresultGET /accounts/{account_id}/warp_connector—connectionsremoved from each item inresultGET /accounts/{account_id}/warp_connector/{tunnel_id}—connectionsremoved fromresult
Fetch connection details from the tunnel-specific connections endpoint instead of parsing it off the list or get response. For Cloudflare Tunnel, call
GET /accounts/{account_id}/cfd_tunnel/{tunnel_id}/connections. For Cloudflare Mesh, callGET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.Terminal window # Before: read connections off the tunnel objectcurl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"# After: query connections directlycurl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID/connections \-H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"Update any dashboards, monitoring scripts, or automation that parses
connectionsfrom the tunnel list or get response.cloudflaredand the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.- Smaller, faster responses. Cloudflare Tunnel and Cloudflare Mesh nodes with many connections no longer inflate every list and get call — connection detail is only fetched when you need it.
- A single way to identify a route. Consolidating on
route_idremoves the need to URL-encode CIDR ranges into the path and matches how every other resource in the Zero Trust Networks API is addressed. - Consistency across the API. Both changes align these endpoints with Cloudflare's standard REST conventions for resource identifiers and nested detail endpoints.
To learn more, refer to the Zero Trust Networks API, the Cloudflare Tunnel API, and Routes documentation.
- Create a tunnel route (CIDR Endpoint):
In AI Search, you can upload files to an instance, or connect a data source such as an R2 bucket, to make your content searchable with natural language. Each file becomes an item identified by an object key (its filename or path). The list items endpoint returns the items in an instance.
That endpoint now accepts a
keyquery parameter, so you can look up a single item by its exact object key without paging through the full list. This complements the existingitem_idfilter for when you know the key but not the ID.Terminal window curl "https://api.cloudflare.com/client/v4/accounts/<ACCOUNT_ID>/ai-search/instances/<INSTANCE_NAME>/items?key=docs/readme.md" \-H "Authorization: Bearer <API_TOKEN>"Keys are unique per data source, so combine
keywithsource(for example,source=builtin) to disambiguate when the same key exists across multiple sources.For more information, refer to managing items.
Workers AI Markdown conversion (
toMarkdown) now supports.gifand.bmpimage files, in addition to the JPEG, PNG, WebP, and SVG formats already supported.GIF and BMP files run through the same image pipeline as other formats. Each image is resized if needed (and for animated GIFs, only the first frame is used), then passed to an object-detection model to identify what it contains. Those detected objects prompt a vision model that writes a natural-language description of the image, which becomes searchable, machine-readable Markdown.
AI Search uses
toMarkdownautomatically to process the files it ingests, so any.gifand.bmpfiles are included the next time your index syncs, with no configuration changes required. This helps when your content mixes formats, for example a support knowledge base full of screenshots or an archive of BMP scans.Learn more about Markdown conversion and the full list of AI Search's supported file types.
Cloudflare IPsec now supports the
IKE_SA_INIT_FULL_TRANSCRIPT_AUTH↗ IKEv2 extension to protect against downgrade attacks on IPsec tunnels.IKEv2's original authentication design has each endpoint sign only its own outbound messages, not the full handshake transcript. A quantum-capable on-path attacker ↗ can exploit this to bypass post-quantum key exchange by downgrading the connection to classical cryptography. The
IKE_SA_INIT_FULL_TRANSCRIPT_AUTHextension addresses this by having both peers sign the entire handshake transcript during the authentication exchange, preventing an attacker from manipulating the negotiation without detection.Key details:
- Available in beta for Cloudflare WAN and Magic Transit IPsec tunnels.
- Cloudflare sends the
IKE_SA_INIT_FULL_TRANSCRIPT_AUTHnotification unconditionally as a responder when the feature flag is enabled. - Both the initiator (your device) and responder (Cloudflare) must support the extension for downgrade protection to be effective.
- This feature is currently gated by a per-account feature flag. Contact your account team to turn it on.
Refer to Downgrade protection for more details.
You can now query your R2 Data Catalog tables with R2 SQL directly from the Cloudflare dashboard, without installing a CLI or wiring up a client. This makes it easy to explore your Apache Iceberg ↗ data, validate queries, and inspect results in one place.
To get started, go to R2 Data Catalog ↗ in the Cloudflare dashboard and select Query data to launch the built-in SQL editor. From there you can:
- Write and run queries interactively — Iterate on R2 SQL directly in the browser with syntax highlighting and autocomplete, instead of re-running commands through Wrangler or the REST API.
- Explore your data — Explore your namespaces and tables alongside the editor so you can discover what's queryable without leaving the page or using other tools.
- Understand results and performance — View result sets with per-query statistics, export them, and get helpful
EXPLAINoutputs to see exactly how a query runs.
Partnering with Moondream ↗ to bring their latest model
@cf/moondream/moondream3.1-9B-A2Bto Workers AI. Moondream 3.1 is a fast vision language model built on a mixture-of-experts architecture with 9B total parameters and 2B active, delivering frontier-level visual reasoning while retaining fast, cost-efficient inference.Moondream 3.1 is designed for real-world vision tasks, with a 32K token context window for handling complex queries and structured outputs.
- Query — ask open-ended questions about an image, with an optional reasoning parameter
- Caption — generate short, normal, or long descriptions of an image
- Point — return coordinates for objects matching a target phrase
- Detect — return bounding boxes for objects matching a target phrase
Vision workloads like live camera feeds, robotics, content moderation, and interactive agents need answers in milliseconds, not seconds. Moondream 3.1's small active footprint (2B active parameters) pairs well with Workers AI's serverless, globally distributed inference: requests run close to your users, and streaming responses start returning tokens almost immediately.
In our testing, first tokens streamed back in roughly 20–30 ms, and results were fast across every task. The example end-to-end times below (client-observed median, including network round trip) are for a simple, single-subject image. Actual latency depends heavily on the image and how much detail you ask for.
Task End-to-end (p50) query~770 ms caption~480 ms point~145 ms detect~160 ms At these speeds you can call the model inline while handling a request rather than pushing the work to a background queue or a separate service. That opens up use cases where a slow response breaks the experience: moderating user-uploaded images before they are stored, locating an object in a video frame to drive a live overlay, extracting fields from a document during a form submission, or letting an agent inspect a screenshot and decide its next step within a single turn.
Use Moondream 3.1 through the Workers AI binding (
env.AI.run()) or the REST API at/ai/run. You can also use AI Gateway with these endpoints.For more information, refer to the Moondream 3.1 model page and pricing.
Cloudflare Drop ↗ lets you deploy a static site to Cloudflare without requiring a Cloudflare account to get started.
Upload a folder or zip file of static assets (static HTML, CSS, JavaScript, images, and fonts) and get a temporary live preview that stays live for 1 hour. During that window, you can test the site, share the preview URL, or claim the deployment to keep it.
When you are ready to make the deployment permanent, click Claim to sign in or create a Cloudflare account. You can claim the site into an existing Cloudflare account or create a new account for the deployment.
After claiming the site, you can:
- Add a domain: Connect an existing domain or purchase a new one for your site.
- Enable observability: Monitor your site's performance and usage.
- Enable Markdown for Agents: Allow AI agents to access your site's content in Markdown.
- Control access: Make your site private and choose who can view it.
A new GA release for the Windows Cloudflare One Client is now available on the stable releases downloads page.
This hotfix addresses a Windows authentication issue in the embedded WebView2 browser. Single sign-on could fail to use the Windows primary account, causing users to be prompted for an interactive sign-in. The embedded authentication browser now allows SSO providers to use the OS primary account when available.
Workflows pricing now includes per-step billing. Requests and CPU time billing have been enabled since the initial public beta and is not changing.
A step is each unit of work executed by a Workflow, including step operations such as sleeping or waiting for events.
You can query Workflows analytics, including
stepCountfor a Workflow instance, with the GraphQL Analytics API.Starting no earlier than August 10th, 2026, Cloudflare will begin billing for step and storage usage on Workers Paid plans.
Storage pricing has been published since Workflows became generally available and is not changing. Storage is measured as persisted Workflow state in GB-months.
Dimension Workers Free Workers Paid Steps 3,000 included per day 500,000 included per month, then $0.80 per additional 100,000 steps Storage 1 GB-month included 1 GB-month included, then $0.20 per additional GB-month Developers on the Workers Free plan will not be charged for steps or storage beyond the included amounts.
Cloudflare will not bill step and storage usage before August 10, 2026.
You can review Workflows usage in the Cloudflare dashboard ↗ before this change takes effect. To reduce costs, consider reducing the number of steps per Workflow or improving the memory efficiency of your stored state.
Refer to the Workflows pricing page for full details.
You can now configure file transfer controls for browser-based RDP with Cloudflare Access, allowing you to restrict whether users can upload or download files between their local machine and the remote Windows server.
This feature is useful for organizations that support bring-your-own-device (BYOD) policies or third-party contractors using unmanaged devices. By restricting file transfers, you can prevent sensitive data from being moved out of the remote session to a user's personal device.
File transfer controls are configured per policy within your Access application, alongside existing text clipboard controls. For each policy, you can select one of the following options:
- Client to remote RDP session allowed — Users can upload files from their local machine into the browser-based RDP session.
- Remote RDP session to client allowed — Users can download files from the browser-based RDP session to their local machine.
- Both directions allowed — Users can upload and download files between their local machine and the browser-based RDP session.
- Disable copying/pasting — Users are not allowed to transfer files between their local machine and the browser-based RDP session.
By default, file transfer is denied for new policies. For existing Access applications created before this feature was available, file transfer remains denied.
To upload, drag files into the browser window or select the settings gear icon on the left side of the RDP session. To download, copy a file in the remote session and select the settings gear to download it, download multiple files as a zip, or print PDFs to a local printer.
This feature is in beta and available on all Zero Trust plans. For more information, refer to File transfer for browser-based RDP.
Browser Isolation now supports Gateway authorization proxy endpoints. You can apply HTTP Isolate policies to traffic routed through authorization proxy endpoints, the same way you can for traffic from the Cloudflare One Client.
Previously, only source IP proxy endpoints supported Browser Isolation, and only with non-identity policies. Because authorization proxy endpoints authenticate users through an identity provider, you can now apply identity-based Isolate policies to PAC file-proxied traffic without requiring the Cloudflare One Client.
To get started, create an authorization proxy endpoint and build an Isolate policy.
Browser Run now supports a standalone
/accessibilityTreeendpoint, giving agent and automation workflows direct access to the browser's accessibility tree for a rendered webpage.An accessibility tree is the browser's structured view of a rendered page: roles, names, states, values, and hierarchy. It is useful for accessibility tooling, but also for AI agents and automation workflows that need page structure without the noise of raw HTML or the cost of screenshots.
For AI agents, this means less inference from pixels and less parsing HTML. You can provide the page structure directly, helping agents identify available elements and determine which actions they can take.
With the new
/accessibilityTreeendpoint, you can request the accessibility tree directly when you only need the semantic structure of a page. If you need multiple page formats in a single API call, you can use the/snapshotendpoint, which also returns Markdown, HTML, and screenshots.Terminal window curl -X POST 'https://api.cloudflare.com/client/v4/accounts/<accountId>/browser-run/accessibilityTree' \-H 'Authorization: Bearer <apiToken>' \-H 'Content-Type: application/json' \-d '{"url": "https://example.com/"}'{"success": true,"result": {"accessibilityTree": {"role": "RootWebArea","name": "Example Domain","children": [{"role": "heading","name": "Example Domain","level": 1},{"role": "link","name": "Learn more"}]}}}Use
interestingOnlyto return only semantically meaningful nodes, orrootto capture the accessibility tree for a specific subtree.Refer to the
/accessibilityTreedocumentation for usage examples and supported parameters.
Enterprise customers can now push per-connection WebSocket analytics to any Logpush destination using the new
websocket_analyticsdataset. Each log record is emitted when a WebSocket connection closes and includes fields that were previously only available to Cloudflare engineers via internal tooling.Key fields include:
ConnectionCloseReason— why the connection ended:peerReset,peerNoError,timedOut,upstreamReset,protocolViolation,unspecifiedError, ornone.ConnectionCloseSource— which side initiated the close:upstream,downstream,me, orboth.ConnectionTransportCloseCode— the TLS alert code or TCP-level close code for additional precision.RayID— correlate WebSocket connection events with your existing HTTP Request logs.
The dataset also includes directional byte counts (
BytesSentClient,BytesReceivedClient,BytesSentOrigin,BytesReceivedOrigin), connection timestamps, client IP, colo code, and request metadata from the original WebSocket upgrade.This data lets you build alerts on connection close patterns — for example, detecting spikes in TCP resets (
ConnectionCloseReason == "peerReset") grouped by host and data center — directly in your existing log analysis tools.For the full list of available fields, refer to WebSocket Analytics.
R2 Data Catalog is a managed Apache Iceberg ↗ catalog built directly into your R2 bucket. Iceberg tracks your data through a tree of metadata files, so every insert, update, and delete must go through a catalog transaction. Manually adding, modifying, or deleting objects outside the catalog can leave pointers referencing files that no longer exist, corrupting the table into an inconsistent state that is difficult to recover from.
To help prevent this, the R2 dashboard and Wrangler now warn you when you attempt a manual delete operation on a Data Catalog-enabled bucket.
When you try to delete objects from a bucket that has R2 Data Catalog enabled, the dashboard displays a warning explaining that the operation could leave the catalog in an invalid state, with a link to the documentation for deleting data correctly. You can cancel the operation or choose to proceed anyway.
Wrangler now checks whether a bucket is Data Catalog-enabled before running a delete and warns you before continuing:
Data Catalog is enabled for this bucket.Proceeding may leave the data catalog in an invalid state. Continue?To learn how to safely manage and delete data in your tables, refer to the R2 Data Catalog documentation.
You can now register a Cloudflare One Virtual Appliance and generate its license key directly from the dashboard, without contacting your account team.
- On the Connectors page, select Add an appliance and choose Virtual appliance to register a virtual appliance and generate its authentication key.
- Use Regenerate authentication key from a virtual appliance connector's menu to rotate its key. The previous key is immediately and irrevocably revoked.
- The authentication key is shown only once — copy and store it securely.
This complements the existing API and Terraform self-serve workflow for provisioning virtual appliances. Hardware appliances continue to use the existing account-team fulfillment workflow.
For details, refer to Configure a Cloudflare One Virtual Appliance.
Announcement Date Release Date Release Behavior Legacy Rule ID Rule ID Description Comments 2026-07-06 2026-07-13 Log N/A Citrix Netscaler ADC - Insufficient Input Validation - CVE:CVE-2026-8451 This is a new detection.
2026-07-06 2026-07-13 Log N/A Progress Kemp LoadMaster - Remote Code Execution - CVE:CVE-2026-8037 This is a new detection.
We have released version 5 of
@cloudflare/workers-types↗. This release simplifies the package to expose only the latest runtime types.We still recommend that you generate types for your Worker using
wrangler types, but if you want to use the package directly, you can install it with your package manager of choice:npm i -D @cloudflare/workers-types@latestyarn add -D @cloudflare/workers-types@latestpnpm add -D @cloudflare/workers-types@latestbun add -d @cloudflare/workers-types@latestThe package now exposes two entrypoints:
@cloudflare/workers-typesreflects the latest compatibility date, using the latest stable compatibility flags.@cloudflare/workers-types/experimentalreflects APIs behind experimental compatibility flags.
The dated entrypoints, such as
@cloudflare/workers-types/2022-11-30and@cloudflare/workers-types/2023-03-01, are removed. With runtime type generation in Wrangler v4, you can generate these with thewrangler typescommand to create types locked to your Worker's compatibility date.For more information, refer to TypeScript language support.
When you connect a data source to your AI Search instance, AI Search runs sync jobs to keep your index up to date with your content. You can now manage those jobs directly from Wrangler.
For example, you can trigger a sync job from your CI/CD or automated pipelines with the
jobs createcommand so your index refreshes when you push a change:Terminal window wrangler ai-search jobs create my-instanceThis creates an asynchronous sync job that checks for changes in your data source, and sends new, modified, or deleted files to be indexed. The following commands are available:
Command Description wrangler ai-search jobs createTrigger a new sync job wrangler ai-search jobs listList sync jobs for an instance wrangler ai-search jobs getGet details for a job wrangler ai-search jobs cancelCancel a running job wrangler ai-search jobs logsView log entries for a job All commands accept
--namespace/-n(defaults todefault) and--jsonfor structured output that automation and AI agents can parse directly. Thelistandlogscommands also support--pageand--per-pagefor pagination, andcancelprompts for confirmation unless you pass-y/--force.For full usage details, refer to the AI Search Wrangler commands documentation.
Your origin can serve different responses for the same URL — different languages based on
Accept-Language, or different formats based onAccept— by returning aVary↗ response header. Cloudflare's cache now honors that header directly in Cache Rules, so the same URL can hold multiple cached versions and each request is matched to the right one. Content that previously had to bypass cache to stay correct can now be cached, following standard HTTP caching behavior ↗.Your origin now decides which request headers matter by listing them in its
Varyresponse, and you control how Cloudflare treats each one. When you have enabled Vary using a cache rule and a response includes aVaryheader, the request headers listed become part of the cache key.For each header your origin varies on, choose one of three actions:
Action Behavior Best for normalizeConverts equivalent header values to the same cache key value before matching, collapsing redundant versions. Most Accept,Accept-Language, andAccept-Encodinguse cases.passthroughUses the raw header value to select the cached version and forwards it to the origin unchanged. When byte-for-byte differences in the header value should create versions. bypassBypasses cache whenever this header name appears in the origin's Varyresponse.Per-user values, or headers with too many possible values to cache safely. - Higher cache hit ratios:
normalizetreats semantically equivalent headers as one version. For example,Accept-Language: en-US, fr;q=0.8andAccept-Language: fr;q=0.8, en-GBboth resolve to the same cache key, so you serve more requests from cache instead of the origin. - Correct content negotiation: Requests always receive the cached version that matches their headers, so language and format variants stay accurate.
- No origin or Worker changes required: If your origin already sends
Vary, you configure the behavior entirely in Cache Rules. - Standards-aligned: Cache key calculation follows RFC 9111, and
Vary: *continues to bypass cache as required by RFC 9110.
Vary in Cache Rules is available on all plans (Free, Pro, Business, and Enterprise). For per-request control in Workers subrequests, use the
cf.varyproperty.Configure Vary in the Cloudflare dashboard ↗ under Caching > Cache Rules, or through the Rulesets API. To learn how Vary affects cache keys and how each action works, refer to Vary and the Cache Rules Vary setting.
- Higher cache hit ratios:
Cloudflare has updated Logpush datasets:
- Gateway DNS (added):
AppliedMaxTTLandUpstreamRecordTTLs. - Gateway HTTP (added):
Warnings. - HTTP requests (added):
CacheLockWaitedMs.
For the complete field definitions for each dataset, refer to Logpush datasets.
- Gateway DNS (added):
You can now add hostname routes to a Cloudflare Mesh node, in addition to CIDR routes.
-
Requests
wiki.internal.local - DNS query
-
Returns a token IP, then rewrites the destination to the real private IP.
100.80.0.0/16 - Hostname route
-
Forwards traffic to the host on the local network
- Private host
wiki.internal.local·10.0.0.50
Instead of managing IP ranges, you can attract traffic for a hostname to a Mesh node:
- Private hostname (for example,
wiki.internal.local) — reach an internal application by name, which is useful when it has an unknown or ephemeral IP. On Mesh you do not need to run a DNS server; a local hosts-file entry on the node is enough, or you can use a Gateway resolver policy for split DNS. - Public hostname (for example,
www.example.com) — route that hostname's traffic through the node and egress via the node's public IP.
For setup steps, prerequisites, and DNS options, refer to Hostname routes.
-
Wrangler CLI now supports auth profiles: named logins that you scope to specific Cloudflare accounts and switch between automatically, based on the directory you are working in.
A profile is a named OAuth login bound to a directory. Commands run in that directory, and its subdirectories, use the matching account — so you can move between accounts without re-running
wrangler login.Use profiles to keep a separate login for each client when working at an agency, or to separate staging and production into different accounts. Pair a profile with an
account_idin your Wrangler configuration file so a command cannot reach the wrong account.Terminal window # Create a profile for each account, choosing which accounts it can reachwrangler auth create client-awrangler auth activate client-a ~/clients/client-awrangler auth create client-bwrangler auth activate client-b ~/clients/client-bUse the
--profileflag to run a single command with a specific profile:Terminal window wrangler deploy --profile personalIn CI and other automated environments,
CLOUDFLARE_API_TOKENstill takes precedence over all profiles.For setup, the resolution order, and the full command reference, refer to Authentication profiles.
A new GA release for the Linux Cloudflare One Client is now available on the stable releases downloads page.
This package is the same release as 2026.6.822.0, with a fix for our RPM package. Previously the repository served a single build to every OS version, so an install could pull a dependency that isn't available on that release. The repository now serves the correct build for each operating system version, so installs automatically pull the dependencies that version requires. Debian and Ubuntu were not affected.
If you installed version 2026.6.822.0 on an RPM-based distribution, we recommend refreshing your repository configuration:
sudo curl -fsSL https://pkg.cloudflareclient.com/cloudflare-warp-ascii.repo | sudo tee /etc/yum.repos.d/cloudflare-warp.repo sudo dnf clean all sudo dnf install cloudflare-warp