Cloudflare is extending its security, performance, and programmability services to private applications, unifying how both public and private origins are protected. This new capability allows organizations to route public traffic to private IP addresses without exposing them to the public internet, eliminating the need for separate operational stacks and complex networking configurations. It leverages existing Cloudflare private network connectivity (like WAN or Mesh) to apply services such as WAF, rate limiting, and caching to internal APIs and services, ensuring consistent security and performance.
Read original on Cloudflare BlogTraditionally, public-facing applications and private internal applications have existed in distinct networking and security environments. Public apps utilized CDNs and WAFs, while private apps relied on VPNs and firewalls. This architectural separation often led to private applications missing out on modern security, performance, and programmability features like WAF, bot management, rate limiting, and caching. Cloudflare's new initiative, "Application Services for Private Origins," aims to bridge this gap, treating traffic to private applications with the same level of service as public ones.
The core innovation lies in enabling Cloudflare's edge network to route public traffic directly to private origins over existing private network connections, without requiring public IP exposure or connector software on the origin itself. This builds upon existing Cloudflare connectivity patterns such as Cloudflare Tunnel, Cloudflare One Client, and private network integrations (IPsec, GRE, CNI links, Cloudflare Mesh). The system extends Cloudflare’s private networking routing layer into the application services stack, allowing security and performance proxy infrastructure to treat private IPs as valid origin targets for public hostnames.
Unified Application Protection
The key benefit is a unified security and performance posture for all applications, regardless of their public or private nature. This simplifies operational overhead and reduces the attack surface by centralizing controls at the Cloudflare edge.
When a DNS record is configured with `proxied: true` and `use_private_routing: true`, Cloudflare's proxy platform intercepts the request. Instead of attempting to connect to the private IP over the public Internet, the request is handed to Cloudflare's private networking layer. This layer then routes the connection through the customer's pre-existing private network connectivity (e.g., IPsec tunnels, Cloudflare Tunnel, Cloudflare Mesh) to the private origin. This mechanism ensures that WAF, rate limiting, bot management, caching, and transform rules are applied at the edge before traffic enters the private network.
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
}This model is not limited to HTTP/HTTPS. Cloudflare Spectrum, the Layer 4 proxy, can now protect TCP and UDP services on private IPs by specifying a `virtual_network_id` in the origin configuration. Similarly, Workers VPC bindings enable Cloudflare Workers to directly call private APIs over these secure private paths. This expansion significantly broadens the scope of applications that can benefit from Cloudflare's edge services, from internal databases to AI agent backends.