Cloudflare just shipped DNS routing to private origins — no public IPs, no extra connectors

Cloudflare announced Application Services for Private Origins yesterday. It's in closed beta. The core idea: route public hostnames to private IP origins over your existing IPsec, GRE, CNI, or Cloudflare Mesh paths. No public IPs required. No extra connector software.

This matters for agentic infrastructure because most production agents run behind corporate firewalls. The standard workaround is ngrok, Tailscale, or a custom reverse proxy. All of those add latency, complexity, and another failure mode. Cloudflare's approach uses the network paths you already have.

Here's how it works. You run IPsec or GRE tunnels from your internal network to Cloudflare's edge. You configure DNS records that point to private IPs (10.x, 172.16.x, 192.168.x). Cloudflare resolves those records at the edge and routes traffic over your existing tunnel. The private IP never touches the public internet.

The blog post calls out a few use cases: internal apps that need public hostnames for SSO, legacy apps that can't run behind a reverse proxy, and multi-cloud deployments where you want consistent DNS regardless of where the origin lives. All of those apply to agentic deployments too.

Why this matters for agents

Most voice agents we deploy at VioX run on internal Kubernetes clusters. The agent needs a public phone number, which means the SIP provider needs to reach the agent. The standard pattern is:

1. Expose the agent via a public load balancer (adds cost, latency, attack surface)
2. Run a reverse proxy like Cloudflare Tunnel or ngrok (adds a hop, another failure mode)
3. Run the agent in a public cloud VPC with direct internet routing (fine if you're already in AWS or GCP; painful if you're on-prem)

Cloudflare's private origins feature collapses steps 1 and 2. You keep the agent on your internal network. You point a public DNS record at the internal IP. Cloudflare routes traffic over the tunnel you already have for other services. No new software, no new failure modes.

The latency story is interesting. Cloudflare claims sub-10ms edge resolution for private DNS records. If that holds, the total latency is tunnel RTT plus agent response time. For most IPsec or GRE tunnels, that's under 50ms. That's better than ngrok (which adds 80–120ms on average) and comparable to running a public load balancer in the same region as your cluster.

What's missing

The blog post doesn't mention pricing. The closed beta application form asks about scale (requests per second, number of origins). That suggests consumption pricing, not a flat fee. If it's priced like Cloudflare's other Application Services products (Load Balancing, Rate Limiting), expect $5–10 per origin per month plus per-request fees. That's cheaper than a dedicated reverse proxy but more expensive than raw DNS.

The blog post also doesn't mention whether private origins work with Cloudflare Workers. If they do, that's a new agentic pattern: run the agent on your internal cluster, run the orchestration logic in a Worker at the edge, and let Cloudflare route between them over your existing tunnel. That would be a real unlock for hybrid agentic deployments.

Cloudflare's blog post includes a diagram showing Application Services for Private Origins sitting between Cloudflare's DNS resolver and your private network. The resolver queries the private DNS zone, gets back a private IP, and routes the request over the tunnel. The tunnel can be IPsec, GRE, CNI (Cloudflare Network Interconnect, their dedicated fiber product), or Cloudflare Mesh (their new SD-WAN offering). All of those are already supported for Cloudflare Access and Cloudflare Gateway, so the infrastructure is there.

The closed beta application is live now. Cloudflare says they're targeting general availability in Q3 2026. If the latency claims hold and the pricing is reasonable, this becomes the default pattern for exposing internal agents to public SIP providers or HTTP webhooks.

What we're watching

Three things will determine whether this becomes the standard pattern:

1. Latency in practice. Cloudflare claims sub-10ms edge resolution, but that doesn't include the tunnel RTT or the agent's processing time. We'll test this with Best Limo NY's voice agent (currently running on a GKE cluster behind an ngrok tunnel) and see if the total latency drops.

2. Pricing. If it's priced like Cloudflare Load Balancing ($5 per origin + $0.50 per million requests), that's cheaper than running a dedicated reverse proxy. If it's priced like Cloudflare Workers ($5 per million requests), that's too expensive for high-volume agents.

3. Workers integration. If private origins work with Cloudflare Workers, that enables a new agentic pattern: run the LLM inference on your internal cluster (where you have GPUs or custom silicon), run the orchestration logic in a Worker at the edge (where you have sub-50ms latency to users), and let Cloudflare route between them. That's the pattern we've been building manually with custom reverse proxies; it would be useful to have it as a primitive.

Cloudflare's blog post ends with a link to the closed beta application. We applied this morning. If we get in, we'll ship a migration log for Best Limo NY's voice agent and post the before/after latency numbers.