Cloudflare Beta Routes Public Traffic to Private Apps via DNS and Private Networks

Cloudflare has announced a new capability that lets organizations direct public internet traffic to applications running on private, non-public IP addresses, without exposing those applications directly. The feature, called public-to-private routing, is now in closed beta for eligible Enterprise customers, with general availability (GA) targeted for the fourth quarter of 2026. The approach uses the Domain Name System (DNS), the internet's address book, to route requests, combined with Cloudflare's private network connectivity.

At the heart of the system is a change to how Cloudflare's proxy platform, the intermediary that stands between users and a customer's servers, decides where to send each request. When a request arrives for a hostname such as app.example.com, Cloudflare queries its internal Origin API. The response includes metadata with a flag called use_private_routing. If that flag is set to true, the proxy does not try to connect to the private IP address over the public internet. Instead, it passes the request to Cloudflare's private networking layer, which sends it through the customer's existing private network connectivity. Supported paths include IPsec, a set of protocols for encrypting network traffic between sites; GRE, a tunnelling protocol; Cloudflare Tunnel, a secure outbound connector; CNI, Cloudflare Network Interconnect; and Cloudflare Mesh.

The same routing model now extends beyond ordinary web traffic. An origin no longer has to be a web server; it can be a TCP database, a UDP logging endpoint, or a private API called directly by Cloudflare Workers, the company's serverless code platform. Spectrum, Cloudflare's Layer 4 proxy for non-web protocols, can now sit in front of TCP and UDP services running on private IPs. Instead of creating a load balancer pool as an intermediary, a Spectrum application can specify a virtual_network_id directly in its origin configuration. For example, an SSH service (the secure remote login protocol) can be defined with a private IP and a virtual network ID. Cloudflare verifies that the IP address matches a route in the customer's Cloudflare Tunnel before saving the configuration; if there is no match, the API rejects the request. In this initial release, Spectrum private origins are supported only through Cloudflare Tunnel, but support for additional private network connectivity options will come later.

Cloudflare Workers VPC closes the loop for code running on Cloudflare. A binding, a connection setting, tells the Workers runtime to route through the same private path as DNS records. As a result, browsers, mobile apps, Workers, and AI agents can all reach private origins through Cloudflare. For internet traffic, DNS records define the routing; for Workers, bindings do the same job. The key benefit is that services stay private: no public IP address, no connector software, and no load balancer are required.

Looking ahead, Cloudflare plans to move beyond public-to-private flows to private-to-private traffic: users, services, and AI agents on private networks securely reaching applications on other private networks, with Cloudflare's application services in the middle. The company describes an end state where the same Cloudflare infrastructure secures traffic regardless of whether the user or the origin is public. For example, an employee using Cloudflare One Client to access wiki.company.internal would receive the same web application firewall (WAF), rate limiting, and bot management protections as a customer accessing a public API. Similarly, an AI agent consuming a proprietary internal API would run through the same security stack as a browser, and service-to-service traffic across clouds and data centers would get the same controls as internet traffic, even when neither endpoint sits on the public internet.

Access to the closed beta is available today for eligible Enterprise customers. Interested teams should contact their Cloudflare account team to request access. Once enabled, the setup process is documented in Cloudflare's developer documentation. Customers will need Cloudflare One connectivity through one of the supported options (IPsec, GRE, CNI, or Cloudflare Mesh) and must configure a return route in their private network for Cloudflare's source IP range 100.64.0.0/12. For organizations that run their own domains and private applications, protecting the DNS records that point to those services is just as important as securing the network path; using an encrypted DNS service like AEU DNS can help prevent DNS spoofing and hijacking attempts that could redirect users away from your private application.