Cloudflare's Private Origins service is now generally available, letting customers point a proxied DNS record at a private IP address and have Cloudflare reach the origin over an existing Cloudflare One connection, according to Cloudflare's blog post announcing the release. The origin never exposes a public IP, and the company's application services — WAF, bot management, rate limiting, caching, and Workers — apply to that traffic the same way they do for public origins.
The mechanism is a DNS record attribute. A standard proxied A or AAAA record gets a private_routing flag, and Cloudflare's proxy platform queries what the post calls Cloudflare's Origin API to decide where to send traffic. When that API response includes private_routing: true, the proxy hands the request to Cloudflare's private networking layer instead of attempting a direct connection over the public internet. That layer then routes the connection across whatever private connectivity the customer already runs: IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh, per the post.
Private network routing turns on automatically for three address ranges: RFC 1918 private IPv4 addresses, RFC 6598 CGNAT addresses (100.64.0.0/10), and RFC 4193 unique local IPv6 addresses (fc00::/7). Cloudflare's post is explicit that this can't be disabled for those ranges — attempts to turn it off through the API return an error. For origins using a public IP reachable only through a private network, the setting has to be enabled manually. TLS termination, WAF, rules and caching all continue running on Cloudflare's network regardless of path.
On the operator side, Cloudflare WAN requires no connector software on the origin at all; Cloudflare Mesh runs a connector inside the private network that can serve multiple origins. Either way, teams connecting over Cloudflare WAN or Mesh need to configure a return route for Cloudflare's source ranges — 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. The post flags this directly from its own beta experience: "A missing route for Cloudflare's source range was the most common setup failure we saw," and the general advice when requests time out with nothing reaching the origin is to check that return route first.
The feature set has real gaps at GA. Argo Smart Routing and Dedicated CDN Egress IPs aren't supported, and origin health checks require Load Balancing — limitations Cloudflare lists directly in the post, pointing to its developer documentation for the complete set. Access also isn't self-serve in the usual sense: the Private Origins entitlement has to be turned on by the customer's account team, and accounts need Unified Routing enabled unless they're connecting over Cloudflare Tunnel specifically, which doesn't need it.
What shipped today only covers public traffic reaching private origins — internet requests from partners, customers, or, as the post specifically names, AI agent backends and MCP servers hitting infrastructure that was never built to face the internet. Private-to-private traffic, where services or agents on one private network reach applications on another private network through Cloudflare, is still in engineering. Cloudflare says it's targeting a closed beta for that in early 2027, open to customers who talk to their account team.
For teams running origin infrastructure behind Cloudflare already, the practical move is narrow and specific: this removes the need to expose a public IP, open a firewall port, or run cloudflared alongside the origin just to get WAF and rate limiting on an internal API or agent backend, but it only closes the public-to-private leg — anything crossing between two private networks still waits on the 2027 beta.