Dev Tunnels in Visual Studio let you expose your local Teams, SharePoint, or Power Platform services to the internet in minutes—no Azure deploys required. Configure a named, persistent tunnel and use Private (authenticated) access tied to Microsoft Entra ID to keep tests secure and your OAuth redirect URIs stable. With real-time feedback in Microsoft 365, you’ll cut iteration loops, avoid “Final_v2” chaos, and standardize setup with the Dev Tunnels CLI. The biggest risk? Leaving a tunnel Public/anonymous—one missed setting can expose your entire dev box. Lock it down, log it, and shut it off when done.

You can securely test Microsoft 365 Apps from your local machine by using visual studio dev tunnels. This tool lets you enable dev tunnels for fast, secure, and collaborative testing without needing to deploy to Azure.

Benefit	Description
Accelerated development cycles	Feedback is available within minutes, reducing the time compared to traditional deployment.
Evaluation consistency	Ensures the same pipeline is used for both local and production code, minimizing discrepancies.
Reduced infrastructure costs	Lowers cloud compute needs during development iterations.
Enhanced debugging capabilities	Allows for full local debugging while still utilizing cloud-based evaluation.

Visual studio dev tunnels offer persistent and named tunnels, Entra ID authentication, robust CLI support, and flexible visibility options. You can choose the right level of access for your project and collaborate with your team in real time.

Key Takeaways

Visual Studio Dev Tunnels allow you to test Microsoft 365 Apps securely from your local machine without deploying to Azure.
Local testing helps catch bugs early, saving time and reducing mistakes before sharing apps with users.
Dev Tunnels provide secure internet access for local services, enabling realistic testing of features like authentication and webhooks.
You can create and manage tunnels easily with Visual Studio or the command line, allowing for quick setup and collaboration.
Setting the right tunnel visibility (private, organizational, or public) is crucial for maintaining security during testing.
Always update your app registration and redirect URIs to match your tunnel URL to avoid authentication errors.
Use Entra ID authentication to secure your tunnels and ensure only approved users can access your local services.
Regularly monitor and manage your tunnels to keep your development environment organized and secure.

9 Surprising Facts About Visual Studio Dev Tunnels

Visual Studio Dev Tunnels give each tunnel a stable, shareable URL or name so you can reuse the same public address across development sessions instead of generating a new one every time.
Traffic through visual studio dev tunnels is TLS‑encrypted end‑to‑end by default, so you get HTTPS for local servers without managing certificates locally.
Dev Tunnels support both HTTP(S) and raw TCP port forwarding, letting you expose web apps, APIs, databases, and even SSH over the same tunnel infrastructure.
You can run multiple named tunnels concurrently and map different local ports to different public endpoints, so multiple teammates can reach distinct services on the same machine.
Access to tunnels can be restricted with authenticated identities (Microsoft/Azure accounts) and role-based controls, not just with obscure URLs—so sharing can be secure and auditable.
Visual Studio and Visual Studio Code integrate with dev tunnels, allowing you to create, manage, and connect to tunnels from the IDE without switching tools or copying URLs manually.
Dev Tunnels are useful for webhook development: external services can call your locally running webhook handler directly using the tunnel URL, eliminating the need for polling or complex NAT config.
There’s a CLI and programmatic API surface for dev tunnels, enabling automation (CI jobs, ephemeral test environments) that automatically create and tear down tunnel endpoints.
Because tunnels can be persistent and authenticated, they enable remote debugging scenarios where a teammate or CI agent connects directly to your local service for live diagnostics without VPN or exposing your entire network.

Local Testing with Visual Studio Dev Tunnels

Why Local Testing Matters

You want your Microsoft 365 Apps to work perfectly before sharing them with users. Local testing gives you the power to catch bugs early and see how your code behaves in a safe environment. When you test locally, you can make changes quickly and see results right away. This process saves you time and helps you avoid mistakes that might appear in production.

Traditional localhost testing has limits. Your local machine cannot accept connections from the internet. This makes it hard to test features that need real-world access, such as webhooks, authentication flows, or integration with Microsoft 365 services. You might find yourself stuck, unable to simulate how your app will behave for actual users.

Dev Tunnels has revolutionized the way we develop and test web applications, especially for mobile developers who often face challenges in setting up local servers for testing. It’s a game-changing feature that enhances collaboration and simplifies the development process.

With the right tools, you can overcome these challenges. You can create a realistic environment for your app, even when working from your own computer.

How Dev Tunnels Enable Local Testing

You can test Microsoft 365 Apps from localhost using visual studio dev tunnels. This tool gives you a secure way to expose your local services to the internet. You do not need to deploy your code to Azure or any other cloud platform just to see how it works with Microsoft 365.

Visual Studio Dev Tunnels enhance traditional localhost testing by enabling you to securely expose your local applications to the internet. This capability allows for inbound connections, which is essential for testing Microsoft 365 Apps in a more realistic environment, overcoming the limitations of being confined to local testing.

Here is how dev tunnels improve the speed and security of your local testing:

Dev tunnels enable local services to act as secure cloud endpoints in under 3 minutes.
They facilitate secure internet access for local testing of Microsoft 365 Apps.
Proper configuration is crucial to avoid exposing the development environment.

You can set up tunnels with just a few clicks or commands. You choose the name and visibility of your tunnel, so you control who can access your app. You can use authentication to keep your work safe. This flexibility means you can collaborate with teammates or invite testers without sharing your entire computer.

Dev tunnels let you test features like OAuth authentication, Teams bots, or SharePoint web parts as if they were running in the cloud. You get real-time feedback and can debug issues on the spot. This process makes your development cycle faster and more reliable.

When you use dev tunnels, you build confidence in your code before you deploy. You know your app works in the real world, not just on your machine.

Visual Studio Dev Tunnels Overview

Key Features

Visual studio dev tunnels give you a powerful way to test and debug Microsoft 365 Apps from your local machine. You can expose your asp.net core services to the internet with just a few steps. This tool helps you create a secure and flexible development environment.

Here are some of the main features you will find useful:

