Cloudflare changelogs | Cloudflare Mesh

Cloudflare Tunnel, Cloudflare Tunnel for SASE, Cloudflare Mesh - Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026

Thu, 09 Jul 2026 00:00:00 GMT

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

Route endpoints

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 as warp_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}

What is changing

	Deprecated (CIDR-encoded path)	Replacement
Route identifier	URL-encoded CIDR in the path (`/network/{ip_network_encoded}`)	`route_id` in the path (`network` moves to the request body on create)
Create	`POST .../teamnet/routes/network/{ip_network_encoded}`	`POST .../teamnet/routes` with `network` and `tunnel_id` in the body
Update	`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}`

Action required

Capture each route's route_id by 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 | delete commands, upgrade cloudflared to 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.

# Before: create a route by URL-encoding the CIDR into the path
curl 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 body
curl 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_id
curl -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"

Cloudflare Tunnel and Cloudflare Mesh connections

Starting the same day, the connections array is removed from list and get responses for Cloudflare Tunnel and Cloudflare Mesh nodes (the cfd_tunnel and warp_connector API 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 — connections removed from each item in result
GET /accounts/{account_id}/cfd_tunnel/{tunnel_id} — connections removed from result
GET /accounts/{account_id}/warp_connector — connections removed from each item in result
GET /accounts/{account_id}/warp_connector/{tunnel_id} — connections removed from result

Action required

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, call GET /accounts/{account_id}/warp_connector/{tunnel_id}/connections.

# Before: read connections off the tunnel object
curl https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/cfd_tunnel/$TUNNEL_ID \
     -H "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

# After: query connections directly
curl 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 connections from the tunnel list or get response. cloudflared and the Cloudflare Terraform provider do not read this field, so no changes are required on their side for this part of the update.

Why we are making these changes

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

Cloudflare Mesh, Cloudflare One - Hostname routing for Cloudflare Mesh

Thu, 02 Jul 2026 00:00:00 GMT

You can now add hostname routes to a Cloudflare Mesh node, in addition to CIDR routes.

Client device

Requests wiki.internal.local
DNS query ↓
Cloudflare Gateway

Returns a token IP, then rewrites the destination to the real private IP.

100.80.0.0/16
Hostname route ↓
Mesh node

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.

Go to Mesh

For setup steps, prerequisites, and DNS options, refer to Hostname routes.

Cloudflare Mesh, Cloudflare Tunnel, Cloudflare WAN, Cloudflare One - Manage all your routes from one page in the dashboard

Fri, 19 Jun 2026 00:00:00 GMT

The Routes page in the Cloudflare dashboard now shows the routes across all of your connectors — Cloudflare Mesh and Cloudflare Tunnel routes alongside Cloudflare WAN and Magic Transit static routes — in a single table, instead of a separate routes view per product.

From the unified Routes page you can:

Visualize your network with an interactive map that shows how your destinations flow through to your connectors — including equal-cost multi-path (ECMP) routes where the same prefix is served by several connectors. Select a node to filter the table down to the routes behind it.
See every route in one table, with its destination, type, connector, priority, and source, and filter or sort to find what you need.
Create, edit, and delete routes of any supported type without leaving the page. When adding a Cloudflare WAN or Magic Transit static route, you now pick the next hop by connector name instead of typing its IP.
Manage virtual networks from a dedicated tab.
Test a route to see which connector and next hop a destination resolves to before you commit a change.

To find it, go to Networking > Routes in the dashboard sidebar.

Go to Routes

Your existing routes, APIs, and configurations are unchanged — this is a dashboard experience that brings them together in one place. Learn how to add routes and manage virtual networks.

Gateway, Cloudflare Mesh, Workers VPC - Filter Workers' public Internet traffic using Gateway policies

Fri, 05 Jun 2026 00:00:00 GMT

Workers using a VPC Network binding with network_id: "cf1:network" now egress to public Internet destinations through Cloudflare Gateway. This means your existing Zero Trust traffic policies — DNS, HTTP, Network, and egress — extend to traffic that originates from your Workers, the same way they do for WARP users today.

Worker

Calls env.EGRESS.fetch()
VPC binding ↓
Cloudflare Mesh

Bind via cf1:network
↓
Cloudflare Gateway

Policies applied:

DNS HTTP Network
↓
↗ Public Internet

Any public hostname or IP

Gateway logs DNS HTTP Network

What you get by default:

Visibility. Worker egress shows up in Gateway DNS, HTTP, and Network logs alongside your other traffic, so you can audit what your Workers are calling and when.
Enforcement. Any existing Gateway policy whose selectors match a Worker request will apply — including allow / block lists, DNS category filtering, and HTTP destination rules. If you have already blocked a category for your workforce, your Workers inherit that block.

wrangler.jsonc

{
  "vpc_networks": [
    {
      "binding": "EGRESS",
      "network_id": "cf1:network",
      "remote": true,
    },
  ],
}

wrangler.toml

[[vpc_networks]]
binding = "EGRESS"
network_id = "cf1:network"
remote = true

JavaScript

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

TypeScript

// Egress to a public destination — subject to your Gateway policies and logged
const response = await env.EGRESS.fetch("https://api.example.com/data");

For configuration options, refer to VPC Networks. For policy authoring, refer to Cloudflare Gateway traffic policies.

Cloudflare Mesh, Cloudflare One - High availability replica management for Cloudflare Mesh

Thu, 28 May 2026 00:00:00 GMT

The Cloudflare Mesh dashboard now shows per-replica details for high availability nodes. You can see which replica is active, view each replica's Mesh IP and connection details, and manually trigger failover — all from the node detail page.

What's new

Replica tabs on the node detail page — switch between replicas to see each one's Mesh IP, edge data center, origin IP, platform, version, and uptime.
Active/passive badges identify which replica is currently routing traffic.
Manual failover — promote a passive replica to active with a single click. The previous active replica switches to standby.
HA badge in the overview table identifies nodes running multiple replicas.
Active replica IP shown in the overview table — the dashboard now resolves which replica is active and displays the correct Mesh IP.

Manual failover

To manually promote a passive replica:

In the Cloudflare dashboard, go to Networking > Mesh.
Select an HA-enabled node.
Select the passive replica tab.
Select Promote to active and confirm.

Traffic reroutes to the promoted replica immediately. Refer to High availability for details on failover behavior.

Cloudflare Fundamentals, Cloudflare One, Cloudflare Tunnel for SASE, Cloudflare Tunnel, Cloudflare Mesh - Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

Thu, 21 May 2026 00:00:00 GMT

You can now scope Cloudflare permissions to individual Cloudflare Tunnel instances and Cloudflare Mesh nodes. Administrators can delegate access to specific Tunnels or Mesh nodes without granting account-wide control over private networking.

What is new

When you add a member or create a permission policy, the resource picker now lists Cloudflare Tunnel instances and Cloudflare Mesh nodes as scopable resource types. You can:

Grant a read-only role on a single Cloudflare Tunnel instance to a support operator for log streaming and diagnostics — without exposing other Tunnels or destructive actions.
Grant a write role on a specific Cloudflare Mesh node to an application team — without giving them access to the rest of your private network.
Scope a single policy to one or many Tunnels and Mesh nodes at once.

How it works

Granular permissions are a parallel layer to existing account-level roles — they do not replace them.

Existing account-level roles continue to work. A member with Cloudflare Access or Cloudflare Zero Trust retains write access to every Tunnel and Mesh node in the account. This ensures backward compatibility for existing automation and tokens.
Granular permissions are additive. For any API request on a specific Tunnel or Mesh node, access is granted if the principal has either the account-level role or a granular permission for that resource.
Resource enumeration is authorization-aware. Listing endpoints (GET /accounts/{id}/cfd_tunnel, GET /accounts/{id}/warp_connector) return only the resources the principal has at least read access to.

Get started

Configure granular permissions for Cloudflare Tunnel.
Configure granular permissions for Cloudflare Tunnel and Cloudflare Mesh in Cloudflare One.
Review the resource-scoped roles on the Cloudflare role reference.