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 SetupThe 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 TunnelsChoosing 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 judge
Become a supporter of this podcast: https://www.spreaker.com/podcast/m365-show-podcast--6704921/support.
