Skip to content
Cloudflare Docs
DirectoryAPISDKsChangelog

Changelog

New updates and improvements at Cloudflare.

Subscribe to RSS View RSS feeds
Cloudflare Mesh
hero image

  1. Zero Trust Networks route endpoints and Cloudflare Tunnel connections field retiring on October 5, 2026

    Cloudflare Tunnel Cloudflare Tunnel for SASE Cloudflare Mesh

    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):

    Replacement endpoints:

    What is changing

    Deprecated (CIDR-encoded path)Replacement
    Route identifierURL-encoded CIDR in the path (/network/{ip_network_encoded})route_id in the path (network moves to the request body on create)
    CreatePOST .../teamnet/routes/network/{ip_network_encoded}POST .../teamnet/routes with network and tunnel_id in the body
    UpdatePATCH .../teamnet/routes/network/{ip_network_encoded}PATCH .../teamnet/routes/{route_id}
    DeleteDELETE .../teamnet/routes/network/{ip_network_encoded}DELETE .../teamnet/routes/{route_id}

    Action required

    1. 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.
    2. Update any scripts, backend services, or CI/CD pipelines that call the CIDR-encoded endpoints directly.
    3. If you manage routes with the cloudflared tunnel route ip add | delete commands, upgrade cloudflared to the latest version ↗.
    4. 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 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:

    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.

    Terminal window
    # 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.

  1. Hostname routing for Cloudflare Mesh

    Cloudflare Mesh Cloudflare One

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

    1. Client device

      Requests wiki.internal.local

    2. DNS query
    3. Cloudflare Gateway

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

      100.80.0.0/16
    4. Hostname route
    5. Mesh node

      Forwards traffic to the host on the local network

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

  1. Manage all your routes from one page in the dashboard

    Cloudflare Mesh Cloudflare Tunnel Cloudflare WAN Cloudflare One

    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.

    The unified Routes page in the Cloudflare dashboard, showing routes across connectors in a single table

    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.

  1. Filter Workers' public Internet traffic using Gateway policies

    Gateway Cloudflare Mesh Workers VPC

    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.

    1. Worker

      Calls env.EGRESS.fetch()

    2. VPC binding
    3. Cloudflare Mesh

      Bind via cf1:network

    4. Cloudflare Gateway

      Policies applied:

      DNS HTTP Network
    5. 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.
    JSONC
    {
      "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");

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

  1. High availability replica management for Cloudflare Mesh

    Cloudflare Mesh Cloudflare One

    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.

    Mesh HA replica tabs showing active and passive replicas with per-replica Mesh IPs and a manual failover option

    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:

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

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

  1. Granular permissions for Cloudflare Tunnel and Cloudflare Mesh

    Cloudflare Fundamentals Cloudflare One Cloudflare Tunnel for SASE Cloudflare Tunnel Cloudflare Mesh

    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