If you read the Cloudflare Tunnel post, you know the problem: localhost does not accept webhooks, OAuth providers reject http://localhost as a redirect URI, and showing a client a work-in-progress means a deploy. Cloudflare Tunnel solves it, but it wants a Cloudflare account and domain setup.
Microsoft Dev Tunnels is the zero-setup alternative. It is already installed if you have Visual Studio 2022 17.4+ (including VS 2026) or the Azure CLI. One command, and your localhost has a persistent public URL backed by Azure infrastructure.
When to use which:
- Cloudflare Tunnel: you own a domain and want a stable named URL (
api.yourdomain.com), production-ish setup.- Dev Tunnels: you want to be running in 30 seconds, no domain, already have VS or the Azure CLI.
How it works#
The devtunnel process opens an outbound connection to Azure’s relay. No inbound ports, no firewall changes. Traffic hits the public *.devtunnels.ms URL and forwards to your local port.
Expose localhost in three commands#
devtunnel user login # one-time, uses your Azure/Microsoft account
devtunnel host -p 5217 # host a tunnel for localhost:5217
# Connect: https://abc123-5217.devtunnels.ms
# Inspect: https://abc123-5217-inspect.devtunnels.msThat URL is live immediately.
The main use case: webhooks#
Your app needs a POST from Stripe, GitHub, or Azure Event Grid, and none of them can reach localhost. Run your API, then host the port with devtunnel host -p 5217 --allow-anonymous and point the provider’s webhook at https://abc123-5217.devtunnels.ms/webhooks/stripe. The --allow-anonymous flag skips the tunnel’s built-in login page, which a webhook sender cannot pass. The -inspect URL gives you a request/response viewer, like ngrok’s dashboard, so you can see the exact payload before your handler runs.
The same tunnel covers the other localhost chores:
- OAuth redirect URIs: register
https://<id>.devtunnels.ms/signin-oidcin your app registration. Azure AD, GitHub, and Google accept it where they rejectlocalhost. - Stable URLs: the quick-start URL rotates each session.
devtunnel create <name>plusdevtunnel port create <name> -p 5217gives you a named tunnel that keeps the same URL, so you register a callback once. - Client demos:
devtunnel host -p 4200and send the link, no deploy. First-time visitors see a confirmation page unless you add--allow-anonymous. - Visual Studio: the same thing lives on the debug toolbar (Dev Tunnels, then Create a Tunnel), and the URL is exposed as
VS_TUNNEL_URLduring the session.
Dev Tunnels vs Cloudflare Tunnel vs ngrok#
| Feature | Dev Tunnels | Cloudflare Tunnel | ngrok Free |
|---|---|---|---|
| Setup time | 30 seconds | 10-15 minutes | 2 minutes |
| Custom domain | No | Yes (own domain) | Paid plan |
| Persistent URL | Named tunnels | Yes | Paid plan |
| Auth required on recipient | Optional | No | No |
| Built into IDE | VS 2022+ | No | No |
| Traffic inspector | Yes | No (needs dashboard) | Yes |
| Account needed | Microsoft/Azure | Cloudflare | ngrok |
| Cost | Free | Free (core) | Free (limited) |
Gotchas#
- Session auth page: by default a tunnel visitor sees a Microsoft login prompt. Add
--allow-anonymousfor webhooks and public demos. - Tunnel lifetime: temporary tunnels close with the CLI; named tunnels persist but still need
devtunnel hostrunning. - Rate limits: Dev Tunnels has usage limits. It is a dev tool, not a way to run production traffic through a tunnel.
- VS and CLI are separate: a tunnel created in Visual Studio does not show in
devtunnel list, and vice versa.