You can expose local APIs using remote URLs, making it easy to test and debug your asp.net core projects.
Integration with third-party services becomes simple because you have publicly accessible URLs for your local apps.
You can set breakpoints on your localhost and watch how your asp.net core code responds when remote URLs are accessed.
Named tunnels help you share specific projects or services without confusion.
Persistent tunnels let you keep access over time, which is important for ongoing asp.net core projects.
You can choose access levels for your tunnels: private, organizational, or public. This makes it easy to control who can see your work.
Entra ID authentication restricts access to users with valid credentials, keeping your data safe.
The CLI lets you manage and automate tunnel creation and configuration. You can use commands to create, list, and tag tunnels for easier management.

Tip: Persistent and named tunnels help you avoid recreating tunnels every time you restart your asp.net core project. This saves you time and reduces errors.

How Dev Tunnels Work

Dev tunnels create a secure bridge between your local asp.net core server and the internet. You can test Microsoft 365 Apps as if they were running in a live environment.

Secure Public Endpoints

You start by downloading and installing the devtunnel CLI. After logging in with your Entra ID, Microsoft, or GitHub account, you launch your local asp.net core server. Then, you host or create a tunnel using the devtunnel host –p PORT command. If you want a permanent URL, you use the devtunnel create command for a persistent tunnel.

This process gives you a secure, internet-accessible endpoint for your local asp.net core service. You can now test webhooks, authentication flows, and integrations that require public URLs. Entra ID authentication ensures that only approved users can access your tunnels, lowering the risk of accidental data exposure.

Integration with Visual Studio and CLI

Visual studio makes it easy to create and manage dev tunnels. You can set up a tunnel with just a few clicks inside the IDE. The CLI offers even more options, such as fixed-life tunnels and tagging for better organization. You can automate tunnel creation for your asp.net core projects, making your workflow faster and more reliable.

You can also list all your tunnels, view details, and manage access permissions. This flexibility helps you collaborate with your team and keep your development environment secure.

Note: Dev tunnels are designed to securely expose your local asp.net core endpoints to the internet, making testing and debugging safe and efficient.

Host or Create a Tunnel in Visual Studio

Prerequisites and Setup

Before you host or create a tunnel for Microsoft 365 App testing, you need to prepare your environment. Visual studio gives you the tools you need, but you must meet a few requirements first. The following table shows what you need to get started:

Prerequisite	Description
Visual Studio 2022 Preview	Download version 17.6 or later. Make sure the ASP.NET and web development workload is installed. Sign in to use dev tunnels.
Power Platform Environment	You need either Power Automate or Power Apps.

You should check that you have the correct version of visual studio. Open the installer and confirm that the ASP.NET and web development workload is active. Sign in with your Microsoft account to access the dev tunnels tool window. If you plan to connect your asp.net core project to Power Platform, make sure you have access to Power Automate or Power Apps.

Tip: Keeping your tools updated helps you avoid setup issues and ensures you can use the latest features in the dev tunnels tool window.

Creating and Naming a Tunnel

You can create a tunnel directly from the dev tunnels tool window in visual studio. This process lets you expose your asp.net core service to the internet for Microsoft 365 App testing. Follow these steps to create and name your tunnel:

In the debug dropdown, select Dev Tunnels > Create A Tunnel.
The dev tunnels tool window opens a dialog. Choose the account you want to use.
Enter a name for your tunnel. This name helps you identify it in the dev tunnels tool window.
Pick the tunnel type. Select Persistent if you want the same URL every time, or Temporary for a new URL each session.
Choose the authentication type: Private, Organization, or Public.
Click OK to create the tunnel.

When you create a tunnel, you make it easier to connect your asp.net core project to Microsoft 365 services. The dev tunnels tool window keeps your tunnels organized and visible. You can always find your active tunnels and manage them from this window.

Note: Naming your tunnel helps you and your team track which asp.net core service is exposed. Use clear names for each tunnel in the dev tunnels tool window.

Setting Tunnel Visibility

Tunnel visibility controls who can access your dev tunnels. You set this option in the dev tunnels tool window when you create a tunnel. The right visibility level protects your work and supports collaboration.

Here are the main visibility options:

Visibility Option	Description
Private	Only you can access the tunnel.
Organization	Anyone in your organization can access the tunnel. For personal accounts, this is the same as Private.
Public	Anyone on the internet can access the tunnel. Use this option with caution.

You can also see these options as:

Private: Only you can use the tunnel.
Organization: Your team or company can use the tunnel.
Public: Anyone can use the tunnel.

The dev tunnels tool window lets you change visibility when you create and manage dev tunnels. Choosing the right visibility helps you monitor traffic and keep your Microsoft 365 App secure. Private tunnels work best for solo development. Organization tunnels help teams test together. Public tunnels allow outside testers but require extra care.

Caution: Public tunnels do not require authentication. Use them only when you need to share your app with users outside your organization and always monitor access in the dev tunnels tool window.

Tunnel visibility affects both security and collaboration. When you set the right level, you make sure only the right people can access your app. This reduces risk and helps your team work together smoothly.

Using the Dev Tunnels CLI

You can manage dev tunnels directly from the command line by using the Dev Tunnels CLI. This tool gives you flexibility and speed, especially when you want to automate your workflow or work outside the visual studio interface. The CLI works well for both quick tests and more advanced setups.

To get started, you need to install the Dev Tunnels CLI. You can do this by running the following command in your terminal:

dotnet tool install -g Microsoft.DevTunnels.Cli

After installation, you must sign in. Use your Microsoft account, Entra ID, or GitHub account. This step connects your CLI session to your visual studio environment and ensures secure access.

devtunnel login

Once you sign in, you can create and manage tunnels. Here is a simple way to create a tunnel for your local project:

devtunnel host -p 5000

This command exposes your local service running on port 5000 to the internet. The CLI will display a public URL that you can use to test your Microsoft 365 App. You can share this URL with your team or use it for integration testing.

If you want a persistent tunnel with a custom name, use:

devtunnel create my-tunnel --persistent
devtunnel host my-tunnel -p 5000

This approach helps you keep the same URL across sessions, which is important for OAuth redirect URIs and consistent testing. You can also set tunnel visibility directly from the CLI. For example, to make your tunnel accessible only to your organization, add the --access organization flag:

devtunnel create my-tunnel --persistent --access organization

Tip: Use clear and descriptive names for your tunnels. This makes it easier to manage multiple projects in visual studio and avoid confusion.

You can list all your active tunnels at any time:

devtunnel list

To stop a tunnel, use:

devtunnel close my-tunnel

