Cloudflare Tunnel Review: Exposing a Development Server Without Port Forwarding

Cloudflare Tunnel is a practical option when I need to expose a local server or an internal tool without opening router port forwarding. In our company, we still have cases where services are exposed through router port forwarding, and recently, while working on Microsoft Teams development, I used Microsoft Dev Tunnels to expose a local bot server. Both solve the immediate problem, but the trade-offs feel different once the same pattern repeats.

The reason I like Cloudflare Tunnel is simple. Instead of receiving inbound traffic directly from the Internet, cloudflared creates outbound connections to Cloudflare, and requests come back through that tunnel. I do not need to expose the origin IP or change router settings every time.

Summary

Cloudflare Tunnel connects a local or server-side resource to Cloudflare through the cloudflared client. It avoids direct port forwarding, works well with custom domains, and can be combined with Cloudflare Access for authentication. Microsoft Dev Tunnels are convenient for Microsoft Teams or bot debugging, but for shared company domains and longer-running internal tools, Cloudflare Tunnel feels closer to an operational option.

What Cloudflare Tunnel is

Cloudflare describes Tunnel as a way to connect resources to Cloudflare without a publicly routable IP address. The key component is cloudflared, a lightweight daemon that runs on my machine or server and establishes outbound connections to Cloudflare’s global network.

user → Cloudflare → Tunnel → local or server-side service

From the origin server’s point of view, traffic is not coming through an open public port. It arrives through the tunnel that the connector already established. It can be used for HTTP services, SSH, RDP, and Zero Trust private access scenarios, but this article focuses on the developer use case: exposing a local web service or internal web tool through a domain.

Comparing common options

The easiest way to understand Cloudflare Tunnel is to compare it with the options teams already use.

Option	Strengths	Weak points	Best fit
Port forwarding	Direct and familiar	Router/firewall changes, possible origin IP exposure	Simple personal servers
VPN	Strong for internal-network access	Heavy for external demos and user setup	Operator or internal-network access
ngrok-style tunnels	Very fast temporary sharing	Plan limits, domain stability, long-running use	Short demos and webhook tests
Microsoft Dev Tunnels	Fits Teams and bot local debugging well	Less ideal for general company domains and shared access policy	Teams apps, Bot Framework, local debugging
Cloudflare Tunnel	No port forwarding, custom domains, Cloudflare security integration	Requires Cloudflare account, DNS, and Zero Trust understanding	Development sharing, internal tools, access control

Compared with Microsoft Dev Tunnels

When I worked on Microsoft Teams development, Microsoft Dev Tunnels made sense. Teams apps and bots need an external HTTPS endpoint during local debugging, and the Microsoft documentation shows flows such as devtunnel host -p 3978 --protocol http --allow-anonymous. In that context, the tool is natural because it is already part of the Microsoft development path.

But to me, Microsoft Dev Tunnels feel more like a local debugging helper inside the Microsoft ecosystem. It is great for Teams, Bot Framework, Visual Studio, and Agents Toolkit flows. Cloudflare Tunnel feels more general when I think about internal tools, company domains, access policies, and services that might need to stay available for longer.

Item	Microsoft Dev Tunnels	Cloudflare Tunnel
Main use	Local development and debugging, especially Microsoft workflows	Connecting local/server services to Cloudflare
Teams development	Excellent fit	Possible, but not Teams-specific
Domain operation	Centered on `devtunnels.ms` development URLs	Natural with custom domains and DNS routes
Access control	Tunnel options and Microsoft account flow	Cloudflare Access, SSO, email, and policy rules
Long-running use	Mostly development-oriented	Service mode, multiple connectors, Zero Trust setup

What teams actually use in practice

In real workplaces, the answer is rarely one tool. Older environments still use port forwarding because it is simple and familiar. During development, temporary tunnels such as ngrok or Microsoft Dev Tunnels are common for webhook tests, Teams bot debugging, or mobile callback testing.

Once the use case becomes closer to production, the criteria change. The URL should not change every time, access should be controlled by policy, and the tunnel should survive a server restart. At that point, Cloudflare Tunnel, VPN, cloud load balancers, and Zero Trust access controls should be compared together.

Basic setup flow

The locally-managed tunnel flow is straightforward: add a domain to Cloudflare, install cloudflared, authenticate, create a tunnel, write a config, connect a DNS route, and run the tunnel.

brew install cloudflared
cloudflared tunnel login
cloudflared tunnel create my-dev-tunnel
cloudflared tunnel list

A simple config can route dev.example.com to a local service.

tunnel: <Tunnel-UUID>
credentials-file: /Users/me/.cloudflared/<Tunnel-UUID>.json

ingress:
  - hostname: dev.example.com
    service: http://localhost:8000
  - service: http_status:404

cloudflared tunnel route dns my-dev-tunnel dev.example.com
cloudflared tunnel run my-dev-tunnel

For long-running use, running cloudflared as a service or launch agent is safer than leaving it in a terminal session.

What felt useful in real use

The best part is not touching router or firewall settings every time. If I need to show a small web tool, admin page, or test API to someone outside my machine, Cloudflare Tunnel removes a lot of friction.

The second benefit is a stable domain. A URL that changes every time breaks documents, webhook settings, and test notes. A domain such as dev.example.com is much easier to explain.

The third benefit is that Cloudflare Access can sit in front of it. If a URL should not be public, I can add email, SSO, OTP, or policy-based access rules.

Security and best practices

Cloudflare Tunnel is not automatically secure just because it avoids port forwarding. The important question is still: what service is exposed, and who can access it?

Area	Recommended approach	Reason
Exposure	Put even development servers behind authentication by default	A known URL should not equal open access
Access control	Use Cloudflare Access with email, SSO, or OTP	Internal tools need user-level control
Tunnel credentials	Treat credentials files and tunnel tokens as secrets	A leaked token can attach an unexpected connector
Service account	Use manageable accounts for shared/long-running tunnels	Better for ownership changes and audit
Ingress	Keep a catch-all such as `http_status:404`	Reduces accidental exposure
Runtime	Use service mode for long-running tunnels	Survives restarts more reliably

The risky mindset is “it is only a development server.” Development servers often contain test accounts, internal API responses, sample data, or admin screens. If the URL is public and unauthenticated, it is still an exposed service.

What was confusing at first

Creating a tunnel and exposing a service are not the same step. Creating the tunnel gives me a UUID and credentials. DNS routes and ingress rules decide what actually becomes reachable.

When something does not open, I first separate three questions: is the local service running, is cloudflared connected, and is the DNS route correct?

cloudflared tunnel list
cloudflared tunnel info my-dev-tunnel
cloudflared tunnel run my-dev-tunnel

Where it is useful

Sharing a local development server with another person
Keeping a stable URL for webhook testing
Avoiding router port forwarding
Putting internal admin tools behind Cloudflare Access
Managing SSH/RDP or private access with a Zero Trust model
Reducing direct origin-IP exposure for a small server

Conclusion

Cloudflare Tunnel is a realistic option when I want to expose a development server or internal service without opening port forwarding. In a company like ours, where port forwarding still exists and Microsoft Dev Tunnels are used for specific development flows, it is worth comparing the roles clearly.

It is not the answer to every networking problem. It adds Cloudflare dependency and requires some understanding of DNS and Zero Trust. But once the structure is clear, it is a useful way to reduce repeated network setup work while improving access control.

References

Original Korean version: This article is based on the Korean version and lightly adapted for English readers. Read the original Korean post. Please show some love to Korean, too.