Cloudflare Services for Private Origins Go GA: WAF, Caching and Workers Reach MCP Servers Without a Public IP
Cloudflare's services for private origins are GA: a proxied DNS record can point an MCP server at a private IP while WAF, caching, bot management and Workers still apply.
Cloudflare’s edge now reaches origins that never touch the public internet. In a post published Oct. 30, 2026, the company declared services for private origins generally available: point a proxied A or AAAA record at a private IP, and Cloudflare delivers the traffic over your existing Cloudflare One connection. The origin keeps its private address with no inbound firewall exception, while WAF, caching, bot management and Workers behave as they do for any public hostname. The blog index credits the announcement to Enrique Somoza and sums it up as public traffic to private origins for every customer with Cloudflare One connectivity.
Why the beta existed: agent backends and MCP servers
Cloudflare framed the capability around a specific, repeating customer complaint. Internal APIs, AI agent backends, MCP servers and operational tools were not built to face the internet, yet they still need to accept requests from partners, customers or agents over it. Before the June closed beta, putting Cloudflare in front of those services meant one of three compromises: expose a public IP, open a firewall port, or run cloudflared alongside the origin. Each left the private application without the protections its public siblings got by default — WAF, bot management, rate limiting, caching, traffic acceleration, rewrites and Workers.
That names the audience here directly. Teams exposing MCP servers to outside agents have had to choose between a public attack surface and a connector process pinned to every origin — the exposure problem that our MCP hardening runbook treats as given. Cloudflare’s WebMCP rollout across nearly 100,000 Commerce.com storefronts pushes from the publisher side; private origins pushes from the infrastructure side.
What general availability includes
During the closed beta, eligible customers had to request access through their account team; Cloudflare is now opening the capability beyond that group. A proxied record pointed at a private IP gets the public-origin treatment:
| Service | Status at GA |
|---|---|
| WAF and managed rules | Included |
| Bot management | Included |
| Rate limiting | Included |
| Caching | Included |
| Transform and rewrite rules | Included |
| Workers | Included |
| Argo Smart Routing | Not supported |
| Dedicated CDN Egress IPs | Not supported |
| Origin health checks | Require Load Balancing |
Cloudflare defers the full limitation list to its developer documentation. Two rows matter for planning: if you monitor origins with Cloudflare health checks, Load Balancing becomes part of the deployment, and anyone relying on Dedicated CDN Egress IPs for origin allowlisting should not expect them here — though a private origin needs no inbound firewall exception in the first place.
How a request reaches a private IP
The mechanism is a flag on a DNS record. Private network routing switches on automatically when a proxied record targets an RFC 1918 IPv4 address, an RFC 6598 CGNAT address (100.64.0.0/10) or an RFC 4193 unique-local IPv6 address (fc00::/7) — and it cannot be turned off for those ranges; attempts through the API return an error. Origins on public IPs reachable only through the private network can enable the setting manually.
Behind the scenes, Cloudflare’s proxy platform asks its Origin API where to send traffic for the hostname and reads back a private_routing flag. Instead of dialing the private IP over the public internet, the proxy hands the connection to the private networking layer, which routes it across IPsec, GRE, Cloudflare Tunnel, CNI or Cloudflare Mesh. TLS termination, WAF, rules and caching still run on Cloudflare’s network.
For API-driven deployments, private routing is one attribute on an otherwise ordinary record:
POST /zones/{zone_id}/dns_records
{
"type": "A",
"name": "app.example.com",
"content": "10.0.0.50",
"ttl": 300,
"proxied": true,
"private_routing": true
}
Setup: entitlement first, then the return route
The blog index calls this available to every customer with Cloudflare One connectivity; the post itself still lists gates. You need the Private Origins entitlement enabled by your account team, one of five connectivity types — IPsec, GRE, CNI, Cloudflare Tunnel or Cloudflare Mesh — and Unified Routing on the account unless you connect over Cloudflare Tunnel, which does not need it. New and existing accounts upgrade Unified Routing through the account team as well. Cloudflare One is the platform those connections ride on: Tunnel makes outbound-only connections from your infrastructure via cloudflared, and Mesh links private networks over post-quantum-encrypted nodes.
If you connect over Cloudflare WAN or Mesh, configure a return route for Cloudflare’s source ranges: 100.64.0.0/12 for IPv4 and 2606:4700:cf1:5000::/64 for IPv6. Cloudflare called out the beta’s failure mode explicitly — if requests time out and nothing arrives at the origin, check the return route first, because a missing route for Cloudflare’s source range was the most common setup failure it saw. Note the two similar-looking ranges: 100.64.0.0/10 triggers private routing on a DNS record, while 100.64.0.0/12 is the source range your network must route back to Cloudflare.
Announcement versus availability
The gap between the headline and the get-started list is the usual enterprise shape: GA opens access beyond the beta group, but enablement still runs through account teams, both for the entitlement and for Unified Routing. Plan on that conversation before the first proxied private record resolves, and treat the developer documentation as the source of truth for current limitations.
What comes next: private-to-private
Today’s release covers public traffic reaching private origins. Cloudflare says private-to-private traffic — users, services and AI agents on one private network reaching applications on another — is in engineering now, with a closed beta targeted for early 2027. The stated goal is symmetric treatment: an employee opening wiki.company.internal should get WAF, rate limiting and bot management, and so should service-to-service traffic between clouds and data centers, even when neither side touches the public internet.
Operator takeaways
- Inventory the MCP servers, agent backends and internal APIs currently fronted by a public IP, an opened firewall port or a cloudflared sidecar — each is now a candidate for a proxied private record.
- Start the entitlement and Unified Routing conversation with your Cloudflare account team early; GA removes the beta waitlist, not the enablement step.
- Add a return-route check to the runbook before the first test. Timeouts with a silent origin mean Cloudflare’s source ranges are probably not routed back.
- Budget for the gaps: no Argo Smart Routing, no Dedicated CDN Egress IPs, and health checks only through Load Balancing.
The edge services you already run against public hostnames now apply to origins that were never meant to be public. For agent-backend operators, that is the trade this release actually offers: keep the origin invisible, keep the controls.