The CLI also lets you automate tunnel creation in scripts. This feature is useful when you want to set up dev tunnels as part of your build or deployment process. You can share CLI commands with your team so everyone uses the same configuration, which improves consistency and reduces errors.

Note: The Dev Tunnels CLI works seamlessly with visual studio. You can switch between the CLI and the visual studio interface without losing your tunnel settings.

By mastering the Dev Tunnels CLI, you gain more control over your development environment. You can quickly create, manage, and secure tunnels for any Microsoft 365 App project. This flexibility helps you test and debug your apps efficiently, whether you work alone or as part of a team.

Configure Microsoft 365 Apps for Dev Tunnels

Update App Registration and Redirect URIs

You need to update your app registration and redirect URIs to connect your local asp.net core project to Microsoft 365 services through visual studio. This process helps your app use the secure endpoint provided by dev tunnels. Here is a simple way to set up your app registration:

Open the Microsoft Entra ID – App Registrations portal.
Select "New Registration" and enter your app name.
Choose the supported account types for your app.
Leave the Redirect URI field empty for now.
Click "Register" to create your app.
On the overview page, copy the Application (client) ID and Directory (tenant) ID.
Under "Manage," select "Expose an API."
Click the "Set" link to generate the Application ID URI.
Add a scope named "access_as_user."
Set "Who can consent?" to "Admins and users."
Fill in the admin and user consent prompts.
Make sure the state is set to "Enabled."
Select "Add scope" to finish.

After you create your tunnel in visual studio, you need to update the Redirect URI in your app registration. Use the public URL from your asp.net core tunnel as the Redirect URI. This step lets Microsoft 365 know where to send authentication responses during testing.

Tip: Always save your client ID and tenant ID. You will need them for authentication and OAuth setup.

Connect Teams, SharePoint, and Power Platform Apps

You can use visual studio to connect your asp.net core services to Teams, SharePoint, and Power Platform Apps. Dev tunnels make this process secure and simple. When you use tunnels, you get alerts if you connect to a tunnel endpoint. These alerts help you avoid phishing attacks and accidental sharing of sensitive URLs.

Teams bots and message extensions use dev tunnels by default for local development. This setup gives you a secure way to test features before you deploy them.
SharePoint web parts and Power Platform connectors also benefit from secure endpoints. You can test webhooks, authentication, and data flows in a real-world scenario.
Microsoft 365 identity authentication adds another layer of security. You must sign in with your Microsoft 365 account to create and manage tunnels in visual studio.

Note: Enhanced security awareness helps you and your team stay safe while testing your asp.net core apps.

Handle Authentication and OAuth

You must configure authentication and OAuth to let your Microsoft 365 Apps work with dev tunnels. Here is a step-by-step guide:

Register your app in the Microsoft Entra ID portal.
Set your application URI to match the tunnel endpoint from visual studio.
Create a client secret for token exchange.
Add API permissions for Microsoft Graph access.
Update the Redirect URIs to use your asp.net core tunnel URL.
Set up dev tunnels for hosting your local service.
Clone your project repository and update the configuration files with your client ID, tenant ID, and secret.
Open visual studio and run your asp.net core project.

This setup allows your app to handle sign-in, token exchange, and API calls securely. You can test authentication flows, such as OAuth, in a safe environment before moving to production.

Always double-check your Redirect URIs and permissions. This step prevents common authentication errors and keeps your testing secure.

Security and Best Practices

Tunnel Visibility Options

You control who can access your development environment by setting tunnel visibility. When you create a tunnel, you choose between private, organizational, or public access. Private tunnels allow only you to connect. Organizational tunnels let anyone in your company use the tunnel. Public tunnels open access to anyone with the link. Always pick the lowest visibility needed for your project.

To maximize security during Microsoft 365 App testing, follow these best practices:

Set tunnels to private or organizational whenever possible.
Implement split tunneling for Office 365 applications. This method improves performance and keeps your data secure.
Use Microsoft-provided IP address ranges for split tunneling. Avoid using fully qualified domain names.
Disable SSL interception for Office 365 traffic. This step helps you comply with Microsoft’s security recommendations.
Confirm your split tunneling policy works by using the Microsoft 365 connectivity test tool.
Turn off SSL Break and Inspect for Office 365 domains.

Tip: Review your tunnel visibility settings before sharing any URLs. This habit helps prevent accidental exposure of your development environment.

Secure Access with Entra ID

You can secure your tunnels by requiring authentication with Entra ID. This feature ensures that only approved users can access your local services. When you enable Entra ID authentication, you add a strong layer of protection to your dev tunnels. Only users with valid credentials can connect, which helps keep your data safe.

Entra ID also supports organizational access. You can allow your whole team to test and debug apps without opening your tunnel to the public. This approach balances security and collaboration. Always use Entra ID authentication for sensitive projects or when handling confidential information.

Note: Entra ID authentication works seamlessly with both the Visual Studio interface and the command-line tools.

Monitoring and Managing Tunnels

You need to monitor and manage your tunnels to maintain a secure and efficient workflow. Visual Studio provides built-in features for managing dev tunnels. You can view active tunnels, check their status, and adjust access settings from within the IDE. The command-line interface also lets you create, list, and close tunnels quickly.

Best practices for managing tunnels include:

Regularly review your list of active tunnels.
Close tunnels when you finish testing to reduce security risks.
Use descriptive names for each tunnel to avoid confusion.
Choose between temporary or permanent tunnels based on your project needs.
Set access controls to match your security requirements.

A table can help you compare tunnel management options:

Management Tool	Features
Visual Studio IDE	View, create, edit, and close tunnels
Command-Line (CLI)	Automate tunnel creation and management

Remember: Good tunnel management keeps your development environment organized and secure.

Common Pitfalls to Avoid

When you use Visual Studio Dev Tunnels for Microsoft 365 App testing, you want to avoid mistakes that can slow you down or put your project at risk. Many developers run into the same issues. If you know what to watch for, you can save time and keep your environment secure.

1. Choosing the Wrong Tunnel Visibility

You might pick a public tunnel for convenience. This choice can expose your app to anyone with the link. Always check your tunnel’s visibility before you start testing. Use private or organization tunnels for most projects. Only use public tunnels when you need outside testers and always monitor access.

Tip: Review your tunnel settings before sharing URLs with your team or testers.

2. Forgetting to Update Redirect URIs

If you change your tunnel URL, you must update the redirect URIs in your app registration. If you skip this step, authentication will fail. Always double-check that your app registration matches your current tunnel endpoint.

