Cloudflare now protects servers with private IPs: WAF, cache, and Workers without opening a single port

On October 30, 2026, Cloudflare announced the general availability of Cloudflare services for private origins: you can now create a proxied DNS record (the orange cloud) that points to a private IP, like 10.0.0.50, and Cloudflare reaches that server through the private connection you already have with its network, not over the Internet. The origin stays without a public IP and without an open port, but it gets the same WAF, cache, bot management, rate limiting, and Workers as any public site. For anyone with internal APIs, AI agent backends, or MCP servers that need to receive traffic from the outside, this matters: it removes the excuse of "we don't protect this because it's not on the Internet." That said, it's not a switch for everyone, and that's where the fine print comes in.

What problem it solves

Cloudflare explains it like this in its announcement: many internal APIs, agent backends, MCP servers, and operational tools "were not built to face the Internet," but they still have to accept requests from partners, customers, or agents. Before, putting Cloudflare in front of those services meant one of three things: exposing a public IP, opening a port on the firewall, or running cloudflared (the Cloudflare Tunnel connector) next to the origin.

The consequence, according to the company itself, was that those private applications were left without the protections that public ones had. My take: it's the usual infrastructure pattern. Public stuff gets hardened because everyone sees it; internal stuff gets "hey, nobody knows about it anyway," until someone does.

The feature launched in closed beta in June for eligible Enterprise customers, and at that time Cloudflare set general availability in the fourth quarter of 2026 as its goal. It kept to the schedule.

How it works

The trick is in the last hop. Everything else stays the same: TLS termination, the WAF, rules, and cache run on Cloudflare's network as always. The difference is that, instead of trying to connect to the origin's IP over the public Internet, the proxy hands the request to Cloudflare's private network layer, which routes it through the connectivity the customer already operates: IPsec or GRE tunnels, CNI (direct interconnect), Cloudflare Tunnel, or Cloudflare Mesh.

Before and after diagram: before, the origin needed a public IP or open port; now Cloudflare reaches the private IP through IPsec, GRE, CNI, Tunnel, or Mesh

In DNS, it's turned on with the Use private network routing option on a proxied A or AAAA record. For these ranges it turns on by itself and can't be turned off:

10.0.0.0/8, 172.16.0.0/12, and 192.168.0.0/16 (private, RFC 1918).
100.64.0.0/10 (CGNAT, RFC 6598).
fc00::/7 (IPv6 unique local, RFC 4193).

If your origin has a public IP that is only reachable through your private network, you can turn it on manually. The documentation adds a detail that can bite: the option applies per name, not per record. If you have several A or AAAA records with the same name and only one has private routing enabled, all of them use it.

The change automation folks should notice

In the API, private routing is just another attribute of the DNS record. Here's something worth checking if you already had scripts from the beta: in the June announcement the field was called use_private_routing, and in the general availability announcement and the current documentation it's called private_routing.

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

According to the documentation, on a proxied record with a private IP the value is set to true on its own; with a public IP it defaults to false; on record types other than A or AAAA the field doesn't exist. And if you send private_routing: false on a proxied record with a private IP, the API responds with an error. I didn't test it; this comes from Cloudflare's official documentation.

What works and what doesn't

Works the same as with a public origin	Not supported or has conditions
WAF and managed rules	Argo Smart Routing (not supported)
Bot management	Dedicated CDN egress IPs (not supported)
Rate limiting	Origin health checks (only with Load Balancing)
Cache	Records other than A or AAAA
Transform and rewrite rules	Unproxied records
Workers

Cloudflare points to its documentation for the full list of limitations.

What you need to use it

Here's the fine print. Cloudflare says it's opening access today "beyond" the beta group, but the requirements it publishes are:

Your account must have the Private Origins entitlement. You ask your Cloudflare account team for it.
Cloudflare One connectivity via IPsec, GRE, CNI, Cloudflare Tunnel, or Cloudflare Mesh.
Unified Routing enabled on the account, unless you connect through Cloudflare Tunnel, which doesn't need it.
If you connect through Cloudflare WAN or Mesh, a return route for Cloudflare's origin ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6.

With Cloudflare WAN you don't need connector software at the origin; with Mesh, a connector runs inside your private network and can serve several origins.

Heads-up on one detail: at the time of writing, the main Private Origins documentation page still says "beta" and "Enterprise-only," with an update date of May 7, 2026, and the general availability announcement doesn't clarify whether that has changed. My take: if you're on a Free or Pro plan, this isn't a button you'll find in the dashboard tomorrow. If you proxy a private IP without the entitlement, the documentation says you get error 1002 ("DNS points to prohibited IP").

The most common beta mistake

Cloudflare shared a lesson from the beta: if requests time out and nothing reaches the origin, check the return route first. A missing route to Cloudflare's origin range was the most frequent configuration error they saw. The troubleshooting guide adds two other typical cases: timeouts because Cloudflare's origin IP is configured in a public range (it needs to be set in a private /12) and traffic trying to go out over the Internet because the record doesn't have private routing enabled.

What's next

This release covers public-to-private traffic. Next on Cloudflare's plan is private-to-private: users, services, and AI agents on private networks reaching applications on other private networks, going through the same application services. The company is aiming for a closed beta in early 2027. Its example: an employee opening wiki.company.internal with WAF, rate limiting, and bot management, as if it were a public API.

What this means

My read is that Cloudflare is erasing the line between "what sits behind the CDN" and "what sits behind the VPN." For teams already paying for Cloudflare WAN or Mesh, it's a direct win: they reuse tunnels they already have to bring WAF and cache to internal services without opening anything. For everyone else, the practical message is different: if today you expose an internal service with a public IP and an allowlist of IPs, that model keeps working, but the direction of the industry is for the origin to not even have a public face. And with AI agents consuming internal APIs more and more, having a WAF and a rate limit in front of that MCP that "nobody knows about" stops being a luxury.