Cloudflare Private Origins Brings Edge Protections to Internal Services

The useful part of this release isn't that Cloudflare can reach a private IP. It's that the controls teams already run on public applications now apply to internal services without opening an inbound port, exposing an address, or installing software on the origin. Cloudflare services for private origins is generally available, and for teams with an existing private network connection, setup is mostly a DNS record change.

Why the old options were awkward

Internal APIs, AI agent backends, MCP servers and operational tools were rarely built to face the internet, yet they still need to accept requests from customers, partners and agents who are outside the network. Cloudflare says that tension is what customers kept raising. Before this capability, putting Cloudflare in front of such a service meant one of three things: give the origin a public IP, open a firewall port, or run cloudflared alongside the application.

Each of those options carries a cost. A public IP widens the attack surface of a service that was never meant to be exposed, and an open firewall port is a standing exception to maintain. Running a connector next to every origin adds software to manage on each host. The result was that many private applications ended up without the WAF rules, bot management, rate limiting, caching, rewrites and Workers that public applications take for granted. That gap is what this release targets.

What works on a private origin today

With a proxied A or AAAA record pointing at a private IP, the application services behave the way they do for public origins. That covers WAF and managed rules, bot management, rate limiting, caching, transform and rewrite rules, and Workers. Existing configuration applies to the hostname without changes, which matters for teams that already have tuned rulesets and cache behavior.

The limitations are specific, and they're worth checking before you plan a migration. Argo Smart Routing and Dedicated CDN Egress IPs aren't supported. Origin health checks depend on Load Balancing. If your failover design relies on Argo or fixed egress addresses, you'll need to account for that. The developer documentation has the full list of current limitations.

How the routing actually works

The mechanism is simpler than the outcome suggests. Cloudflare's proxy platform looks up where traffic for a hostname should go by querying the Origin API. For a private destination, the response carries a private_routing flag. When the proxy sees that flag, it doesn't try to reach the private address across the public internet. It hands the request to a private networking layer, which carries it across the connectivity the customer already runs.

That connectivity can be IPsec, GRE, Cloudflare Tunnel, CNI or Cloudflare Mesh. TLS termination, WAF evaluation, rules and caching still happen on Cloudflare's network. Only the last leg to the origin changes path. This is the part I'd want engineers to internalize: the origin never sees a public request, but the request still gets the full edge treatment before it reaches the private link.

Private network routing turns on automatically for RFC 1918 IPv4 ranges, RFC 6598 CGNAT addresses in 100.64.0.0/10, and RFC 4193 unique local IPv6 addresses in fc00::/7. For those ranges the setting can't be disabled, and API attempts to turn it off return an error. If your origin uses a public IP that's reachable only through your private network, you can enable the setting manually.

The API view

For teams automating deployments, private routing is just another 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,
  "private_routing": true
}

That makes it straightforward to fold into infrastructure-as-code. A Terraform module or deployment pipeline that already creates proxied records only needs the extra field for private hosts.

Connectivity choices and what each one asks of you

The connection type determines how much you have to build. With Cloudflare WAN, no connector software is needed on the origin. With Cloudflare Mesh, a connector runs inside your private network and can serve multiple origins, which is useful if you have many internal services behind one site. Tunnel is another route, and it doesn't require Unified Routing, which is the only prerequisite that changes by connection type.

Before starting, you'll need the Private Origins entitlement on your account, which your account team enables. You'll also need Cloudflare One connectivity over IPsec, GRE, CNI, Tunnel or Mesh. Unified Routing must be enabled unless you connect over Tunnel, and existing accounts can upgrade through their account team.

If you connect over WAN or Mesh, there's one step that's easy to miss. Configure a return route for Cloudflare's source ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. Then create the proxied record and confirm that "Use private network routing" is enabled.

The return route is the usual failure point

Cloudflare's beta experience points to a clear first troubleshooting step. If requests time out and nothing arrives at the origin, check the return route before anything else. A missing route for Cloudflare's source range was the most common setup failure during the beta. It's a networking problem rather than a Cloudflare configuration problem, and it can look like the origin is down when it's simply unreachable on the way back.

That's a useful lesson for any private-network integration. Asymmetric routing and missing return paths tend to surface as timeouts, which send people to application logs that show nothing. Checking the path in both directions first saves time.

Where this goes next

Today's release covers public traffic reaching private origins. The next target is private-to-private traffic: users, services and AI agents on one private network reaching applications on another through Cloudflare's application services. Engineering work is underway, and Cloudflare is aiming for a closed beta in early 2027. Interested teams should talk to their account team.

The use cases are easy to picture. An employee opening an internal wiki could get rate limiting and bot management in front of it. Service-to-service calls between clouds and data centers could use the same controls even when neither side touches the public internet. Neither scenario is in production yet, and the private-to-private design is still ahead of its beta. Still, it's the direction that makes the current release more than a convenience for exposing a few APIs.

For now, the practical takeaway is narrower and still valuable. If you already run a private connection to your origins and you've been avoiding public exposure just to get WAF and caching in front of them, that trade-off is now optional. Confirm the entitlement, set up the return route if you're on WAN or Mesh, and check the limitations list against your failover design before you move anything.