Cloudflare Makes Private Origins Generally Available, Routing Proxied Requests to Private Services over Existing Connections

On October 30, 2026, Cloudflare announced that its services for private origins are generally available. A site owner points a proxied DNS record at a private IP address, and Cloudflare reaches the origin over a Cloudflare One connection the customer already has. The origin stays private, and Cloudflare says its web application firewall (WAF), caching, bot management and Workers work as they do for public origins.

Cloudflare says it launched the capability in closed beta in June, after customers described internal APIs, AI agent backends, MCP servers and operational tools that were not built to face the Internet but still had to accept requests from partners, customers or agents. Before the beta, putting Cloudflare in front of such a service meant exposing a public IP, opening a firewall port, or running cloudflared next to the origin. Those routes often left private applications without the protections public ones had. Access during the beta went through account teams, and the post says that today Cloudflare is opening access beyond that group. General availability still requires the Private Origins entitlement on the account, which the post tells customers to ask their account team to turn on.

Setup is a proxied A or AAAA record. The "Use private network routing" setting turns on automatically for RFC 1918 private IPv4 addresses, RFC 6598 CGNAT addresses (100.64.0.0/10) and RFC 4193 unique local IPv6 addresses (fc00::/7), and for these ranges it cannot be turned off; an attempt through the API returns an error. If an origin has a public IP that is reachable only through the customer's private network, the setting can be turned on by hand. In the API it is one extra attribute on a standard DNS record, private_routing set to true. Cloudflare's proxy learns the flag from its Origin API and, instead of connecting to the address over the public Internet, hands the request to a private networking layer. That layer uses the customer's existing connectivity: IPsec, GRE, Cloudflare Tunnel, CNI or Cloudflare Mesh. TLS termination, WAF, rules and caching still run on Cloudflare's network. The origin needs no inbound firewall exception. With Cloudflare WAN no connector software is needed on the origin, and with Cloudflare Mesh one connector inside the private network can serve several origins.

Before starting, a customer needs the entitlement, Cloudflare One connectivity over IPsec, GRE, CNI, Cloudflare Tunnel or Cloudflare Mesh, and Unified Routing enabled on the account, unless it connects through Cloudflare Tunnel, which does not need it. With Cloudflare WAN or Cloudflare Mesh, the customer must also configure a return route for Cloudflare's source ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. Cloudflare's advice from the beta is to check the return route first if requests time out and nothing reaches the origin, because a missing route was the most common setup failure it saw. Some features are not supported: Argo Smart Routing and Dedicated CDN Egress IPs do not work with private origins, and origin health checks require Load Balancing. The post points to the developer documentation for the full list of limits. When we read that documentation page, it still carried a May 7 update date, a closed beta label and an Enterprise-only note, so the blog post and the documentation page did not yet agree.

Cloudflare says the next step is private-to-private traffic, meaning users, services and AI agents on one private network reaching applications on another through Cloudflare's application services. Engineering is under way, with a closed beta targeted for early 2027. For teams that already run IPsec, GRE, CNI, Tunnel or Mesh, today's release is a way to put WAF, rate limiting and caching in front of internal services without opening them to the Internet, provided the entitlement and the return route are in place.