Dev Tunnels: Test Webhooks and Share Local Apps Without a Deploy

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 work-in-progress means a deploy. Cloudflare Tunnel is a solid solution, but it requires 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+ (or later, 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 tool:

• Cloudflare Tunnel: you own a domain, you want a stable named URL (api.yourdomain.com), production-ish setup.
• Dev Tunnels: you want to be running in 30 seconds, no domain needed, already have VS or Azure CLI installed.

How Dev Tunnels Work

#

The devtunnel process opens an outbound connection to Azure’s relay infrastructure. No inbound ports, no firewall changes. Traffic arrives at the public *.devtunnels.ms URL and is forwarded to your local port.

Installation

#

Dev Tunnels ships with:

• Visual Studio 2022+ (17.4+, including VS 2026) — available as a built-in tool
• Azure CLI extension: az extension add --name dev-tunnels
• Standalone CLI: download from aka.ms/TunnelsCliDownload

Verify:

devtunnel --version

Quick Start: Expose localhost in 3 Commands

#

# 1. Log in (one-time, uses your Azure/Microsoft account)
devtunnel user login

# 2. Create and host a tunnel for localhost:5217
devtunnel host -p 5217

# Output:
# Connect via browser: https://abc123-5217.devtunnels.ms
# Inspect tunnel activity: https://abc123-5217-inspect.devtunnels.ms

That URL is live immediately. Share it, use it as a webhook callback, or paste it into an OAuth redirect URI configuration.

Use Case 1: Webhook Testing (.NET + Stripe / GitHub / Azure Event Grid)

#

The most common use case. Your app needs to receive a POST from a third-party service, but that service cannot reach localhost.

# Start your .NET API
dotnet run --project src/MyApi

# In a second terminal, expose port 5217
devtunnel host -p 5217 --allow-anonymous

Now configure the webhook endpoint in Stripe/GitHub/Azure Portal to:

https://abc123-5217.devtunnels.ms/webhooks/stripe

--allow-anonymous skips the tunnel’s built-in auth page — required for webhooks since the sending service cannot log in.

Inspecting Traffic

#

Dev Tunnels includes a built-in HTTP inspector at the -inspect URL:

https://abc123-5217-inspect.devtunnels.ms

This shows every request/response through the tunnel — similar to ngrok’s local dashboard. Useful for seeing the exact payload a webhook is sending before your handler processes it.

Use Case 2: OAuth Redirect URIs

#

OAuth providers (Azure AD, GitHub, Google) require a registered redirect URI. They reject localhost for production flows. With a Dev Tunnel:

1. Start your tunnel
2. Register https://abc123-5217.devtunnels.ms/signin-oidc as the redirect URI in your app registration
3. Update appsettings.Development.json:

{
  "AzureAd": {
    "CallbackPath": "/signin-oidc",
    "RedirectUri": "https://abc123-5217.devtunnels.ms/signin-oidc"
  }
}

For a more stable URL across restarts, use a named persistent tunnel (see below).

Use Case 3: Persistent Named Tunnels

#

The quick-start URL changes each session. For recurring use (OAuth redirect URIs you do not want to re-register, webhook endpoints in staging configs), create a named persistent tunnel:

# Create once
devtunnel create my-api-tunnel --allow-anonymous

# Add a port
devtunnel port create my-api-tunnel -p 5217

# Host it (same URL every time)
devtunnel host my-api-tunnel

The URL https://my-api-tunnel-<suffix>.devtunnels.ms stays stable across sessions.

Use Case 4: Sharing Work in Progress with a Client

#

No deploy required. Start your app, start the tunnel, send the URL:

devtunnel host -p 4200   # Angular dev server

The recipient gets a browser warning (tunnel access confirmation page) on first visit unless you add --allow-anonymous. For client demos, the confirmation page is usually fine — it makes the “this is a developer preview” context explicit.

Visual Studio Integration

#

In Visual Studio 2022+, Dev Tunnels are available directly from the debug toolbar:

1. Click the dropdown next to the run button
2. Select Dev Tunnels → Create a Tunnel
3. Choose tunnel type (temporary or persistent) and access (private / org / public)
4. Run the project — VS automatically uses the tunnel URL

The tunnel URL shows in the Output window and is available as an environment variable VS_TUNNEL_URL during the debug session.

Dev Tunnels vs Cloudflare Tunnel vs ngrok

#

Gotchas

#

Session auth page: by default, anyone visiting your tunnel URL sees a Microsoft login prompt. Add --allow-anonymous for webhooks and public demos.

Tunnel lifetime: temporary tunnels close when you stop the CLI. Named tunnels persist but still need devtunnel host to be active.

Rate limits: Dev Tunnels has usage limits — suitable for development, not for running a production service through a tunnel.

VS tunnel and CLI tunnel are separate: creating a tunnel in Visual Studio does not show up in devtunnel list and vice versa.

Common Commands Reference

#

# Login
devtunnel user login

# Quick tunnel (temporary)
devtunnel host -p 5217 --allow-anonymous

# Create persistent tunnel
devtunnel create <name> --allow-anonymous
devtunnel port create <name> -p 5217
devtunnel host <name>

# List tunnels
devtunnel list

# Delete tunnel
devtunnel delete <name>

# Show tunnel details and URL
devtunnel show <name>

If you are on Windows with Visual Studio, Dev Tunnels is the path of least resistance — it is already there. For cross-platform setups or when you need a stable domain-backed URL, Cloudflare Tunnel is the better fit.