This allows engineers to apply enterprise-grade security and performance tools like WAF and Workers to internal-only services without exposing them to the public internet. It simplifies architecture for internal APIs and AI backends while maintaining a strict zero-trust posture.
Today, Cloudflare services for private origins is generally available. Point a proxied DNS record at a private IP, and Cloudflare reaches the origin over your existing Cloudflare One connection. Your origin stays private, while web application firewall (WAF), caching, bot management, and Workers work just as they do for public origins.
In June, we launched this capability in closed beta to address a problem we kept hearing from customers: Their internal APIs, AI agent backends, MCP servers, and operational tools weren’t built to face the Internet, but those services still need to accept requests from partners, customers, or agents over the Internet. Before the beta, putting Cloudflare in front of these services meant exposing a public IP, opening a firewall port, or running cloudflared alongside the origin.
Those requirements often left private applications without the same protections and controls they used for public applications, including WAF, bot management, rate limiting, caching, traffic acceleration, rewrites, and Workers.
During the closed beta, eligible customers requested access through their account team. Today, we’re opening access beyond that beta group.
Point a proxied A or AAAA record at a private IP, and Cloudflare’s application services work as they do for public origins:
Some limitations remain. Argo Smart Routing and Dedicated CDN Egress IPs aren’t supported, and origin health checks require Load Balancing. See the developer documentation for the full list of current limitations.
Your origin keeps its private IP, with no inbound firewall exception required. With Cloudflare WAN, no connector software on the origin is required. With Cloudflare Mesh, a connector runs within your private network and can serve multiple origins.
Create a proxied A or AAAA record pointing to your origin. For supported private IP ranges, use private network routing is enabled automatically. If your origin uses a public IP that’s reachable only through your private network, you can enable the setting manually.
The rest of the request flow stays the same: TLS termination, WAF, rules, and caching continue to run on Cloudflare’s network.
The setting turns on automatically for RFC 1918 private IPv4 addresses, RFC 6598 CGNAT addresses (100.64.0.0/10), and RFC 4193 unique local IPv6 addresses (fc00::/7). It can’t be turned off for these ranges; attempts to disable it through the API return an error.
For customers automating deployments through the API, private routing is simply an additional attribute on a standard DNS 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
}
Behind the scenes, Cloudflare's proxy platform determines where to send traffic for app.example.com by querying Cloudflare's Origin API. The response includes metadata indicating that the destination should be reached through a private network path:
{
"zone_name": "example.com",
"ipv4_addresses": ["10.0.0.50"],
"private_routing": true
}The private_routing flag is the key signal. When our proxy sees it, instead of attempting to connect directly to the private IP address over the public Internet, it hands the request to our private networking layer, which then routes the connection across the customer's existing private network connectivity, whether that's IPsec, GRE, Cloudflare Tunnel, CNI, or Cloudflare Mesh.
The beta post covers the routing layer in more detail.
Before you begin, you’ll need:
Then, create a proxied A or AAAA record for the private IP and confirm that Use private network routing is enabled. Your existing WAF, cache, and bot management configuration applies to that hostname without further changes.
One note from the beta: if requests time out and nothing arrives at the origin, check the return route first. A missing route for Cloudflare’s source range was the most common setup failure we saw.
Once enabled, follow our developer documentation, which walks through the full setup.
Today’s release covers public traffic reaching private origins. Next, we’re working on private-to-private traffic: users, services, and AI agents on private networks reaching applications on other private networks through Cloudflare’s application services.
Engineering work is underway, and we’re targeting a closed beta in early 2027. If you’d like to participate, talk to your account team.
The goal is to give private applications the same protections and controls as public applications. An employee opening wiki.company.internal, for example, could benefit from WAF, rate limiting, and bot management. Service-to-service traffic between clouds and data centers could use those controls too, even when neither side touches the public Internet.
For now, today’s release brings the WAF, caching, bot management, and Workers you use for public applications to private origins over connectivity you already operate.
Questions or feedback? Join the conversation in our community forums or reach out to your account team.
Continue reading on the original blog to support the author
Read full articleEngineers must adapt to high-frequency, short-duration attacks that bypass traditional thresholds. While massive volumetric threats decreased due to botnet takedowns, the pivot to DNS and UDP amplification requires robust, automated mitigation strategies across diverse protocols.
This report highlights that even resilient distributed systems depend on physical infrastructure like power grids and cooling. For engineers, it underscores the importance of geographic redundancy and understanding how localized failures at interconnection points can cause national-level outages.
Engineers can now execute arbitrary code inline with security policies without managing separate proxy infrastructure. By combining edge compute with a secure web gateway, Cloudflare enables complex traffic manipulation and data-driven decisions with zero added latency.
This eliminates the 'black box' nature of edge processing by providing granular visibility into how security rules, transformations, and routing affect requests. It allows engineers to debug complex distributed systems using industry-standard OpenTelemetry protocols.