On 2026-06-10, Cloudflare announced Application Services for Private Origins, a closed beta for eligible Enterprise customers that lets a proxied DNS record resolve a public hostname to a private RFC 1918 address and still serve live traffic. The final hop runs through the customer’s existing Cloudflare One private connectivity instead of the public Internet, removing the need for a public IP or a VPN tunnel. The DNS flag routes; it does not authenticate.
What changes when a public hostname points at a private origin
The launch lets a proxied DNS record resolve a public hostname to a private RFC 1918 origin and still serve live traffic, where previously that combination required a Cloudflare Tunnel and a cloudflared process on the origin. Before this, pointing a public hostname at a private 10.x or 192.168.x address meant the DNS record either stayed unproxied (DNS-only, no edge controls) or required a tunnel plus a cloudflared daemon living on the origin. The new toggle collapses those into one step: a proxied A/AAAA record carries traffic from Cloudflare’s edge all the way to a private address, with the WAF, rate limiting, caching, bot management, transform rules, and Workers running in front of it, Cloudflare says.
Access today is limited to eligible Enterprise accounts in closed beta. Cloudflare frames the motivation in its own words: “security should be a property of the traffic reaching an application, not an accident of where the application happens to sit,” explicitly naming internal APIs, AI agent backends, and MCP servers as the workloads it is built for. The framing is that the security posture follows the traffic rather than depending on network topology: an origin on a private subnet picks up edge-grade controls without first being published to the public Internet.
The practical savings are concrete. The components this removes from the operator’s plate are a publicly routable IP allocation, a cloudflared process to run and keep patched on the origin, and, in many setups, a public-facing load balancer or reverse proxy whose only job was to terminate traffic before forwarding it inside. What it does not remove is the private connectivity itself, which is a prerequisite rather than something the feature provisions.
How the private_routing toggle works and what it requires
The feature is a single attribute on the DNS record: private_routing in the API, “Use private network routing” in the dashboard. When the proxy sees it, the request is handed to Cloudflare’s private networking layer across Cloudflare Tunnel, Cloudflare WAN IPsec, or Cloudflare Mesh, according to Cloudflare’s blog.
The toggle auto-enables for addresses in RFC 1918 space (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16), RFC 6598 CGNAT (100.64.0.0/10), and RFC 4193 (fc00::/7). Manually setting the flag to false on a proxied A/AAAA record that points at a private IP returns an API error, Cloudflare’s DNS docs note: you cannot opt out of private routing for a private address while keeping the proxy on. The auto-detection is by address class, not by operator intent.
Setup is not self-contained. It requires an active tunnel connection to Cloudflare through one of the supported on-ramp methods, such as Cloudflare WAN IPsec or Cloudflare Mesh, Cloudflare’s DNS docs note. This builds on top of private connectivity the customer already has; it does not provision the tunnel itself. Teams without existing Cloudflare One connectivity will not find a shortcut here.
Does the edge WAF replace origin authentication?
No. Private-origins DNS routing adds routing, not identity. The WAF, rate limiting, and bot management that run at the edge are traffic controls; checking who the caller is requires a separate Cloudflare Access policy layered on top, and even then the origin is not automatically safe.
Cloudflare’s own documentation for publishing a self-hosted application warns that origin security depends on validating the Access application token, because requests that bypass Cloudflare Access (for example, through a network misconfiguration) must be rejected at the origin, per the Cloudflare One docs. The edge is, in Cloudflare’s own framing, bypassable. The docs treat origin-side token validation as the mechanism that makes a bypass survivable rather than catastrophic.
Read literally, the feature protects the origin from the public Internet’s noise but does not authenticate callers. Authentication is a separate Access layer the operator must configure, and the two pieces are independent: routing decides where the packet goes, Access decides who may send it, and only the operator wires them together. An origin that serves any request it receives will serve a request that slipped past the edge.
Tailscale and WireGuard: mesh overlay or single-vendor edge?
The architectural choice is between a peer-to-peer, end-to-end-encrypted mesh and a centrally proxied edge. Tailscale’s own comparison page is predictably partial but technically specific. It argues Cloudflare Access offers no end-to-end encryption because the edge terminates TLS and can inspect traffic, routes all traffic through a centrally managed proxy rather than a peer-to-peer mesh, and is not a mesh VPN, per Tailscale.
The same comparison notes Cloudflare Access SSO is only available on Enterprise plans, while Tailscale integrates identity providers (Google, Azure AD, GitHub, Okta, OneLogin) on free and personal tiers. For a team already running a Tailscale or WireGuard overlay, the question is whether offloading name resolution and TLS termination to Cloudflare’s edge is worth depending on a single vendor for both the DNS record and the private path that record resolves to.
| Dimension | Cloudflare (Private Origins + Access) | Tailscale |
|---|---|---|
| TLS / encryption | Edge terminates TLS; no end-to-end encryption, per Tailscale | End-to-end encrypted, peer-to-peer |
| Traffic routing | Centrally managed edge proxy | Peer-to-peer mesh, not a vendor proxy |
| SSO availability | Enterprise plans only | Google, Azure AD, GitHub, Okta, OneLogin on free/personal tiers |
| Hostname model | Public hostname resolves to a private origin via DNS | Overlay addressing; no public hostname required |
The Tailscale column above reflects Tailscale’s own claims, not an independent measurement; treat the encryption and routing assertions as a vendor’s self-assessment, and the Cloudflare column as Cloudflare’s docs read alongside that comparison. The honest reading is that the two products optimize for different things: Cloudflare optimizes for a public hostname fronted by edge controls, Tailscale for a private address space reachable only by authenticated mesh members. They overlap on “reach a private service from outside” and diverge on everything else, including who holds the keys and whether a public name is involved at all.
What fails open when the edge is the only gate?
When the edge WAF and Access policy are the only thing standing between the public Internet and an unauthenticated origin, the failure modes concentrate on that edge. A network misconfiguration that lets a request bypass Cloudflare Access reaches an origin that, absent its own token validation, will simply serve it.
This is the tradeoff the launch marketing does not foreground. Moving both name resolution and authorization onto one vendor’s edge simplifies operations but concentrates the trust boundary there, and Cloudflare’s own documentation treats origin-side token validation as mandatory precisely because the edge is bypassable. Read literally, “no VPN” means the proxying function has moved from an overlay the customer controls to an edge Cloudflare controls; Tailscale’s comparison makes the argument explicitly, framing Cloudflare’s centrally proxied traffic as functionally a VPN operated by the vendor.
The single-vendor dependency cuts both ways. Consolidating DNS resolution, TLS termination, the private transport, and the access policy onto one platform reduces the number of moving parts an operator has to stitch together, and Cloudflare’s edge controls are, on paper, stronger than what most teams build for themselves in front of an internal service. The cost is that the same vendor now mediates name resolution, encryption termination, the private path, and identity, so a misconfiguration or outage in any one of those layers can expose or deny the application wholesale. A mesh overlay spreads those functions across the customer’s own infrastructure and the identity provider, at the price of more operational surface to maintain.
For practitioners, the durable takeaway is older than this beta: the origin is the last line of defense, not the first. Private-origins DNS routing makes it cheaper to expose an internal service and put strong traffic controls in front of it, which is useful and worth evaluating once it reaches general availability. It does not remove the obligation to make the origin reject what it should reject, and it does not change which party terminates the connection. As of 2026-06-23, the responsible configuration is private routing plus Access plus origin-side token validation, not private routing alone.
Frequently Asked Questions
Does private-origins routing extend to non-HTTP protocols like raw TCP and UDP?
Spectrum can front TCP/UDP services on private IPs by setting a virtual_network_id on the origin, and Workers VPC bindings route outbound calls through the same private path. At launch the Spectrum path is Cloudflare Tunnel only, and the API rejects any origin IP that doesn’t match a Tunnel route.
What must already be running in the customer network before this flag does anything?
An active Cloudflare One on-ramp (IPsec, GRE, CNI, or Mesh) plus a return route inside the private network for Cloudflare’s source range 100.64.0.0/12, so responses can climb back to the edge. The flag selects a path through connectivity that already exists; it provisions none of it.
How does Cloudflare’s return-traffic source range interact with the CGNAT auto-detect?
Cloudflare’s source range for return traffic is 100.64.0.0/12, which sits inside the 100.64.0.0/10 CGNAT band that auto-triggers private routing. A network already using CGNAT space for its own purposes has to install a return route for that /12 to Cloudflare without colliding with its existing numbering.
When can teams outside Enterprise actually adopt private-origins DNS routing?
Cloudflare’s stated target is general availability in Q4 2026, with the current closed beta limited to eligible Enterprise accounts. The company has not published pricing or which tiers and on-ramps will ship at GA, so non-Enterprise teams have no confirmed date or cost to plan against.
