For most of the Internet’s history, public and private infrastructure have existed in separate realms. Public-facing applications were shielded by content delivery networks (CDNs) and web application firewalls (WAFs), while private applications relied on virtual private networks (VPNs), firewalls, and entirely separate operational setups. We believe this division is rapidly becoming outdated.
Many of the applications that matter most to organizations aren’t public websites. They include internal APIs, AI agent backends, MCP servers, operational tools, and services never intended for public Internet exposure. Despite this, these applications still require modern security, performance, and programmability features. Security should depend on the nature of the traffic reaching an application, not on whether the application happens to be publicly accessible.
Until now, delivering those capabilities to private applications typically demanded public IP addresses, firewall exceptions, connector software, or intricate networking configurations. Consequently, many private applications lacked access to essential features like WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, even though they needed the same protections and controls as their public-facing counterparts.
Today, we’re introducing Application Services for Private Origins in closed beta for qualifying Enterprise customers. Customers can now route traffic to private origins securely without exposing those origins to the public Internet. This enables Cloudflare’s security, performance, and programmability services to safeguard applications running on private networks, just as they already do for public Internet applications.
WAF rules, bot management, rate limiting, caching, rewrites, and Workers can now be deployed in front of private origins without requiring public IP exposure, inbound firewall rules, or cloudflared running on the origin.
Four use cases, one application layer
This routing model builds on connectivity patterns Cloudflare already supports through Cloudflare Tunnel, Cloudflare One Client, and private network integrations. For years, Cloudflare Tunnel has enabled customers to route public traffic to private applications using cloudflared. This new capability extends the same approach to existing Cloudflare WAN or Cloudflare Mesh connectivity without requiring connector software on the origin.
Much of this connectivity is managed through Cloudflare’s private networking routing layer, which determines how traffic reaches private destinations across Cloudflare Tunnels, Virtual Networks, Cloudflare Mesh, and other connectivity models. Customers can define their routing behavior through APIs and the dashboard rather than managing separate networking stacks for each product.
We have extended Cloudflare’s private networking layer directly into the application services stack, enabling security and performance proxy infrastructure to treat private IPs as valid origin targets for public hostnames. As a result, the same private IPs previously accessible only through Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, or Cloudflare WAN can now be placed behind Cloudflare’s security, performance, and programmability services in the same way public origins already are.
This also creates a more unified model across Cloudflare products. Workers VPC bindings and Spectrum private origin routing now rely on the same underlying private connectivity layer, giving customers a single source of truth for controlling how private traffic flows through their Cloudflare environment.
Application traffic now falls into four categories based on where users originate and where applications are hosted:
The combination in the upper right is what Cloudflare has always handled: Internet users reaching Internet-hosted applications, with Cloudflare in between. The bottom right represents Cloudflare One: users on private networks securely accessing public services.
The upper left is what we’re launching today. The bottom left, private-to-private, is what we’re working toward next.
Until now, directing public traffic to a private origin often required compromises. Customers could use Cloudflare Tunnel, which runs cloudflared, our connector software, on or near the origin, or Cloudflare Load Balancing with private origin pools for health checks and failover. In many cases, organizations also maintained parallel infrastructure such as public-facing load balancers, reverse proxies, mTLS between hops, and TLS termination across multiple layers. As a result, applying Cloudflare’s full Application Services stack to private applications often introduced additional complexity, operational overhead, or required separate products. Application Services for Private Origins eliminates those tradeoffs.
What was missing was a solution for customers already operating Cloudflare WAN (IPsec tunnels, GRE tunnels, CNI links) or Cloudflare Mesh. They had established private connectivity into Cloudflare for site-to-site networking and Zero Trust, and they wanted to leverage that same connectivity for public traffic to private origins. That’s exactly what Application Services for Private Origins provides.
When you enable Use private network routing on a proxied A or AAAA record, Cloudflare’s WAF, rate limiting, caching, bot management, and transform rules all function normally on Cloudflare’s network. The only difference is the final hop: instead of reaching the origin over the public Internet, Cloudflare routes the connection through your existing private network connectivity.
The toggle is automatically enabled for RFC 1918 private IPv4 ranges (10.x.x.x, 172.16.x.x–172.31.x.x, and 192.168.x.x), RFC 6598 CGNAT ranges (100.64.x.x–100.127.x.x), and RFC 4193 Unique Local IPv6 Addresses (FC00::/7), since these addresses are only reachable within private networks. For public IP addresses that are accessible only through your private network or tunnel, you can enable the toggle manually.
For customers automating deployments through the API, private routing is simply an additional attribute on a standard DNS record.
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, Cloudflare’s proxy platform determines where to send traffic for app.example.com by querying Cloudflare’s Origin API. The response includes metadata indicating that the destination
Access to private origins must be established via a private network connection:
{
"zone_name": "example.com",
"ipv4_addresses": ["10.0.0.50"],
"use_private_routing": true
}The use_private_routing setting is the critical indicator. When our proxy detects this flag, rather than trying to connect to the private IP over the public Internet, it passes the request to our private networking layer. This layer then directs the connection through the customer’s existing private network links, such as IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.
Beyond HTTP: Spectrum and Workers VPC
This routing approach now covers more than just HTTP applications. The origin doesn’t need to be a web server. It could be a TCP database, a UDP logging service, or a private API that Workers invoke directly. The consistent principle is that Cloudflare positions itself between your traffic and your private network, delivering identical security, performance, and routing capabilities regardless of the protocol or the source of the request.
Spectrum, Cloudflare’s Layer 4 proxy, can now protect TCP and UDP services hosted on private IPs. Rather than setting up a load balancer pool as a middleman, Spectrum applications can assign a virtual_network_id directly to the origin settings. When configuring a Spectrum application, you can specify the virtual network ID along with your private origin IP:
{
"protocol": "tcp/22",
"dns": {
"type": "CNAME",
"name": "ssh.example.com"
},
"origin_direct": ["tcp://10.0.0.50:22"],
"virtual_network_id": "fab9ac85-491b-44c8-b7ae-dd44d4f4672e"
}When you create or modify a Spectrum application with a private origin and virtual network, Cloudflare confirms that the IP address corresponds to a route in your Cloudflare Tunnel before saving the configuration. If no matching route is found, the API denies the request and the application isn’t created. Once saved, Spectrum routes the connection through your virtual network, sending it through the linked tunnel using the same pathway that HTTP traffic follows when private network routing is enabled on a DNS record. In this initial release, Spectrum private origins work exclusively through Cloudflare Tunnel. Support for other private network connectivity methods will be added in upcoming releases.
This means you can now place Spectrum in front of any TCP/UDP service on a private IP. The service remains entirely private. No public IP, connector software, or load balancer is needed.
Workers VPC completes the picture for code executing on Cloudflare. A binding instructs the Workers runtime to use the same private pathway as DNS records. Browsers, mobile apps, Workers, and AI agents all connect to your private origins through Cloudflare: DNS records handle Internet traffic, while bindings handle Workers traffic.
Public-to-private routing is currently in closed beta, with General Availability (GA) planned for Q4 2026.
After GA, we plan to expand into private-to-private traffic flows: users, services, and AI agents on private networks will be able to securely access applications on other private networks, with Cloudflare’s application services positioned in between.
We’re working toward a model where the same Cloudflare infrastructure secures traffic whether the user or the origin is public or private.
The ultimate goal is a scenario where an employee using Cloudflare One Client to reach wiki.company.internal receives the same WAF, rate limiting, and bot management protections as a customer accessing a public API. An AI agent calling a proprietary internal API passes through the same security stack as a browser. Service-to-service communication across clouds and data centers gets the same level of control as Internet traffic, even when neither the user nor the server is on the public Internet.
Routing to private origins is available today in closed beta for qualifying Enterprise customers. Contact your Cloudflare account team to request access. Once enabled, follow our developer documentation, which guides you through the complete setup process. You’ll need Cloudflare One connectivity (IPsec, GRE, CNI, or Cloudflare Mesh) and a return route for Cloudflare’s source IP range 100.64.0.0/12 within your private network.
Have questions or feedback? Join the discussion in our community forums or contact your account team.
