Cloudflare brings WAF and caching to private-IP origins
Private origins reaches general availability, letting internal APIs, MCP servers and AI agent backends sit behind Cloudflare's edge without ever getting a public IP.
Cloudflare’s private origins service reached general availability on 30 October, after running as a closed beta since June. Point a proxied DNS record at a private IP, and Cloudflare reaches it over your existing Cloudflare One connection. WAF and managed rules, bot management, rate limiting, caching, transform rules and Workers all work exactly as they do for a public origin, with no public IP involved.
Cloudflare’s stated target is internal APIs, AI agent backends, MCP servers and operational tools that “weren’t built to face the Internet” but still need to accept outside requests. Previously, protecting one of these meant exposing a public IP, opening a firewall port, or running cloudflared alongside it. Now it’s a DNS record with one extra flag:
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"proxied": true,
"private_routing": true
}
Getting there needs a Private Origins entitlement, switched on by your account team, plus Cloudflare One connectivity over IPsec, GRE, Cloudflare Network Interconnect, Cloudflare Tunnel or Cloudflare Mesh.
Why it matters: backend-only services have generally gone without WAF or bot management because giving them one meant making them public first. This removes that trade-off, so an internal API or MCP server that needs to take requests from partners, customers or agents can get the same edge protections a public endpoint already has.
The caveat: Argo Smart Routing and Dedicated CDN Egress IPs aren’t supported yet, and the entitlement itself isn’t self-serve, you still have to ask your account team to turn it on.