Cloudflare brings WAF, caching and Workers to origins on private IPs

What happened

On October 30, 2026, Cloudflare moved its services for private origins from closed beta to general availability, according to a post on the Cloudflare blog. The capability, first launched to a limited group in June, lets a proxied DNS record point at a private IP address; Cloudflare then reaches that origin through the customer's existing Cloudflare One connection rather than over the public Internet.

The result is that an origin keeps its private IP with no inbound firewall exception, while Cloudflare's application services behave as they would for any public hostname.

The problem it addresses

The Cloudflare blog describes a recurring customer situation: internal APIs, AI agent backends, MCP servers and operational tools were never built to face the Internet, yet still need to accept requests from partners, customers or agents arriving over it. Before the beta, putting Cloudflare in front of such services meant exposing a public IP, opening a firewall port, or running cloudflared alongside the origin. In practice, that often left private applications without the protections used for public ones, including the WAF, bot management, rate limiting, caching, traffic acceleration, rewrites and Workers.

What the release includes

According to Cloudflare, pointing a proxied A or AAAA record at a private IP now brings the following to that hostname:

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

Some limitations remain: Argo Smart Routing and Aegis are not supported, and origin health checks require Load Balancing. Cloudflare directs readers to its developer documentation for the full list.

How it works

For supported ranges, the "Use private network routing" setting turns on automatically. This covers RFC 1918 private IPv4 addresses, RFC 6598 CGNAT space (100.64.0.0/10) and RFC 4193 unique local IPv6 addresses (fc00::/7). The setting cannot be disabled for these ranges; attempts to turn it off through the API return an error. If an origin uses a public IP that is only reachable through a private network, the setting can be enabled manually.

TLS termination, WAF, rules and caching continue to run on Cloudflare's network as usual.

For automated deployments, private routing is an additional attribute on a standard DNS record: a private_routing flag on a proxied A or AAAA record. Behind the scenes, Cloudflare's proxy platform queries its Origin API to decide where traffic should go. When the response includes the private routing metadata, the proxy hands the request to the private networking layer instead of attempting a direct connection, and the traffic is routed across whatever private connectivity the customer already operates, whether IPsec, GRE, Cloudflare Tunnel, CNI or Cloudflare Mesh.

Setup requirements

Cloudflare lists three prerequisites: the Private Origins entitlement on the account, enabled through the account team; Cloudflare One connectivity using IPsec, GRE, CNI, Cloudflare Tunnel or Cloudflare Mesh; and Unified Routing enabled on the account, also via the account team.

Customers connecting over Cloudflare WAN or Cloudflare Mesh additionally need a return route for Cloudflare's source ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. The blog notes that a missing return route was the most common setup failure seen during the beta, so if requests time out and nothing arrives at the origin, that route is the first thing to check.

Once the record is in place, existing WAF, cache and bot management configuration applies to the hostname without further changes.

What comes next

This release covers public traffic reaching private origins. Cloudflare says engineering work is underway on private-to-private traffic: users, services and AI agents on private networks reaching applications on other private networks through the same application services, with a closed beta targeted for early 2027. The stated goal is parity between private and public applications. An employee opening an internal wiki, for example, could get WAF, rate limiting and bot management, and service-to-service traffic between clouds and data centers could use those controls even when neither side touches the public Internet.

Why it matters

The line between internal and internet-facing applications keeps blurring, driven in part by AI agents and MCP servers that outside callers need to reach. Until now, teams wanting Cloudflare's WAF or Workers in front of such services had to punch a hole somewhere: a public IP, a firewall port or a sidecar connector. Making private routing a property of an ordinary DNS record folds private origins into the same operational model as public ones, over connectivity teams already run. The account-level entitlements and Unified Routing requirement mean this is still an account-team conversation rather than a self-serve switch, and the planned private-to-private support signals a broader ambition: applying edge security controls across internal networks, not just at the edge of them.