Today, Cloudflare made services for private origins generally available, after a closed beta that began in June.1 It closes a gap that many enterprises on Cloudflare One have worked around for years: the applications that most need protecting are often the ones that were never meant to sit on the Internet.
What Cloudflare launched
Until now, putting Cloudflare's application services in front of an internal service meant one of three things: giving it a public IP, opening a firewall port, or running cloudflared next to it.1 Each one adds something to the network that a security team then has to own.
With this release:
- You create an ordinary proxied A or AAAA record that points at a private address.
- For RFC 1918 addresses, the CGNAT range 100.64.0.0/10 and IPv6 unique local addresses (fc00::/7), Cloudflare turns on Use private network routing automatically, and it cannot be turned off. You can also turn it on for a public IP that is only reachable over your private network.1
- Cloudflare terminates TLS and runs the WAF, managed rules, bot management, rate limiting, caching, transform rules and Workers at its edge, as it does for any public origin.
- The request then travels to the origin over your existing Cloudflare One connection: IPsec or GRE tunnels from Cloudflare WAN (formerly Magic WAN), a Cloudflare Network Interconnect (CNI), Cloudflare Tunnel, or Cloudflare Mesh.1
With Cloudflare WAN, nothing needs to be installed on the origin: the IPsec or GRE tunnel from your router or firewall already carries the traffic. With Cloudflare Mesh, one connector inside your network can serve several origins.
Two ways enterprises will use it
Publish an internal app to the people outside who need it
Internal APIs, partner portals, operational tools, AI agent back ends and MCP servers often need requests from outside the company, but they were built for the internal network. Cloudflare names exactly these examples.1
With a private origin, the service stays on its private address. Outside users reach a normal hostname on Cloudflare, and every request passes your WAF, bot and rate limiting rules first. There is no public IP for an attacker to find and go around Cloudflare to reach.
Give third-party contractors access without a VPN
Most enterprises know this problem: an outsourced development team, an auditor or a support vendor needs one or two internal applications, and the only way in is often a VPN account that places them on the network.
Because a private origin sits behind an ordinary proxied hostname, you can put a Cloudflare Access self-hosted application in front of it. Contractors sign in with their own company's identity provider or a one-time PIN, Access checks your policy on every request, and Cloudflare forwards only the allowed requests to the private IP. The contractor never gets a route into your network, and removing their access is a policy change, not a firewall ticket.
What you need before you start
Cloudflare lists four prerequisites.1
The private origins entitlement. Your Cloudflare account team enables it.
Cloudflare One connectivity over IPsec, GRE, CNI, Cloudflare Tunnel or Cloudflare Mesh.
Unified Routing, unless you only use Cloudflare Tunnel. Your account team can upgrade new or existing accounts.
A return route for Cloudflare's source ranges if you use Cloudflare WAN or Mesh:
100.64.0.0/12for IPv4 and2606:4700:cf1:5000::/64for IPv6. Your router or firewall must send replies to these ranges back through the Cloudflare tunnels.
Then create the proxied record, confirm private routing is on, and your existing WAF, cache and bot settings apply with no further changes.
Limits to know about
- Argo Smart Routing and dedicated CDN egress IPs are not supported for private origins.1
- Origin health checks need Load Balancing.
- The return route has to coexist with your existing routing. If
100.64.0.0/12overlaps a range you already use inside your network (CGNAT is common on carrier and SD-WAN links), plan that before you go live. - Cloudflare's developer documentation has the full list of limitations.
What comes next
Cloudflare is also working on private-to-private traffic: users, services and agents on one private network reaching applications on another, with WAF, rate limiting and bot protection applied on the way. Its example is an employee opening wiki.company.internal. A closed beta is planned for early 2027; ask your account team if you want to join.1
How Vigilbase can help
We have set up a lot of Cloudflare WAN uplinks: IPsec and GRE tunnels from enterprise firewalls and routers, redundant links across data centres, return routing and Cloudflare Access for staff and third parties. Moving an internal application to a private origin touches all of those at once, and a wrong route or an over-broad Access policy is easy to miss.
If you want to publish internal applications through Cloudflare, or replace contractor VPN access with Cloudflare Access, talk to us. We can review your current connectivity, plan the return routes and Access policies, and run the change with you.
Sources
- ↩
Cloudflare, Cloudflare services for private origins is now generally available, 30 October 2026.