3. Ignoring Authentication Settings

You may forget to enable Entra ID authentication for your tunnel. Without this, anyone can access your local service if they have the link. Always require authentication for sensitive projects. This step protects your data and your users.

4. Leaving Tunnels Open After Testing

If you leave tunnels running after you finish, you increase your security risk. Unused tunnels can become targets for unwanted access. Always close tunnels when you no longer need them.

5. Using Generic or Confusing Tunnel Names

If you use unclear names for your tunnels, you and your team may get confused. Use descriptive names that match your project or service. This habit helps you manage multiple tunnels and avoid mistakes.

6. Overlooking Log Monitoring

You might not check your tunnel logs. Logs help you spot unusual activity or unauthorized access. Make it a habit to review logs regularly.

Pitfall	How to Avoid It
Public tunnel for private app	Set tunnel to private or organization
Outdated redirect URI	Update app registration after tunnel changes
No authentication	Enable Entra ID authentication
Unclosed tunnels	Close tunnels after testing
Vague tunnel names	Use clear, descriptive names
Ignoring logs	Monitor logs for suspicious activity

Note: You can prevent most issues by following a checklist before and after each testing session.

By staying alert to these common pitfalls, you keep your development process smooth and your Microsoft 365 Apps secure. You build better habits and help your team avoid unnecessary problems.

Troubleshooting and Advanced Tips

Debugging Connection Issues

You may sometimes face connection problems when working with tunnels. Start by checking if your local service is running and listening on the correct port. Use the command line to confirm that your service responds to requests. If you see errors, restart your service and try again.

Next, check your firewall settings. Firewalls can block incoming connections. Allow traffic on the port you use for your tunnel. If you use a VPN, disconnect it and test again. VPNs can change your network settings and cause issues.

If you still have trouble, use the devtunnel list command to see all active tunnels. Make sure you use the correct tunnel URL in your Microsoft 365 App. Sometimes, copying the wrong URL causes connection failures.

Tip: Always test your tunnel URL in a browser before starting testing and debugging. This step helps you catch simple mistakes early.

Handling Authentication Errors

Authentication errors can stop your app from working with Microsoft 365 services. First, check your app registration in the Microsoft Entra ID portal. Make sure your redirect URIs match the tunnel URL exactly. Even a small typo can cause failures.

Review your client ID and secret. These values must match what you set in your app’s configuration. If you change your tunnel or create a new one, update the redirect URIs in your app registration.

If you see an "unauthorized" message, check your tunnel’s visibility and authentication settings. For sensitive projects, always use Entra ID authentication. This step keeps your data safe and prevents unwanted access.

Note: Most authentication errors come from mismatched URLs or missing permissions. Double-check these settings during debugging.

Advanced CLI and Automation

You can use the Dev Tunnels CLI to automate your workflow. Automation saves time and reduces mistakes. For example, you can write a script to create a tunnel, start your local service, and open the test page in your browser.

Here is a sample script for Windows PowerShell:

devtunnel create my-automation-tunnel --persistent --access organization
devtunnel host my-automation-tunnel -p 5000
Start-Process "https://my-automation-tunnel.devtunnels.ms"

You can share scripts like this with your team. Everyone can use the same setup for testing and debugging. This approach helps you work together and avoid configuration errors.

If you want to close all tunnels at once, use:

devtunnel close --all

Automating tunnel management makes your development process smoother and more reliable. Try using scripts for repeated tasks.

You can boost your Microsoft 365 App development by using visual studio dev tunnels. This tool makes testing faster and more secure. Start by setting up your first tunnel and follow best practices for visibility and authentication. Explore advanced features to improve your workflow. Remember to focus on security and teamwork as you continue testing and building better apps.

Visual Studio Dev Tunnels Checklist

Quick checklist to configure, use, and troubleshoot Visual Studio Dev Tunnels.

Verify Visual Studio version supports Visual Studio Dev Tunnels (Visual Studio 2022 or later / required workload installed)
Install or update the dev tunnels extension or CLI component if required
Sign in to your Microsoft account or AAD tenant used for tunnel access
Create a new dev tunnel from Visual Studio or via the dev tunnels CLI
Choose and confirm the correct tunnel name and region for low latency
Select and configure the local endpoint (port) to expose through the tunnel
Confirm protocol (HTTP/HTTPS or TCP) and enable TLS if exposing HTTPS
Configure and reserve custom domains or subdomains if needed
Set access policies: public, authenticated users, or specific AAD users/groups
Validate firewall and router settings to allow outbound tunnel traffic
Verify local app is running and listening on the configured port
Test tunnel connectivity from an external device or collaborator
Use HTTPS and valid certificates for production-sensitive endpoints
Rotate credentials and tokens periodically; revoke unused tokens
Monitor active tunnel sessions and usage from the Visual Studio or portal dashboard
Limit exposed routes and only forward necessary endpoints
Enable logging and inspect tunnel logs for connection errors or performance issues
Troubleshoot common issues: port conflicts, authentication failures, region mismatch
Update Visual Studio and dev tunnel tooling regularly for security fixes
Close or delete inactive tunnels to reduce attack surface and resource usage

dev tunnels in visual studio — use dev tunnels for asp.net core web projects

What are Visual Studio Dev Tunnels and how do they work?

Visual Studio Dev Tunnels is a feature (introduced and improved in Visual Studio 2022 v17.6 and later) that lets you create a secure tunnel from a local web project or local web service to the internet so remote machines, collaborators, CI systems, or mobile applications can access your web app or API. It creates a public dev tunnel URL that forwards requests to your localhost, enabling connections between machines that can't otherwise reach your development machine.

How do I create and use dev tunnels in Visual Studio?

In Visual Studio (VS 2022) you can open the Dev Tunnels window (via View > Other Windows > Dev Tunnels or the debug dropdown) and choose to create a tunnel for your web app or api. You pick a tunnel type (persistent or temporary), expose the local port for your ASP.NET Core web or core web API, and Visual Studio will generate a dev tunnel url. Use that URL in a web browser, mobile app, or webhook consumer to test your web services from remote environments.

What’s the difference between persistent and temporary tunnels?

