Key details

  1. GA announced October 30, 2026, following June closed beta.
  2. Proxied A/AAAA records can target private IPs over existing Cloudflare One connectivity.
  3. WAF, bot management, rate limiting, caching, transform rules and Workers apply to private origins.
  4. Automatic private routing for RFC1918, RFC6598 and RFC4193 addresses.
  5. Requires Private Origins entitlement and Unified Routing; supported on-ramps include IPsec, GRE, CNI, Tunnel and Mesh.
  6. Cloudflare says Argo Smart Routing and Aegis are unsupported; origin health checks require Load Balancing.
  7. No universal self-service price or availability was published in the GA announcement.

What builders should take away

  1. Do not expose a public origin IP just to add WAF or Workers if your account qualifies for Private Origins.
  2. Check entitlement and Cloudflare One connectivity before estimating migration effort.
  3. Verify return routes and health-check requirements with representative requests.
  4. Keep application-level authentication, authorisation and logging even behind Cloudflare.
  5. Compare this with a conventional Cloudflare Tunnel deployment rather than assuming it replaces all tunnel use cases.

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.

What to watch next

  • Whether Private Origins entitlement expands beyond account-team enablement and enterprise arrangements.
  • Documentation updates removing older closed-beta language.
  • Support for Argo, Aegis and more health-check options.
  • Planned private-to-private application services beta targeted for early 2027.

Still unclear

  • The GA blog and older documentation currently differ in status labels; announcement is the newer authority.
  • No general self-service pricing or plan matrix is supplied.
  • No independent production latency or reliability benchmarks were available at research time.
  • Private-to-private support remains a future plan, not current GA.

Sources

Direct reading behind this dossier.

3 sources
Private origins
Cloudflare Docs primary_documentation

Documents enterprise-only entitlement and setup; status label may lag October 30 GA announcement.

Private network routing
Cloudflare Docs primary_documentation

Routing semantics and proxied A/AAAA considerations.

Discussion

Discussion is reader-contributed. Comments are not part of the BTN dossier or its editorial evidence.

0 visible comments

Join the discussion

Keep comments useful and relevant. Reader contributions may be moderated and are not BTN editorial evidence.

Sign in to comment