For most of the Internet’s history, public and private infrastructure operated as separate worlds. Public applications lived behind content delivery networks (CDNs) and web application firewalls (WAFs). Private applications lived behind virtual private networks (VPNs), firewalls, and separate operational stacks.
We think that distinction is becoming obsolete. Many of the applications organizations care about are not public websites. They are internal APIs, AI agent backends, MCP servers, operational tools, and services that were never designed to be exposed to the public Internet.
Yet these applications still need modern security, performance, and programmability services. Security should be a property of the traffic reaching an application, not an accident of where the application happens to sit. Until now, applying those services to private applications often required public IPs, firewall exceptions, connector software, or complex networking.
As a result, many private applications missed out on capabilities such as WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers, despite needing the same protections and controls as public-facing applications. Today, we're launching Application Services for Private Origins in closed beta for eligible Enterprise customers. Customers can now securely route traffic to private origins without exposing those origins to the public Internet.
This allows Cloudflare's security, performance, and programmability services to protect applications running on private networks, just as they do for public Internet applications. WAF rules, bot management, rate limiting, caching, rewrites, and Workers can now sit 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 today through Cloudflare Tunnel , Cloudflare One Client , and private network integrations. For years, Cloudflare Tunnel has allowed customers to route public traffic to private applications through cloudflared . This new capability extends the same model to existing Cloudflare WAN or Cloudflare Mesh connectivity without requiring connector software running on the origin.
Much of that connectivity is orchestrated through Cloudflare’s private networking routing layer that 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 instead of managing separate networking stacks for each product.
We have extended Cloudflare’s private networking layer directly into the application services stack, allowing security and performance proxy infrastructure to treat private IPs as valid origin targets for public hostnames. As a result, the same private IPs previously reachable only through Cloudflare Tunnel, Cloudflare One, Cloudflare Mesh, or Cloudflare WAN can now sit behind Cloudflare’s security, performance, and programmability services the same way public origins already do.
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 moves through their Cloudflare environment. Application traffic now falls into four combinations based on where users come from and where applications live: The combination on the upper right is what Cloudflare has always done: users on the Internet reach applications on the Internet, with Cloudflare in the middle.
The bottom right is Cloudflare One : users on private networks reach public services securely. The upper left is what we are shipping today. The bottom left, private-to-private, is what we are building toward next.
What is shipping today Until now, getting public traffic to a private origin often meant making tradeoffs. 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 required additional complexity, operational overhead, or separate products. Application Services for Private Origins removes those tradeoffs. What was missing was a path for customers who already operate Cloudflare WAN ( IPsec tunnels , GRE tunnels , CNI links ) or Cloudflare Mesh .
They had built private connectivity into Cloudflare for site-to-site networking and Zero Trust , and they wanted to use that same connectivity for public traffic to private origins. That is what Application Services for Private Origins delivers. When you toggle Use private network routing on a proxied A or AAAA record, Cloudflare's WAF, rate limiting, caching, bot management, and transform rules all run as normal 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 enabled automatically 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 reachable only through your private network or tunnel, you can enable the toggle manually.
Originally published at blog.cloudflare.com