Persistent tunnels remain registered (and can have stable dev tunnel URL mapping) across Visual Studio sessions and are useful for long-lived testing or collaboration; temporary tunnels are ad-hoc and exist only while your Visual Studio session or the tunnel process runs. Temporary tunnels are great for quick demos, testing and development, or when you don’t want to maintain a permanent public endpoint.

Can I use Dev Tunnels to test webhooks and web APIs from external services?

Yes — dev tunnels expose your local web API or web application to the internet so external services (payment providers, webhook senders, or Microsoft Learn labs) can reach your local endpoint. This is similar to ngrok but integrated into Visual Studio, providing a seamless debugging experience with breakpoints and local development environment tooling.

Do I need ngrok if I use Visual Studio Dev Tunnels?

No, ngrok is an alternative. Visual Studio’s dev tunnels feature offers a built-in option to create tunnels in Visual Studio 2022 without installing third-party tools. Some teams may still prefer ngrok for specific workflows, automation, or advanced features, but for many local development scenarios VS dev tunnels are sufficient.

How secure are dev tunnel URLs and connections?

Dev tunnels use authenticated, encrypted connections and are designed for development and testing. Persistent tunnels can be scoped to Visual Studio accounts or team identities to control access. Still, treat any public URL as potentially accessible and do not expose sensitive production data via a dev tunnel.

Can I debug an ASP.NET Core web API while it’s exposed through a dev tunnel?

Yes — you can debug an asp.net core web project that’s exposed through a dev tunnel just like a local web project. Requests arriving via the dev tunnel URL are forwarded to your local host where Visual Studio attaches the debugger, enabling breakpoints, step-through, and the standard debugging experience for web apis and core web applications.

How do dev tunnels help mobile developers and mobile app testing?

Mobile developers often need their mobile app to communicate with a local backend. Dev tunnels enable ad-hoc connections between machines so a phone or emulator on a different network can reach your local web services. This removes the need to deploy to cloud or change DNS settings and speeds up the development workflow for mobile applications.

What use cases are best suited for Visual Studio Dev Tunnels?

Common use cases include testing webhooks, collaborating with remote team members, demoing a feature to a stakeholder, connecting CI systems to local services, mobile app integration testing, and validating web APIs from external systems. They are particularly useful when you need to test local web services that otherwise cannot be reached from the internet.

How do I open the dev tunnels window and manage tunnels in VS?

Open the Dev Tunnels window from View > Other Windows > Dev Tunnels or from the debug dropdown in Visual Studio 2022. From there you can create new tunnels, pick a tunnel type (temporary tunnels or persistent), view the dev tunnel url, and stop or remove tunnels. The UI integrates with your development process so you can switch between running and exposing local web projects quickly.

Will the dev tunnel URL change each time Visual Studio creates a temporary tunnel?

Temporary tunnels usually generate a new dev tunnel url each time you create them. Persistent tunnels are intended to give a more stable URL across sessions. If you need a stable URL for integration testing or webhooks, choose a persistent tunnel or manage DNS/redirects outside the tunnel for production-like flows.

Can I use dev tunnels with Dataverse or other Microsoft cloud services?

Yes — dev tunnels can make your local endpoints reachable to cloud services that need callbacks or integrations, including Dataverse connectors and Microsoft-hosted services. Ensure authentication and security are configured properly; use tunnels for development/testing rather than production integrations unless explicitly supported.

How do dev tunnels compare with deploying to Azure for testing?

Dev tunnels let you test locally without deploying, which dramatically speeds up iterations and debugging. Deploying to Azure replicates production environments but adds deployment time and may complicate debugging. Use dev tunnels for development workflow speed and local debugging, and deploy to Azure for staging/production validation and performance testing.

Can I automate creating tunnels from my development process or CI?

Visual Studio’s UI is the most direct route, but the dev tunnels service provides CLI and APIs that can be scripted to create tunnels programmatically. This lets you automate tunnel creation for test runs, demos, or integration tests where an ephemeral dev tunnel url is required by external systems.

Are there limits to the kinds of local web services I can expose?

You can expose most local web services, including asp.net core web apps, web apis, core web services, and local web projects built with other frameworks. Some limitations may apply for protocols or ports not supported by the dev tunnels service; check Visual Studio documentation (and Microsoft Learn) for current platform specifics.

How does the debugging experience change when using a dev tunnel URL in a web browser?

The debugging experience remains seamless: requests from a web browser to the dev tunnel url are forwarded to your local host and handled by Visual Studio’s debugger. You can set breakpoints in your web project, inspect requests, and iterate code while the remote client interacts via the tunnel.

Can I expose multiple web apis or services at once with Dev Tunnels?

Yes, you can create multiple tunnels or configure a single tunnel to forward multiple ports depending on your scenario. This helps when testing a suite of local web services or microservices simultaneously from remote clients or mobile applications.

Is Visual Studio Dev Tunnels available in older VS versions like VS 2019?

The integrated Dev Tunnels feature is specific to Visual Studio 2022 (notably v17.6 and newer) and later versions. For older Visual Studio versions you’d use external tunneling tools (like ngrok) or upgrade to a supported VS release to use the built-in experience.

Where can I find tutorials or official guidance to get started?

Microsoft Learn and the Visual Studio documentation contain step-by-step tutorials on how to open the dev tunnels window, create tunnels, and use dev tunnels in Visual Studio for local development and testing. Search “Visual Studio Dev Tunnels tutorial” or consult the “create and use dev tunnels” guides on Microsoft Learn for hands-on examples.

🚀 Want to be part of m365.fm?

Then stop just listening… and start showing up.

👉 Connect with me on LinkedIn and let’s make something happen:

🎙️ Be a podcast guest and share your story
🎧 Host your own episode (yes, seriously)
💡 Pitch topics the community actually wants to hear
🌍 Build your personal brand in the Microsoft 365 space

This isn’t just a podcast — it’s a platform for people who take action.

🔥 Most people wait. The best ones don’t.

👉 Connect with me on LinkedIn and send me a message:
"I want in"

Let’s build something awesome 👊

Ever built the perfect Teams app locally… only to realize your customer can’t test it without a painful deployment? What if you could make your laptop act like a secure cloud endpoint in under 3 minutes? Dev Tunnels in Visual Studio can do exactly that—but only if you configure them right. Today I’ll walk you through how to open your local services to the internet, securely, for Microsoft 365 testing—and the one setting that could accidentally expose your entire dev box if you miss it.

What Dev Tunnels Really Are (and Why That Matters for M365 Apps)

