SERVERBORNForged for speed
Blog · Hosting

Cloudflare Brings WAF, Caching, and Bot Management to Private Origins

Hosting

Cloudflare announced that its services for private origins capability is now generally available, extending WAF, caching, bot management, and Workers to origins that never need to expose a public IP address. The feature moved out of closed beta after launching in June, when it was limited to customers who requested access through their account teams.

The core idea: point a proxied A or AAAA DNS record at a private IP, and Cloudflare reaches that origin over existing Cloudflare One connectivity rather than the public Internet. The origin stays private, but Cloudflare’s edge still terminates TLS and runs the same application services used for public sites.

Why it matters

Cloudflare said the feature addresses a recurring customer problem: internal APIs, AI agent backends, MCP servers, and operational tools were never designed to face the Internet, yet still need to accept external requests from partners or customers. Previously, putting Cloudflare in front of these services required exposing a public IP, opening a firewall port, or running cloudflared alongside the origin, often leaving private applications without the WAF, bot management, rate limiting, caching, and rewrite protections available to public apps.

What’s supported

  • WAF and managed rules
  • Bot management
  • Rate limiting
  • Caching
  • Transform and rewrite rules
  • Workers

Argo Smart Routing, Dedicated CDN Egress IPs, and origin health checks (which require Load Balancing) are not yet supported. Cloudflare’s developer documentation lists the full current limitations.

How it works

Private network routing 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 it cannot be disabled for these ranges via the API. For public IPs reachable only through a private network, the setting can be enabled manually. The DNS record API simply gains a private_routing attribute; Cloudflare’s proxy platform queries an internal Origin API to determine whether to route a connection over IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh instead of the open Internet.

Getting started

Access requires the Private Origins entitlement (enabled by an account team), Cloudflare One connectivity, and in most cases Unified Routing (Cloudflare Tunnel is exempt). Customers connecting via Cloudflare WAN or Mesh must 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 noted that a missing return route was the most common setup failure during the beta, causing requests to time out silently.

What’s next

Cloudflare said this release covers public traffic reaching private origins, and it is now working on private-to-private traffic, allowing users, services, and AI agents on one private network to reach applications on another through Cloudflare’s application services. A closed beta for that capability is targeted for early 2027.