Cloudflare has announced general availability of its private origins service, enabling customers to direct proxied DNS records toward private IP addresses while leveraging Cloudflare One connectivity to reach those backends. The service keeps origin infrastructure private while delivering web application firewall protections, caching, bot management, and Workers functionality—the same features available for publicly-facing applications.

The capability emerged from customer feedback gathered during a closed beta that launched in June. Organizations frequently operate internal APIs, AI agent backends, MCP servers, and operational tools that were never designed for internet-facing exposure, yet still require the ability to receive requests from external partners, customers, or autonomous agents. Previously, placing Cloudflare in front of such services required either exposing a public IP address, opening firewall ports, or running cloudflared on the origin itself—approaches that typically left private applications without the same security controls applied to public-facing services.

Without this capability, private applications frequently operated without access to WAF rules, bot management, rate limiting, caching, traffic acceleration, rewrite rules, and Workers—protections that organizations routinely deployed for public applications.

What is now available

The general availability release opens access beyond the closed beta participant group. Organizations can now point proxied A or AAAA records toward private IP addresses, and Cloudflare's application services function identically to their public-origin counterparts.

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

Some constraints persist in the current release. Argo Smart Routing and Dedicated CDN Egress IPs remain unsupported, and origin health checks require Load Balancing. The developer documentation details the complete list of current limitations.

Origins retain their private IP addresses without requiring inbound firewall exceptions. When using Cloudflare WAN, no connector software needs to run on the origin. With Cloudflare Mesh, a connector operates within the private network and can serve multiple origins.

How the service operates

Organizations create a proxied A or AAAA record that points to their origin. For supported private IP ranges, private network routing activates automatically. When an origin uses a public IP that is only reachable through a private network, the setting can be enabled manually.

The remainder of the request processing pipeline remains unchanged: TLS termination, WAF evaluation, rules execution, and caching all continue operating on Cloudflare's network infrastructure.

The setting enables 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). These ranges cannot be disabled; API attempts to turn off the setting for these ranges produce an error response.

API implementation

For teams automating infrastructure deployments through the API, private routing appears as an additional attribute on standard DNS records.

POST /zones/{zone_id}/dns_records
{
 "type": "A",
 "name": "app.example.com",
 "content": "10.0.0.50",
 "ttl": 300,
 "proxied": true,
 "private_routing": true
}

Internally, Cloudflare's proxy platform determines traffic routing for app.example.com by querying the Origin API. The response includes metadata signaling that the destination should be accessed through a private network path:

{
 "zone_name": "example.com",
 "ipv4_addresses": ["10.0.0.50"],
 "private_routing": true
}

The private_routing flag serves as the critical indicator. When the proxy detects this flag, instead of attempting a direct connection to the private IP over the public internet, it passes the request to the private networking layer, which routes the connection across the customer's existing private network infrastructure—whether that uses IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.

Getting started

  1. Enable the Private Origins entitlement on your account by requesting activation from your account team.
  2. Establish Cloudflare One connectivity using IPsec, GRE, CNI, Cloudflare Tunnel, or Cloudflare Mesh.
  3. Activate Unified Routing on your account, unless you connect via Cloudflare Tunnel (which does not require it). Both new and existing accounts can upgrade through their account team.
  4. If connecting through Cloudflare WAN or Cloudflare Mesh, 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 a proxied A or AAAA record for the private IP and verify that Use private network routing is enabled. Existing WAF, cache, and bot management configurations automatically apply to that hostname.

A note from the beta phase: if requests time out with nothing reaching the origin, verify the return route configuration first. Missing routes for Cloudflare's source range represented the most frequent setup issue encountered during testing.

The developer documentation provides a complete walkthrough of the setup process.

Future development

Today's release addresses public traffic reaching private origins. The next phase involves private-to-private traffic: users, services, and AI agents operating on private networks accessing applications on other private networks through Cloudflare's application services.

Engineering efforts are in progress, with a closed beta targeted for early 2027. Organizations interested in participating should contact their account team.

The broader objective is to extend the same protections and controls available to public applications toward private applications. An employee accessing wiki.company.internal, for instance, could benefit from WAF, rate limiting, and bot management. Service-to-service traffic between clouds and data centers could leverage these controls as well, even when neither endpoint connects to the public internet.

For the present, this release brings WAF, caching, bot management, and Workers capabilities—features already deployed for public applications—to private origins across connectivity infrastructure organizations already operate.