Most developers hear “Dev Tunnels” and think “temporary URL.” That description isn’t wrong—it’s just incomplete. A tunnel isn’t just a link. It’s a remote entry point into whatever service is running on your machine right now. And when you’re building for Microsoft 365—whether that’s a Teams personal app, a SharePoint web part, or a Power Platform custom connector—that distinction matters a lot more than most people realize. At its simplest, a Dev Tunnel is a way to take something running locally—say a Node server for your Teams tab—and let people hit it from anywhere on the internet. No publishing to Azure first. No staging environment. It’s just your local code, reachable by someone across the country the moment they load the link. For M365 scenarios, that’s gold. Teams tabs, SharePoint Framework solutions, or webhooks for Power Automate flows often need to make live calls to your dev service. Without an externally reachable endpoint, those features either break or force you into a slow deployment loop. Here’s the catch—because tunnels are so easy to spin up, plenty of developers treat them as a disposable convenience. They’ll click “create,” grab the link, and forget about what’s actually being exposed. But the truth is, the way you configure your tunnel shapes who has access, how secure it is, and even how long it lasts. Without thinking about that, you might hand out more access than you intended—sometimes to the entire internet. Think of it like issuing a guest pass to your dev machine. If that pass has “access all areas” printed on it, and you’ve left your desk unattended, you can imagine the risk. Dev Tunnels work the same way: the rules you set at creation time are the guardrails that keep your guests from wandering into places they shouldn’t. I’ve seen people run right into this problem when testing with remote teammates. One dev tried to get feedback on a Teams tab from a colleague in another city. The app worked fine locally. But Teams, by design, wasn’t going to call `localhost:3000` from a user’s client session in another tenant. Without a tunnel, their only option was to package and deploy the tab into a test tenant running in Azure. That deployment cycle? Fifteen minutes per change. By lunchtime, they’d tested almost nothing. The first time they used a Dev Tunnel, feedback was instant—click save, reload in Teams, done. Microsoft actually has a big base of developers using Microsoft 365 tools this way. A significant portion report that they can run most of their iteration cycles entirely locally, as long as they can push traffic through a tunnel. Those working cloud-only generally accept that slower loop as the trade-off. The tunnel group, in contrast, gets real-time feedback. Before tunnels, devs relied on staging servers or manually deploying builds to cloud sandboxes. Staging works fine for stable features, but it’s overkill for testing a half-built card in Adaptive Cards Designer or checking if your bot’s messaging extension responds correctly when called from a remote Teams client. Not to mention that staging environments add network hops, authentication differences, and configuration mismatches that can hide or introduce issues you won’t see in production. And it’s not just about speed. When you compress the feedback loop this much, collaboration changes. You can have a PM, a designer, and a developer looking at the same instance of your app in live Teams while you tweak things on your laptop. You’re building in real time, without waiting for a pipeline to run or an environment to reset. That leads to fewer surprises once you do publish. So while “temporary URL” might be the simplest way to describe a Dev Tunnel, it barely scratches the surface. In Microsoft 365 development, they’re more like an on-demand extension of your developer environment into the outside world—one you can control down to the visibility, authentication, and lifespan. They’re not a side tool. They’re the connective tissue that makes secure, rapid iteration and real collaboration possible without blowing up your schedule in deployment waits. And once you see them as that kind of infrastructure, the next question is pretty clear—how do you switch them on without wrecking the setup you already depend on?

Enabling Dev Tunnels in Visual Studio Without Breaking Your Setup

The first time you switch on a tunnel in Visual Studio, it feels almost effortless. A couple of clicks, and suddenly your dev box is reachable from anywhere. But that’s also when you notice your localhost SSL prompt breaking, your configured URLs no longer lining up, or your OAuth redirect URIs throwing errors. The magic moment turns into a head‑scratch fast if you’re not intentional about the setup. Starting from a clean project, enabling a tunnel is straightforward. Open your solution, go to the project node in Solution Explorer, right‑click, and choose Properties. In web‑friendly projects, you’ll see a Debug tab. That’s where the Dev Tunnel option lives. Click the checkbox to enable a tunnel, and Visual Studio will prompt you for a tunnel name and scope. This is where most people just type something quick and hit Enter. But what you name and how you scope it will shape how your tunnel behaves later—especially when testing Microsoft 365 apps. By default, Visual Studio tends to pick a public visibility option if you don’t change it. That means anyone with the link can hit your endpoint. For a throwaway demo, maybe that’s fine. But if your project has authentication flows linked to an internal tenant or exposes an API behind that tunnel, you’ve effectively given the internet a way in. It’s all too common to see developers click through this without realizing they’ve left the door wide open. In the visibility dropdown, you’ll see choices like Public, Public (authenticated), and Private (authenticated). Pick carefully—this isn’t just a label. For a Microsoft 365 Teams app that uses Entra ID, choosing an authenticated tunnel keeps your audience to those who can sign in with valid credentials. That makes accidental data exposure much less likely. Once you’ve chosen scope, give your tunnel a clear and reusable name. This isn’t just cosmetic. If you use a consistent subdomain—for example, `myteamsapp.dev.tunnels.ms`—you can avoid constant adjustments to registered redirect URIs in Azure AD app registrations. OAuth callbacks are sensitive to exact URLs. If your tunnel address changes every test session, you’ll spend half your day in the Azure Portal re‑registering redirect URLs. Locking in a persistent tunnel name avoids that churn entirely. Visually, the setup page is simple. Under the Dev Tunnel section, type your name, pick the scope, and hit “Apply.” Visual Studio will then spin up the tunnel the next time you debug. You’ll see a network forwarding table in the Output window showing your local port mapped to the `.dev.tunnels.ms` address. But here’s something that trips up a lot of people: if you’re running IIS Express and enable a tunnel mid‑session, Visual Studio often restarts the web server. That restart kills your breakpoints for the current debugging run. If you were halfway through tracking down a tricky state bug, it’s frustrating to start over. The fix is simple—enable the tunnel before you start debugging. That way, the process starts in its final state, and your breakpoints hold as expected. For multi‑port projects—say, you’ve got an API backend and a front‑end app—Visual Studio can only tunnel one port per project by default. If you need both exposed, you’ll have to either run them in separate projects with their own tunnels or use the CLI later for advanced config. Understanding this now helps you plan your debugging session without surprises. Once configured, running your project now serves it both on `localhost` and via the external tunnel link. You can send that link to a colleague, paste it into your Teams configuration, or register it in your SharePoint Framework `serve.json` pointing to the externally accessible address. And because you set the visibility right, you know exactly who can reach it. Done this way, a tunnel doesn’t disrupt your local SSL setup, it doesn’t kill your debugging context, and it doesn’t require repeated redirect URI edits. It just adds a secure, shareable endpoint on top of your normal workflow. That’s the sweet spot—a transparent addition to your process, not a new set of headaches. Once you’ve got the tunnel running smoothly like this, the next big decision is the type of tunnel you choose—because that choice decides whether your remote testers are in a locked‑door environment or walking straight in off the street.

