Cloudflare Private Origins now generally available for internet-facing private apps

What's launching

Cloudflare's private origins feature exits closed beta today as generally available to all customers. The capability allows you to create a proxied DNS record pointing to a private IP address, and Cloudflare routes traffic to that origin through your existing Cloudflare One private network connection—whether via IPsec, GRE, Tunnel, CNI, or Cloudflare Mesh. The origin keeps its private IP with no required firewall changes.

Features and limitations

All standard Cloudflare application services apply to private origins: WAF and managed rules, bot management, rate limiting, caching, transform and rewrite rules, and Workers. TLS termination and rules processing happen on Cloudflare's edge network as usual.

Some features are not yet supported. Argo Smart Routing and Dedicated CDN Egress IPs do not work with private origins. Origin health checks require Load Balancing. If you use Cloudflare WAN, no connector software must run on the origin itself. With Cloudflare Mesh, a connector runs within your private network and can serve multiple origins.

How to set it up

Create a proxied A or AAAA record pointing to your private IP. For RFC 1918 private IPv4 addresses, RFC 6598 CGNAT addresses (100.64.0.0/10), and RFC 4193 unique local IPv6 addresses (fc00::/7), private network routing enables automatically and cannot be disabled through the API.

Before you start, your account needs the Private Origins entitlement and Cloudflare One connectivity. Unified Routing must be enabled on your account unless you connect over Cloudflare Tunnel. If using 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 your proxied record with private network routing confirmed as enabled. Your existing WAF, cache, and bot management settings apply automatically.

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

Why this matters

Before this launch, protecting internal APIs, AI agent backends, MCP servers, and operational tools with Cloudflare meant exposing a public IP, opening a firewall port, or running cloudflared as a sidecar. Each approach left these services without the same protections available to public applications. Private origins eliminate that trade-off: customers can now apply WAF, bot management, rate limiting, and caching to internet-facing private applications without changing their network architecture.

What comes next

Cloudflare is working on private-to-private traffic support, which would let users, services, and AI agents on private networks reach applications on other private networks through Cloudflare's application services. Engineering is underway and a closed beta is targeted for early 2027. The goal is to extend WAF, rate limiting, bot management, and other protections to internal service-to-service traffic and private employee access, even when neither endpoint touches the public internet.

Source

AI-assisted, verified against the source. This post was drafted with AI from the primary source linked above and checked automatically against it. For anything you depend on, read the original.