Summary: On October 30, 2026, Cloudflare announced that services for private origins is generally available, after a closed beta that started in June. You can now point a proxied A or AAAA record at a private IP and Cloudflare routes traffic over your existing Cloudflare One connection — no public IP, no open firewall port. For anyone shipping internal APIs, AI agent backends, or MCP servers, this means the same WAF, caching, and bot management you use on public apps finally applies to private ones.
The problem it solves
Cloudflare’s beta post says customers kept hitting the same wall: internal services weren’t built to face the Internet, but partners, customers, or agents still needed to reach them. Before this feature, putting Cloudflare in front of such a service meant exposing a public IP, opening a firewall port, or running cloudflared next to the origin. That left private applications without the protections they’d get as public apps — WAF, managed rules, rate limiting, caching, rewrites, Workers.
If you’ve read my earlier piece on securing internal apps on Cloudflare Workers, this is the other half of that story: the network path, not just the access layer.
What GA includes — and what doesn’t
The full stack of application services works as it would for a public origin: WAF and managed rules, bot management, rate limiting, caching, transform and rewrite rules, and Workers. Your origin keeps its private IP with no inbound firewall exception.
A few gaps remain: no Argo Smart Routing, no Dedicated CDN Egress IPs, and origin health checks require Load Balancing. Check the developer documentation for the current list before you plan a migration around it.
The mechanics are a single DNS flag
Setup is refreshingly small. Private routing turns on automatically for RFC 1918 IPv4, CGNAT (100.64.0.0/10), and RFC 4193 IPv6 ULA ranges — and it can’t be turned off for those ranges; API attempts to disable it return an error. Under the hood, the proxy sees a private_routing flag on the DNS record and hands the request to Cloudflare’s private networking layer, which routes over IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.
If you connect via Cloudflare WAN or Mesh, configure a return route for Cloudflare’s source ranges (100.64.0.0/12 for IPv4, 2606:4700:cf1:5000::/64 for IPv6). One practical note from the beta: if requests time out and nothing arrives at the origin, a missing return route was the most common failure. Check that first.
Prerequisites: the Private Origins entitlement (via your account team), Cloudflare One connectivity in one of the supported forms, and Unified Routing enabled unless you use Cloudflare Tunnel.
Why this matters for agent backends
The beta framing explicitly called out AI agent backends and MCP servers as the motivating use case. Agents increasingly need to call services that should never be Internet-facing, yet they need edge controls — rate limiting in particular — when those services accept external requests. This feature makes that combination a DNS record instead of an infrastructure project.
What’s next
This release covers public-to-private traffic. Private-to-private — users, services, and agents on one private network reaching apps on another through Cloudflare’s application services — is targeted for a closed beta in early 2027. If your architecture spans clouds and data centers where neither side touches the public Internet, that’s the piece to watch.
For now, the practical step is simple: ask your account team for the entitlement, wire up your Cloudflare One connection, and move one low-risk internal service behind a proxied private record to validate your return routes before committing anything production-critical.