Choosing Between Public Anonymous and Private Authenticated Tunnels

Choosing the wrong tunnel type is basically like handing a stranger the keys to your office and hoping they only look at the thing you invited them to see. When Visual Studio prompts you to pick between Public Anonymous, Public Authenticated, and Private Authenticated, it’s not just a formality. Each choice changes what someone on the other end can do and how easily they can get in. Public Anonymous is the fastest to set up. You create the tunnel, share the URL, and anyone with the link can hit your endpoint. There’s no sign‑in, no extra step for the tester. That speed is appealing during something like a hackathon, where your biggest concern is getting an early proof of concept in front of judges or teammates. You’re moving fast, the code is throwaway, and there’s no sensitive tenant data involved. Public Authenticated takes that same open link but requires the user to log in with a Microsoft account before they can see your app. It’s a middle ground—good if you want to keep out completely anonymous access but don’t need to lock things to a single identity provider or narrow group. You’re adding a speed bump without fully closing the gate. Private Authenticated is where you define a specific audience. Your testers have to authenticate, and they have to be in whatever group, tenant, or directory you’ve allowed. In the Microsoft 365 context, this often means they must sign in with an account in your Microsoft Entra ID tenant. That instantly cuts down who can see your app, and it ties access to an identity you already manage. If someone leaves your project or company, disabling their Entra ID account means their tunnel access disappears too—no separate cleanup needed. Here’s where developers get tripped up. It’s common to default to Public Anonymous during early development because it’s frictionless. But if your code references internal APIs, even unintentionally, or your Teams app renders content from secure Graph endpoints, you’re exposing more than just a demo UI. That link could become an easy target for automated scanners or bots that sweep public URLs. Even if you think the risk is low, you have no visibility into who might be poking around. Think about it in scenarios. At a hackathon, speed wins. You’re showing features, not production data, so Public Anonymous might be fine for those 24 hours. Compare that to pre‑release enterprise testing for a Teams app that’s wired into a finance system. In that case, Private Authenticated should be the default. Only invited testers can sign in, and their activity is logged through your normal Microsoft 365 auditing. When deciding, break it into three questions: Who exactly needs to access this? What kind of data will they see or interact with? Do I need to verify their identity before they can connect? If the answers are “a small known group,” “potentially sensitive business data,” and “yes,” then Private Authenticated isn’t optional—it’s mandatory. If it’s “anyone,” “sample data only,” and “no,” then speed might win out with Public Anonymous, but you make that trade‑off consciously. Entra ID integration is what makes Private Authenticated so strong for M365 work. It’s not just another login screen—it’s your tenant’s directory, with multi‑factor authentication and conditional access policies baked in. That means even in a tunnel context, you can enforce the same trust level as your production systems. Testers get in the same way they would access company resources, and you don’t have to invent a separate credential system for dev testing. The security gap between public and authenticated options is bigger than most people assume. Public mode—anonymous or even with basic Microsoft account sign‑in—still faces the risk of targeted attacks if the URL gets shared or discovered. Authenticated tunnels tied to your directory shrink that risk to a controlled tester pool, and since every request is tied to a real account, you gain accountability. Once you start thinking this way, picking a tunnel type stops being a “just click the first one” step and becomes part of your security posture. You’re no longer reacting after something gets exposed—you’re defining access at the moment you open the connection. And with that in place, the next logical step is figuring out how to create, manage, and reuse those exact configurations without manually clicking through Visual Studio every time. That’s where the CLI completely changes the game.

Taking Control with the Dev Tunnels CLI

The Visual Studio UI works fine when you’re setting up a single tunnel on your own machine. But if you’re trying to mirror that exact tunnel on multiple laptops, or spin one up from a build agent in seconds, the clicking becomes a bottleneck. That’s where the Dev Tunnels CLI starts to pull its weight. It gives you the same underlying tunnel service that Visual Studio uses, but with the repeatability and scripting control that’s hard to match in a GUI. Most developers never open the CLI, so they miss out on a lot of practical capabilities. The UI is tied to the project you have open, which feels natural until you want a tunnel for something outside of Visual Studio or you need to reuse the same port without re‑configuring. The CLI doesn’t have those limits. You can start a tunnel without loading an IDE, you can standardise naming conventions, and you can automate the whole process so it’s consistent across every environment. If you’ve never touched it before, the CLI approach is straightforward. Once you’ve installed the Dev Tunnels tool, creating a new tunnel is a single command. For example, `devtunnel create myteamsapp --port 3000 --allow-unauthenticated` will set up a new tunnel called “myteamsapp” forwarding port 3000 with anonymous access. From there, `devtunnel list` shows all your active and saved tunnels, along with their URLs. To start one, you use `devtunnel host myteamsapp`, and the service comes online instantly. The naming here is more than cosmetic. Consistent names translate to consistent URLs, which is critical for any Microsoft 365 app that has registered redirect URIs or webhook endpoints. One wrong character in a callback URL, and your auth flow fails silently. With the CLI, you can define those names once and know that every developer on the team will get the same outcome. Config files make this even smoother. You can store tunnel settings—name, port, authentication type—in a JSON file alongside your code. When a new developer joins the project, they run one command against that file, and their tunnel matches the rest of the team’s setup immediately. There’s no “go click here, then here, then change this dropdown” walkthrough. No step is left to memory. This standardisation is where larger teams see real gains. Imagine onboarding three contractors into a Teams app project. Instead of each person fumbling through UI settings, they all run `devtunnel create --config devtunnel.json` and have the exact same environment in under a minute. That removes a whole category of “it works on my machine” problems before they start. The CLI also opens the door to using Dev Tunnels in CI/CD pipelines. If your automated build runs integration tests that rely on an external callback—maybe a Teams messaging extension that needs to call your dev API—you can have the pipeline spin up a tunnel automatically during the job. The build agent hosts it, the tests run against the real endpoint, and when the job finishes, the tunnel is torn down. You get end‑to‑end testing with live callbacks without exposing anything permanently to the internet. For local debugging, this flexibility means you’re not tied to having Visual Studio up and running just to serve traffic. You can host the backend through the CLI, then hit it from your front‑end app that’s running in another dev tool entirely. That makes it easier to test scenarios where one part of the solution is in .NET and another is in Node, without forcing both into the same debugging session. And because the CLI can reuse previous tunnels without changing URLs, your OAuth and webhook registrations stay valid between runs. All of this adds up to a key point: the CLI isn’t just for people who dislike GUIs. It’s for anyone who needs repeatability, speed, and environment parity without relying on manual clicks. Once you’ve got a set of tested CLI commands, you can share them in your repo’s README, embed them in npm scripts, or wire them into PowerShell build routines. That’s a level of control and consistency you simply can’t get if every tunnel is created from scratch by hand. When you’re working this way, tunneling stops being an occasional tool and becomes part of the core workflow. Every machine can host the same configuration, automation can stand up tunnels in seconds, and you can scale testing to more people without slowing down setup. But with that power comes responsibility—because once your tunnels are this fast to deploy, you need to be deliberate about how you protect them from the moment they come online.

