Cloudflare Tunnel gives you a way to publish services without exposing the origin directly to the internet. In Cloudflare’s model, a lightweight cloudflared daemon runs inside your infrastructure and opens outbound-only connections into Cloudflare’s network. That is the appeal from a security point of view. It is also how tunnel estates quietly grow messy. Once a tunnel fixes an access problem, teams still need to answer the unglamorous questions: what it connects to, who owns it, how resilient it is, and how anyone is supposed to troubleshoot it under pressure.
Cloudflare’s early 2026 updates make those questions harder to dodge. On February 20, 2026, Tunnel management moved into the main Cloudflare Dashboard. On March 19, 2026, Cloudflare introduced wrangler tunnel commands for terminal-based management. On March 20, 2026, Cloudflare added a tunnel overview in the Cloudflare One dashboard that shows replicas and streams logs from multiple replicas at the same time. None of that creates governance for you, but it does remove a lot of the old friction around seeing what exists and how well it is set up.
What changed, in practical terms
The February 20 dashboard release matters because Tunnel is no longer tucked away in a narrow setup flow. It now sits under Networking > Tunnels in the main dashboard, where Cloudflare positions it as a place to create, configure, delete, and monitor tunnels. Cloudflare also added native integrations so tunnels can be selected by name when working with DNS records and Workers VPC services, instead of relying on copied UUIDs. The routing map is the more important operational detail: public applications, private hostnames, private CIDRs, and Workers VPC services are visible in one place, alongside tunnel health and replica status. That turns tunnel inventory into something an operations team can actually review instead of reconstructing by memory.
The March 19 Wrangler release changes a different part of the workflow. Cloudflare added terminal commands to create, list, inspect, delete, and run tunnels, plus a quick-start path for free temporary tunnels. Wrangler will also download and manage the cloudflared binary on first use. The business value is repeatability. Once a team can rely on commands like wrangler tunnel list and wrangler tunnel info, tunnel management becomes easier to document, script, review, and hand over. Cloudflare also labels these commands experimental and notes they may change without notice, so production processes built around them should be version-aware and properly documented.
The March 20 observability update closes a more obvious gap. Cloudflare says that before this release, you could only stream logs from one replica at a time. The new tunnel overview page in the Cloudflare One dashboard shows all active replicas for a selected tunnel and lets you stream logs from several replicas simultaneously. That is not cosmetic. During an incident, comparing replicas is often the quickest way to tell whether you are dealing with a broader routing issue or a problem tied to one host or connector.
Why tunnel sprawl is harder to excuse now
Undocumented tunnel sprawl usually survives because auditing it is tedious. Someone has to find the tunnels, map them to DNS and origin services, work out who owns them, and check whether the deployment matches the importance of the service behind it. Cloudflare’s 2026 changes reduce the tooling excuse. If tunnels can be centrally listed, referenced by name in related workflows, inspected from the CLI, and reviewed through a route map, then “we do not really know what is there” starts to look less like a platform limitation and more like an operating decision.
That is where the commercial risk sits. The problems are usually ordinary, not dramatic. A production hostname still works, but nobody can say who owns the tunnel behind it. A customer-facing service is effectively hanging off one live connector because nobody revisited the original setup. Troubleshooting depends on SSH access to a server because no one established a sensible logging pattern. Better visibility makes these gaps visible earlier, which is useful if you would rather fix them before an outage, migration, or audit does it for you.
Cloudflare’s logging documentation is a good example. You can stream real-time tunnel logs either in the dashboard or from any machine with cloudflared installed, so remote troubleshooting does not have to start with shell access to the origin host. Cloudflare also notes that dashboard log streams are only available for remotely managed tunnels and require edit permissions rather than read-only access. The tunnel also has to be active and able to receive requests. On the CLI side, the documented patterns are cloudflared tail <UUID> for a tunnel and cloudflared tail --connector-id <CONNECTOR ID> <UUID> when you want a specific replica. That matters because the March 20 release improves the dashboard precisely by making cross-replica comparison easier.
Better observability still needs deliberate design
More visibility does not mean every logging option is fit for every job. Cloudflare documents that remote log sessions are capped at one hour and that logs can be dropped on high-throughput tunnels because service stability takes priority over log delivery. The same documentation recommends reducing log volume with filters such as event type, log level, or sampling rate, and notes that server-side logs are the better choice when complete coverage matters. So the dashboard and cloudflared tail are valuable operational tools, but they are not a substitute for an intentional logging design.
This is where older tunnel estates usually show their age. A team may have enough visibility to handle a live incident, but not enough structure to support audit, handover, or planned change. If a tunnel sits in front of an important service, “someone can probably log into the right VM and tail something” is not a serious operating model. The replica-aware tooling released on March 20 makes that easier to see. If availability matters, you should be able to explain why a service has the replica count it has, how those replicas are monitored, and how operators compare behavior when something starts failing.
The get-started documentation underlines another basic point: tunnel operations still depend on disciplined deployment. To create and manage tunnels, Cloudflare says you need to install and authenticate cloudflared on the origin server so it can connect that server to Cloudflare’s global network. Better tooling helps, but it does not remove the need for clean deployment standards.
What a rationalization engagement should actually cover
A useful cleanup project is usually not about building more tunnels. It is about removing ambiguity from the ones the business already relies on. In practice, that tends to mean five things.
- Build a tunnel inventory that maps each tunnel name to its purpose, DNS relationship, route type, origin service, and operational owner.
- Standardize names and routes so the dashboard and CLI views make sense to someone other than the original implementer.
- Review availability expectations and add replicas where the business impact justifies failover, instead of leaving important services on a single connector by default.
- Set a logging baseline that combines persistent local logs where needed with remote log streaming for faster diagnosis, while staying inside Cloudflare’s documented limits and permission model.
- Move repeatable lifecycle work out of one-off dashboard clicking and into documented CLI or API-driven procedures where that makes sense.
That is the real service angle behind these 2026 updates. Cloudflare is now much better at showing you the shape of your tunnel estate. Once that visibility is there, the sensible next step is to clean up the parts that were easy to tolerate when tunnels were treated as isolated fixes: unclear ownership, inconsistent routes, missing redundancy, and ad hoc troubleshooting.
For companies already using Cloudflare Tunnel, the takeaway is fairly simple. The security value of outbound-only origin connectivity is still there. What changed on February 20, March 19, and March 20, 2026 is that Cloudflare made tunnel operations easier to see and easier to manage across the dashboard and the CLI. Once visibility improves, undocumented sprawl stops looking like harmless technical debt and starts looking like preventable infrastructure risk.
Need help with this kind of work?
Need a clean tunnel inventory, naming standard, and logging baseline? Start with a Cloudflare Tunnel rationalization review. Get in touch with Greg.
Sources
- Manage Cloudflare Tunnel directly from the main Cloudflare Dashboard · Changelog
- Manage Cloudflare Tunnels with Wrangler · Changelog
- Stream logs from multiple replicas of Cloudflare Tunnel simultaneously · Changelog
- Cloudflare Tunnel · Cloudflare One docs
- Set up your first tunnel · Cloudflare One docs
- Tunnel log streams · Cloudflare One docs