Cloudflare Puts WAF and Workers in Front of Origins That Keep a Private IP

TL;DR

• Cloudflare services for private origins is a capability that places Cloudflare's application services — WAF and managed rules, bot management, rate limiting, caching and Workers — in front of a server that keeps a private IP address.
• Cloudflare announced general availability on 30 October 2026, after a closed beta that started in June 2026.
• The mechanism is one DNS attribute: a proxied A or AAAA record points at a private address, and the proxy hands the request to Cloudflare's private networking layer over the Cloudflare One connection the account already runs.
• The operational weight moves to DNS permissions, because a record that used to publish a public address now exposes an internal service to internet traffic.
• The return route for Cloudflare's own source ranges is the setup failure the beta saw most often: requests time out and nothing arrives at the origin.
• What general availability leaves open: Argo Smart Routing and dedicated egress IPs stay unsupported, origin health checks need Load Balancing, and the developer documentation still carries a beta label.

On 30 October 2026, Cloudflare published Cloudflare services for private origins is now generally available, signed by Enrique Somoza. The post opens with the whole mechanism in one sentence: "Point a proxied DNS record at a private IP, and Cloudflare reaches the origin over your existing Cloudflare One connection." A beta that began in June 2026 is now open to any account with the entitlement.

The reason the company gives for building it is the one worth keeping: internal APIs, AI agent backends, MCP servers and operational tools were never built to face the internet, yet they still have to answer requests from partners, customers and agents that arrive from the internet. Before this release, putting Cloudflare in front of those services meant a public IP, an inbound firewall port, or a connector process running next to the application.

The DNS record became the control surface

A proxied A or AAAA record can now carry an address from the private ranges. For supported ranges the private network routing setting turns on automatically, and it covers RFC 1918 IPv4 addresses, RFC 6598 carrier-grade NAT addresses in 100.64.0.0/10, and RFC 4193 unique local IPv6 addresses in fc00::/7. On those ranges the setting cannot be switched off, and an API call that tries returns an error.

Behind the record, the proxy asks Cloudflare's Origin API where to send the request and receives metadata that includes a private routing flag. That flag is the branch point. The proxy hands the connection to the private networking layer, which routes it across connectivity the customer already operates.

The rest of the request path stays where it was. TLS terminates on Cloudflare's network, the WAF and the rules run there, and caching behaves as it does for a public origin. Nothing about the application changes.

What the edge does before the request enters the private network

The list of services that work on a private origin is the list that used to require a public address: WAF and managed rules, bot management, rate limiting, caching, transform and rewrite rules, and Workers. A team that wanted those controls over an internal application previously had two options, and both of them exposed something — a firewall hole with a narrower rule set, or a public hostname with no edge protection at all.

Cloudflare's own limits are worth reading before planning anything. Argo Smart Routing and Dedicated CDN Egress IPs are not supported on private origins, and origin health checks require Load Balancing. Unified Routing has to be enabled on the account, with one exception: the connector path does not need it.

Where the connector lives decides the deployment shape

Cloudflare WAN needs no connector software on the origin. Cloudflare Mesh runs a connector inside the private network, and that connector can serve several origins. The remaining paths are IPsec, GRE, CNI, and the connector Cloudflare calls Tunnel. This is the part of the design that differs most between two companies with the same requirement, because the connector location determines what fails when a route is wrong.

Take a concrete hypothetical case. Imagine a logistics company with a dispatch API that only its own drivers and warehouse scanners call. That API has never had a public address. Under this model the company publishes a hostname, points it at the API's private address, and gains the WAF and the rate limiting it never had, while the API keeps the address it always had.

One DNS write now decides who can reach an internal service

Here is the part of the announcement that deserves a second read. Exposure of an internal service used to be a firewall change, reviewed by whoever owns the network. It is now a DNS record, written through an API call that adds a private routing attribute to a standard record.

The permission boundary moved with it. Anyone who can create or modify proxied records in a zone, and who knows a private address inside a connected network, can put an internal service behind a public hostname. The WAF in front of that service is a real control, and it arrives after the decision to be reachable has already been taken. Inventories of internal services and the people who can publish hostnames belong in the same review, and in most companies they currently sit in two different teams.

That inventory question is the same one sovereign infrastructure and cloud exit work starts from: knowing what you expose, to whom, before a migration forces the answer.

The return route is where this breaks

Cloudflare names the failure mode it saw most during the beta. If requests time out and nothing reaches the origin, the return route is missing: traffic has to be able to come back toward Cloudflare's source ranges, 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6, whenever the connection is Cloudflare WAN or Cloudflare Mesh.

This is a routing problem with a quiet symptom. The forward path works, the DNS record resolves, the WAF evaluates the request, and the origin never sees a packet. Diagnostics that start at the application will find nothing, because the application was never reached.

What general availability leaves open

Two documents disagree today. The announcement says generally available. The documentation page is titled "Private origins (beta)" and still carries that beta label. A reader planning a production dependency should treat the beta label as current until the documentation page changes, and confirm the entitlement and the routing prerequisites with the account team, and read the blog post as the announcement.

The roadmap points at private-to-private traffic next: users, services and agents on one private network reaching applications on another through Cloudflare's application services, with a closed beta targeted for early 2027.

For a team deciding whether to move an internal API behind a private origin this quarter, the test is narrow. Publish one non-critical internal service, confirm the return route from the origin's own routing table, check that the WAF logs arrive with the hostname attached, and keep the DNS write permission away from anyone who cannot also read the internal service inventory.

Sources

• Cloudflare, "Cloudflare services for private origins is now generally available", Enrique Somoza, 30 October 2026 — https://blog.cloudflare.com/private-origins-public-to-private/
• Cloudflare Developer Documentation, "Private origins (beta)" — https://developers.cloudflare.com/dns/private-origins/

Source: Cloudflare, "Cloudflare services for private origins is now generally available", blog.cloudflare.com, 30 October 2026.