Locking It Down: Avoiding Common Security Mistakes

One missed setting can turn your dev box into an open buffet for attackers. It’s not an exaggeration—Dev Tunnels are essentially internet-facing endpoints into whatever you’re running locally, and if you treat them like a casual “share” link, you’re handing out access without tracking who’s walking through the door. The most common mistakes keep repeating. Developers spin up a tunnel and leave it at the default visibility—often Public Anonymous—without considering that the link may travel further than intended. Or they finish testing, close their laptop, and forget the tunnel is still running hours later. In some cases, tunnels stay accessible overnight with services still responding. And then there’s weak authentication—using accounts without MFA or handing access to people outside a controlled tenant. The pattern is predictable: speed wins in the moment, and security gets added “later.” It doesn’t take much for a small oversight to snowball. Picture this: a local API behind a public tunnel helps test a Teams messaging extension. That API trusts calls from Graph with a certain token. An attacker probing randomly finds your tunnel’s URL, hits a less protected endpoint, and extracts some internal IDs. Those IDs get used to craft an authenticated request upstream. Now you’ve got a compromised API key tied back to your connected M365 tenant. From one missed scope change to a potential breach—without you ever realising someone outside your circle connected. I’ve seen log snippets where exposed tunnels started receiving GET requests from IP ranges in regions the developer had no connection to. Patterns like `/wp-login.php` and `/phpmyadmin` litter the logs—a clear sign someone’s scanning for common admin pages. None of those existed on the dev box, but the noise made it harder to spot requests that actually mattered. If there had been a real vulnerable endpoint, the story could have ended differently. This is why the principle of least privilege applies as much here as it does to any cloud role assignment. Open as little as possible for as short a time as possible. If you only need port 3000 for a Teams client test, don’t forward your entire web stack. Limit visibility to a specific tenant or authorised accounts. And the moment testing is done, shut it down—don’t leave the channel open “just in case.” Microsoft Entra ID plays a big role here for M365-focused work. If you set your tunnel to Private Authenticated and tie it to your Entra ID tenant, you immediately raise the bar for access. Multi-factor authentication can kick in for testers. Conditional access policies can require devices to meet compliance before they connect. It’s the same trust layer you’d rely on for production resources, applied to your ephemeral dev endpoint. That’s far more effective than a random password or relying on an unvalidated public login. Logging and monitoring can feel like overkill for something temporary, but it pays off the first time you need to verify whether a tester actually saw the latest build or if a strange request came from your team or from outside. Tunnel logs give you request timestamps, source IPs, and hit endpoints. Pair them with your app logs, and you get a timeline you can actually trust. In a sensitive test cycle, that record is your safety net. At a practical level, locking things down means having a short checklist you run through every time you start a tunnel: set the correct visibility, verify the authentication mode, confirm only the necessary ports are forwarded, and plan a clear stop time. If your work takes more than one session, reuse named tunnels with fixed URLs instead of rebuilding them publicly each day—especially if that rebuild defaults to open access. The goal isn’t to make tunnelling cumbersome—it’s to make it conscious. When security settings are part of your standard flow, you stop treating them as an “extra” and start treating them like the foundation. That’s how you avoid the feeling of “it was only supposed to be a quick test” becoming “we might have just leaked production data.” Once you bake those habits into your workflow, Dev Tunnels stop being a casual risk and start being a reliable part of your testing pipeline. Which brings us to the bigger picture—how they fit strategically into how you build and collaborate in Microsoft 365 without slowing down delivery.

Conclusion

Dev Tunnels aren’t just a handy trick to skip deployment—they’re a bridge that connects your local code to real users securely when you configure them with intention. In Microsoft 365 projects, that means faster collaboration without taking shortcuts that weaken security. For your next Teams, SharePoint, or Power Platform build, try starting with a private, authenticated tunnel tied to your tenant. You’ll keep control while giving testers the same experience as production. Next time, we’ll look at pairing tunnels with automated Teams app testing pipelines—so your local changes can be validated end‑to‑end without ever leaving your development environment.

Get full access to M365 Show - Microsoft 365 Digital Workplace Daily at m365.show/subscribe

Mirko Peters

Founder of m365.fm, m365.show and m365con.net

Mirko Peters is a Microsoft 365 expert, content creator, and founder of m365.fm, a platform dedicated to sharing practical insights on modern workplace technologies. His work focuses on Microsoft 365 governance, security, collaboration, and real-world implementation strategies.

Through his podcast and written content, Mirko provides hands-on guidance for IT professionals, architects, and business leaders navigating the complexities of Microsoft 365. He is known for translating complex topics into clear, actionable advice, often highlighting common mistakes and overlooked risks in real-world environments.

With a strong emphasis on community contribution and knowledge sharing, Mirko is actively building a platform that connects experts, shares experiences, and helps organizations get the most out of their Microsoft 365 investments.

Visual Studio Dev Tunnels: Test Microsoft 365 Apps from Localhost