Episode Details

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 y