What changed
On October 30, 2026, Cloudflare announced general availability of application services for private origins after a closed beta launched in June. An eligible customer can create a proxied A or AAAA DNS record pointing at an RFC1918/CGNAT/unique-local private IP and route HTTP(S) requests through an existing Cloudflare One connection instead of publicly exposing the origin. Cloudflare WAF, bot management, rate limiting, caching, rewrite/transform rules and Workers remain available. The DNS API adds private_routing on standard records. The release is GA in Cloudflare's announcement, but entitlement and Unified Routing must still be enabled through an account team; an older documentation page still displays a beta label.
Why it matters
Private APIs, internal web applications, MCP servers and agent backends sometimes need to accept external traffic without making their origin directly internet-reachable. This architecture allows Cloudflare's public-facing application controls to protect a private destination, reducing the need for public origin addresses, open inbound firewall ports or separate cloudflared instances on every origin when WAN/Mesh connectivity already exists. It is not a substitute for application authentication, private-network design or routing validation, and the account-level prerequisites mean small self-hosters cannot assume access.
Public hostname, private destination
Create a proxied A/AAAA record for the service and enable private network routing. Cloudflare's edge terminates TLS and applies configured WAF, rate limits, bot controls, cache and Workers before handing traffic to its private networking layer. The origin remains on a private address. For RFC1918 IPv4, RFC6598 CGNAT and RFC4193 IPv6, Cloudflare automatically enables private routing and does not allow it to be disabled on those records.
Existing Cloudflare One network connectivity is mandatory
Cloudflare supports IPsec, GRE, Cloudflare Network Interconnect, Cloudflare Tunnel and Mesh paths. Customers need Private Origins entitlement and Unified Routing. For WAN or Mesh, a return route for Cloudflare source ranges must be present; the company says missing return routes were the most common beta setup failure. These prerequisites make the feature different from simply enabling the orange-cloud DNS proxy.
Feature boundaries and cost uncertainty
Cloudflare states that Argo Smart Routing and Aegis are not supported; origin health checks require Load Balancing. Its documentation labels Private Origins enterprise-only and its October 30 blog instructs customers to request account-team enablement. The announcement does not provide a general self-service price or promise that every Cloudflare plan can use it. Builders should verify contract, traffic, load-balancer and tunnel costs before designing around the feature.
How it differs from Cloudflare Tunnel and Unified Routing
Cloudflare Tunnel already offers a way to publish private services without inbound ports. The new GA path integrates a private IP directly into proxied DNS/application services across existing Cloudflare One on-ramps, including WAN/Mesh deployments where no connector runs on the origin. Unified Routing, covered separately by BTN, is the routing prerequisite rather than the same product launch.
Operational test plan
Verify the entitlement and Unified Routing mode, create a test private origin, confirm the proxied record's private_routing flag, then test HTTPS, application authentication, WAF, cache behaviour and return routing. Check timeouts, private address collisions and load-balancer health checks before migrating production services. Avoid treating Cloudflare edge controls as permission to expose an unauthenticated internal API.