Cloudflare has announced the general availability of its private origins service, marking a significant milestone for organizations looking to secure internal applications, modern API architectures, and artificial intelligence infrastructure. By simply pointing a proxied DNS record at a private IP address, companies can now route traffic from the public internet directly to their private origins using their existing Cloudflare One connections. This seamless integration allows critical services—such as internal APIs, Model Context Protocol (MCP) servers, AI agent backends, and operational tools—to remain isolated from direct public exposure while still leveraging Cloudflare’s robust suite of application security and performance tools.
The rollout follows a closed beta program launched in June, which was initiated to address a persistent operational challenge heard from customers across industries. Modern infrastructure designs increasingly rely on backend components, AI assistants, and automated agents that were never built to face the open internet. However, these same systems frequently need to accept legitimate incoming requests from external partners, customers, or distributed client software. Historically, bridging this gap required organizations to expose public IP addresses, configure fragile inbound firewall exceptions, or deploy auxiliary connector software such as cloudflared directly alongside the origin infrastructure.
These architectural workarounds often left private applications structurally disadvantaged compared to their public-facing counterparts. Because they bypassed standard edge security perimeters, internal applications frequently lacked critical protections including Web Application Firewalls (WAF), advanced bot management, granular rate limiting, high-performance caching, traffic acceleration, and edge computing capabilities powered by Cloudflare Workers. Today’s general availability release bridges this security and performance divide, bringing enterprise-grade edge controls directly to private network infrastructure without requiring complex re-architecture.
Expanding Access Beyond the Closed Beta
During the initial closed beta phase, eligible organizations were required to coordinate with their dedicated account teams to gain access to private origin routing. With today’s launch, Cloudflare is officially opening the capability to a broader audience, removing the requirement for special beta provisioning.
Under the newly available architecture, system administrators can point a standard proxied A or AAAA record at a private IP address, allowing Cloudflare’s application services to process traffic just as they would for a conventional public origin. The origin server maintains its private IP address, and no inbound firewall exceptions are required on the host network. Furthermore, for organizations utilizing Cloudflare WAN or Cloudflare Mesh, there is no need to install additional connector software on the origin server itself, streamlining deployment and reducing ongoing maintenance overhead.
Despite the broad expansion, some platform limitations remain in place for the general availability release. Advanced features such as Argo Smart Routing and Aegis are not currently supported, and origin health checks require the use of Cloudflare Load Balancing. Organizations are encouraged to review the official developer documentation for a comprehensive, up-to-date catalog of current limitations and configuration prerequisites.
How Private Origin Routing Works Under the Hood
The underlying mechanics of private origin routing are designed to be intuitive for network and infrastructure teams. Administrators begin by creating a proxied A or AAAA record pointing directly to their internal origin. For recognized private IP ranges, the system automatically enables a setting known as private network routing. If an organization utilizes a public IP address that is exclusively reachable through its private network, this setting can also be enabled manually.
Once configured, the request lifecycle at the network edge remains familiar. Standard procedures such as TLS termination, WAF evaluation, rule execution, and caching continue to run smoothly across Cloudflare’s global network.
The configuration automatically engages for RFC 1918 private IPv4 addresses, RFC 6598 Carrier-Grade NAT (CGNAT) addresses within the 100.64.0.0/10 range, and RFC 4193 unique local IPv6 addresses in the fc00::/7 block. For these designated ranges, private network routing is permanently enabled by design, and attempts to disable the setting via the API will return an error to preserve security boundaries.
For engineering teams that automate infrastructure provisioning through APIs, private routing is integrated as an additional attribute on standard DNS records. When configuring a DNS record programmatically, developers include a specific private routing flag in the JSON payload. Behind the scenes, Cloudflare’s proxy platform resolves the destination by querying the Origin API, which returns metadata indicating that the traffic must traverse a private network path rather than the public internet.
When the proxy recognizes this routing flag, it bypasses attempts to connect directly to the private IP over the public web and instead hands the request to Cloudflare’s internal private networking layer. This layer safely transports the connection across the customer’s pre-existing private network connectivity, utilizing established protocols and architectures such as IPsec, GRE tunnels, Cloudflare Tunnel, Cloudflare Network Interconnect (CNI), or Cloudflare Mesh.
Implementation and Early Deployment Insights
Getting started with the service requires an existing Cloudflare One connectivity option alongside a configured private networking path to the origin. Once these foundational elements are in place, administrators create a proxied DNS record for the private IP and verify that private network routing is active. Existing WAF policies, caching rules, and bot management configurations immediately apply to the hostname without requiring redundant setup steps.
Drawing from lessons learned during the closed beta phase, Cloudflare engineering teams highlight return routing as a critical configuration detail. The most common setup hurdle observed during the beta period involved connection timeouts caused by missing return routes for Cloudflare’s source IP ranges. Ensuring that the origin network correctly routes traffic back through the established tunnel or interconnect resolves this issue immediately.
Looking Ahead to Private-to-Private Traffic
While today’s general availability release focuses primarily on safely routing public traffic to private origins, Cloudflare is already laying the groundwork for the next evolution of the platform: private-to-private traffic routing. Engineering work is actively underway to enable human users, backend services, and AI agents operating within private networks to securely reach applications residing on entirely separate private networks, all mediated by Cloudflare’s application services.
Cloudflare is targeting an early closed beta for private-to-private routing, with interested organizations advised to contact their account teams to participate. The overarching vision is to provide private applications with the exact same security controls, visibility, and performance optimizations traditionally reserved for public web properties. For instance, an employee accessing an internal corporate wiki could benefit from comprehensive WAF protection, rate limiting, and bot management, while service-to-service communication between disparate cloud environments and data centers can leverage those same safeguards without exposing data to the public internet.
For now, the general availability of private origins delivers an essential capability, extending enterprise-grade WAF, caching, bot management, and Workers execution to internal applications over trusted network topologies. Organizations with questions or feedback are encouraged to engage with the engineering community through Cloudflare’s community forums or by reaching out directly to their account representatives.
