Cloudflare Routes Public Traffic to Private Origins Without Exposing Them

Cloudflare has announced a closed beta for Application Services for Private Origins, a feature that allows customers to route public traffic to private applications without exposing those origins to the internet. Instead of requiring public IPs, firewall exceptions, or running cloudflared on the origin, you can now point a proxied DNS record at a private IP and let Cloudflare's proxy handle the rest.

The core idea is that security and performance services like WAF, rate limiting, bot management, caching, and Workers should apply to private applications—internal APIs, AI agent backends, MCP servers—just as they do to public websites. Until now, applying those services to private origins meant tradeoffs: either expose the origin publicly, run connector software, or maintain parallel infrastructure like public-facing load balancers and reverse proxies.

How it works

The feature extends Cloudflare's existing private networking layer—used by Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, and Cloudflare WAN—into the application services stack. When you enable private routing on a proxied DNS record, Cloudflare's proxy sees the use_private_routing flag and routes traffic through the customer's existing private connectivity (IPsec, GRE, CNI, Tunnel, or Mesh) instead of attempting a direct public connection.

The API is straightforward: add "use_private_routing": true to a DNS record with a private IP. Cloudflare's Origin API returns metadata that tells the proxy to use the private network path.

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "use_private_routing": true
}

Behind the scenes, the proxy queries the Origin API and gets back:

{
  "zone_name": "example.com",
  "ipv4_addresses": ["10.0.0.50"],
  "use_private_routing": true
}

The flag triggers the private networking layer, which routes the connection over the customer's existing tunnels or WAN links.

Beyond HTTP

The same model extends to non-HTTP traffic via Spectrum (Layer 4 proxy) and Workers VPC bindings. You can now put Spectrum in front of a TCP database or UDP logging endpoint running on a private IP by specifying a virtual_network_id on the origin configuration. Workers can also call private APIs directly through VPC bindings, using the same routing layer.

What's missing

Today's release covers public-to-private traffic. Cloudflare says private-to-private (e.g., a user on a private network accessing a private app through Cloudflare's security stack) is next. The closed beta is available for eligible Enterprise customers.

For teams already running Cloudflare WAN or Mesh, this removes a significant operational burden: no more maintaining separate public-facing load balancers or TLS termination layers just to get WAF in front of an internal API. The private origin stays private, and Cloudflare handles the security and performance layer.