Claim your Google Cloud Credits in Google AI Studio

We shipped servicing releases for all three supported SqlClient lines: 7.1.2, 7.0.4 and 6.1.8. They pick up a dependency security fix, tighten certificate validation, and fix several bugs.

Check your HostNameInCertificate values

HostNameInCertificate tells SqlClient which name to expect in the server's TLS certificate. You use it when the name you connect to isn't the name on the certificate, for example when you connect by IP address, through an alias, or through a load balancer:

var connectionString = "Server=10.0.0.20;Database=Sales;" + "Encrypt=Mandatory;HostNameInCertificate=sql01.contoso.com;" + "Integrated Security=true";

In earlier versions, SqlClient used HostNameInCertificate only when the server name in Data Source didn't match the certificate. If the server name matched, a wrong HostNameInCertificate was ignored and the connection opened.

Starting with these releases, a HostNameInCertificate value replaces the server name for certificate validation. If the value isn't in the certificate, the connection fails, even when the server name matches.

We tested this against Azure SQL Database and SQL database in Fabric with a deliberately incorrect value for HostNameInCertificate:

In 6.1.8, the stricter check applies only to managed networking. Managed networking is the default on Linux and macOS. On Windows you opt in to it.

To check your applications, search your connection strings and configuration for HostNameInCertificate. For each value, confirm the name appears in the server certificate's subject or subject alternative names. If it doesn't, fix the value or remove it. A wrong value now fails with a certificate name mismatch error during the TLS handshake, before login.

Security updates

All three releases raise dependency minimums to address CVE-2026-84008. System.Security.Cryptography.Pkcs moves to 8.0.2 on .NET Framework, .NET 8, and .NET Standard 2.0. On .NET 9, the Microsoft.Extensions and System packages move to 9.0.21.

If your project references any of those packages directly, raise those references to at least the same versions.

The releases also isolate Always Encrypted enclave sessions by attestation protocol. A connection that asks for one attestation protocol no longer reuses a cached enclave session created with a different one.

Clearer errors for Entra sign-in on windowless hosts

Active Directory Interactive authentication on Windows uses the Web Account Manager (WAM) broker, and WAM needs a parent window. A host with no window, such as an Azure Functions local worker or a Windows service, used to fail with a bare MSAL window_handle_required error.

The error message now tells you what to do instead:

• If your app has a window, pass its handle with SetParentActivityOrWindowFunc.
• If your host has no window, use Active Directory Default with a non-interactive credential, such as a managed identity or environment credential.
• To sign in interactively without WAM, set your own ApplicationClientId and turn off UseWamBroker.

This guidance is in Microsoft.Data.SqlClient.Extensions.Azure 7.1.2 and 7.0.4, and in Microsoft.Data.SqlClient 6.1.8.

Bug fixes

These fixes apply to all three releases unless noted:

• SqlDataReader.HasRows returned false for a result set that had rows when several informational messages, such as PRINT output, arrived before the first row.
• Statistics bookkeeping could throw InvalidOperationException with "Nullable object must have a value." In 6.1, this was a regression starting with 6.1.4 that showed up on MARS connections.
• A malformed PRELOGIN response from a server or proxy threw IndexOutOfRangeException from Open. It now fails with the corrupted-stream error, and malformed row and authentication responses close the physical connection so it can't return to the pool. (7.1.2 and 7.0.4)
• Closing a managed networking connection while MARS was still receiving could raise unobserved task exceptions. (7.1.2 and 7.0.4)
• On Linux and macOS, SqlClient no longer tries to load the Windows native networking library, which could throw DllNotFoundException. (7.1.2)
• Entra authentication now works when the server returns an authority URL with an OAuth endpoint suffix, such as /oauth2/authorize. Dataverse and Dynamics 365 return this form. (6.1.8)

Upgrade

Install the release for your line:

dotnet add package Microsoft.Data.SqlClient --version 7.1.2 dotnet add package Microsoft.Data.SqlClient --version 7.0.4 dotnet add package Microsoft.Data.SqlClient --version 6.1.8

 

In 7.0 and 7.1, the companion packages ship with the same version number. If you reference them, update them to the same version as the driver:

• Microsoft.Data.SqlClient.AlwaysEncrypted.AzureKeyVaultProvider
• Microsoft.Data.SqlClient.Extensions.Azure
• Microsoft.Data.SqlClient.Extensions.Abstractions
• Microsoft.Data.SqlClient.Internal.Logging

Upgrading from 7.1.1 or 7.0.3 doesn't need new .NET Framework binding redirects.

Read the full release notes for 7.1.2, 7.0.4, and 6.1.8.

For more about certificate validation, see Encryption and certificate validation

Microsoft Ignite returns to San Francisco November 17–20, bringing together developers, data professionals, and technology leaders. Whether you’re modernizing an existing SQL estate or building your next AI application, our sessions offer a practical path through the week—from architecture and migration decisions to hands-on development. Here’s what to add to your agenda.

Tuesday, November 17: Bring AI and agents closer to your data 

Start with No Cloud Required: Build AI apps with SQL Server on Azure Local (BRK450). Join Bob Ward as he explores how to bring SQL and local AI to sovereign, regulated, edge, and disconnected environments while keeping sensitive data within trusted boundaries.

 

Then join Less Hunting, More Building: Database Agents in a Unified Estate (BRK363). See how Database Hub and database agents can help teams surface issues, understand likely causes, and act with human approval using familiar SQL tools.

 

Onsite? Make sure you join us in the Hub and look for the AMD booth during the evening recaption for an exclusive book signing for Bob Ward’s latest book “SQL Hyperscale Unveiled”

 

 

 

 

 

 

 

Wednesday, November 18: Build the foundation—and go deeper

Start your day with Data foundations for modern apps, AI, and agents (BRK362). Join Shireesh Thota together with leaders across Azure Databases as they share how operational, analytical, relational, and NoSQL platforms work together to support modern applications and agents.

Follow that up by going deeper into SQL’s cloud-native offering Hyperscale in Humans to agents: Mission-critical starts with Azure SQL Hyperscale with Bob Ward and Anna Hoffman. This session is designed to explore the architecture, scale, resilience, and AI capabilities behind production-ready applications.  

Short on time?  Catch Data modernization decision tree for growing businesses* a 15min lightning talk with Bob Ward, for a practical guide at SQL Server migration choices,

Learn how to Ship database changes faster with agents in Database Hub or bring your questions and join the conversation with VP of SQL Priya Sathy at our table talk, spots are limited, so make sure you add it to you schedule and get there early.

 

 

 

Thursday, November 19: Choose your architecture and build what’s next

Not all applications are created equal, which makes choosing the right database critical. But how do you cut through the noise and pick the right solution for your application workloads? Database SOS: Choosing the right engine for your job will help teams weigh the options across Azure’s database portfolio.

Or maybe SaaS deployments are more your speed? Join Anna as she shares how to ground your agents on operational data and connect your agentic applications to analytics in one platform in:  Where agents meet analytics: Build with SQL Database in Fabric.

Why run SQL on Azure? Priya Sathy, VP of SQL, shows you in a demo-heavy session on what sets Azure apart as your data platform for modern, AI-ready apps: Why Azure is the best cloud for SQL.

Close out your day with Bob and Anna as they pull back the curtains and share the SQL roadmap, see what’s next in Sneak peek: What's next in SQL.

 

 

 

 

Friday, November 20: Simplify your DevOps

Close the week with BRK373, Build AI-ready apps on Azure SQL with GitHub Copilot in VS Code. Follow an application from local prototype through database design, retrieval-augmented generation, API creation, and cloud deployment.

 

All week: Go one step further with technical skilling

Lab Building search for AI apps and agents with Azure SQL Database, is planned across multiple days, including Friday. Check the schedule builder for its available lab times and to confirm your final agenda.

From SQL Server and Azure Local to Azure SQL Database, Hyperscale, and SQL database in Fabric, there’s a session for wherever you are in your data journey. Explore the full Ignite schedule and we’ll see you there!

Less than you might fear. You don't change a line of C#, and you don't touch your workflow definitions. The work is retargeting your projects, resolving a couple of dependency conflicts, running the right host locally, and changing a handful of app settings in Azure. Those last two are where people get stuck, so I spend most of this post on them.

This is a companion to Logic Apps Standard custom code now supports .NET 10. That post covers custom-code (local function) projects. This one covers NuGet-based applications and the custom built-in connectors they consume, and it answers the questions you left in the comments on the custom code post. We validated every step below end to end, locally and in Azure, with a NuGet-based sample app and a custom built-in connector.

Which post do you need?

Your code stays the same

Your code don't change. Keep the [assembly: WebJobsStartup] attribute, your IWebJobsStartup.Configure method and your IServiceOperationsProvider implementation exactly as they are. Your workflow definitions don't change either. You don't add an isolated worker project or a Program.cs file.

We validated this with a sample custom built-in connector that exposes an action, locally and in Azure. That tells you the model works. It doesn't tell you your connector works. Your connectors and their dependencies still need application-specific testing, and I come back to that in the limitations section.

First, understand which host runs your app

A connector built for net10.0 needs a .NET 10 host. The .NET 8 host can't load it: every type fails with a missing System.Runtime 10.0.0.0 reference. So the whole migration comes down to two things: building for net10.0, and making sure a .NET 10 host runs the result.

Azure and your local tools choose that host in different ways, and this is the part that catches people out:

dotnet-isolated doesn't move you to the isolated worker model. The Workflows runtime and your connector still load into the host process; the value only changes which host Core Tools starts. That's also why it's a local-only value. Keep it out of your Azure app settings and deployment templates. This is a current limitation of the the extension and we are working to remove this extra configuration step.

Check your prerequisites

• The .NET 10 SDK, version 10.0.403 or later. The Azure Logic Apps (Standard) extension for VS Code, version 5.1013.4, installs it in the extension's managed dependencies folder. On Windows the default is %USERPROFILE%\.azurelogicapps\dependencies\DotNetSDK.
• Azure Functions Core Tools 4.16.0 or later, the first version whose main host runs on .NET 10. The extension installs a managed copy in %USERPROFILE%\.azurelogicapps\dependencies\FuncCoreTools. An older copy installed through npm and earlier on your PATH (4.12.0 in our testing) runs on .NET 8 and fails to start the app.
• Microsoft.Azure.Workflows.WebJobs.Extension 1.170.91 or later. The current version at the time of this post on NuGet is 1.194.31, which is the version we validated. Use the latest version you have available as it will have the latest product improvements and fixes.
• Microsoft.NET.Sdk.Functions 4.5.0 or later. We validated 4.5.0 and 4.6.0.
• Write access to the package feed where you publish your connector packages.
• A build agent image with the .NET 10 SDK for your pipeline.

Keep your current deployment stable while you migrate

If your app runs on .NET 8 today, leave its app settings alone until your .NET 10 build is validated and ready to deploy. Retaining the existing app settings preserves the current compatibility configuration while you prepare and validate the migration. For NuGet-based apps, that includes LOGICAPP_INPROC_REDIRECT=1, the setting that keeps your app on the legacy .NET 8 in-proc host. Remove it early and the app moves to the new host on its next restart, before your .NET 10 build is in place.

Check your pipelines too. A release that rebuilds app settings from a template can drop the redirect without anyone noticing.

Don't treat this as a reason to wait. .NET 8 apps keep running after end of support, but they no longer receive security fixes. Plan the migration now.

Update your project files

Work on a branch, and back up any local configuration before you start. This table lists every file that changed in our validated migration. Repeat the connector changes for every connector project your app consumes.

Pin the SDK

Update global.json in the repository root and in the Logic Apps project folder:

{
  "sdk": {
    "version": "10.0.403",
    "rollForward": "latestPatch"
  }
}

Retarget the connector and resolve downgrades

Restore is where the first failure shows up. In our sample, retargeting the connector with Workflows 1.194.31 produced NU1605 package downgrade errors, and two direct references fixed them:

  
    net10.0
    true
    Contoso.LogicApps.Connectors.Inventory
    2.0.0
  
  
    
    
    
    
  

Those were the right pins for our connector's dependency graph. Yours may need different ones, so read the NU1605 output and pin what it names rather than copying ours. If restore also reports vulnerability warnings, review them; don't suppress them as part of the migration.

Then build, pack, and publish the new version to your feed:

dotnet build -c Release
dotnet pack -c Release -o ./nupkg
dotnet nuget push ./nupkg/Contoso.LogicApps.Connectors.Inventory.2.0.0.nupkg --source 

If your Logic Apps project references the connector as a project reference rather than a package, skip the pack and push. The retarget and the dependency fixes still apply.

Retarget the Logic Apps project

The relevant parts of the project file:

<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>net10.0</TargetFramework> <AzureFunctionsVersion>v4</AzureFunctionsVersion> </PropertyGroup> <ItemGroup> <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="4.5.0" /> <PackageReference Include="Microsoft.Azure.Workflows.WebJobs.Extension" Version="1.194.31" /> <PackageReference Include="Contoso.LogicApps.Connectors.Inventory" Version="2.0.0" /> </ItemGroup> <!-- Keep your existing None/Update items and CopyDynamicLibraries target. --> </Project>

Don't remove Microsoft.NET.Sdk.Functions. It generates bin\extensions.json, which registers your connector with the host. Without it, the connector is missing from the build output.

A NuGet-based app loads the Workflows runtime from your package, not from an extension bundle, so host.json needs no bundle:

{ "version": "2.0" }

Version 5.1013.4 of the extension have a configuration bug. It is ignoring the following extension configuration set:

"azureLogicAppsStandard.enableProjectConsistencyChecks": false

With that your host.json file will include the extension bundle setting again when the project opens:

  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  }

Remove it before pushing to source control or running the application. We are working on a fix for this issue which will ship with the next version of the bundle.

Why a net8.0 package works in a net10.0 project

Microsoft.Azure.Workflows.WebJobs.Extension targets net8.0. That doesn't stop a net10.0 project from referencing it: NuGet treats net10.0 as compatible and selects the package's net8.0 assets. What has to be .NET 10 is the host that runs your app.

There's one side effect worth knowing about. On net10.0, the SDK resolves the package's ASP.NET Core framework reference to version 10, which already contains Microsoft.Extensions.DependencyInjection and related assemblies, so the build leaves the package copies out of your output. That's expected. The .NET 10 host supplies them, which is one more reason the app only runs on that host.

Run and verify locally

Set the worker runtime in local.settings.json and keep your other values as they are:

{
  "IsEncrypted": false,
  "Values": {
    "FUNCTIONS_WORKER_RUNTIME": "dotnet-isolated"
  }
}

• Make sure Core Tools 4.16.0 or later is the func that runs. If you start the host from a terminal or a script, check that the managed copy, not an older npm install, comes first on your PATH. The version banner tells you which one started.
• Stop the host serving this project if it's running, then restore and build the Logic Apps project.
• Start the host from bin\Debug\net10.0.
• Check the host log. There should be no '/serviceProviders/' ... is not valid error, and your workflows should be listed.
• Run a workflow for every operation you ship, triggers included, and check the run history.
• Optionally, open a workflow in the designer, select Built-in, and confirm your connector's operations appear.

You may see Could not find the .azurefunctions folder in the deployed artifacts of a .NET isolated function app in the log. It's a warning that comes with the dotnet-isolated selection, and the workflows still run.

Update the Azure app settings

In Azure, the platform selects the .NET 10 host when LOGICAPP_INPROC_REDIRECT is absent, and FUNCTIONS_WORKER_RUNTIME stays dotnet. These are the settings we changed and the ones we left alone:

The extension bundle settings are the easiest to miss. Apps created in the Azure portal usually get them by default. If either is present, the host loads the Workflows runtime from the bundle instead of your package, your connector never registers, and the log reports that '/serviceProviders/' is not valid. Your deployed package can be perfectly correct and still fail this way.

Keep your deployment template at dotnet as well, and make sure it doesn't add the bundle settings or the redirect back on the next release.

Deploy and verify in Azure

1. Update your pipeline to build with the .NET 10 SDK, publish a Release build, and deploy the contents of bin\Release\net10.0\publish.
2. Deploy to a non-production app or deployment slot first.
3. For an existing app, stop it, change the app settings, deploy the .NET 10 package, and then start it. In that order, the new package never starts under the old configuration.
4. Check the host log for the '/serviceProviders/' ... is not valid error. It shouldn't be there.
5. Confirm that each workflow that uses your connector shows its callback URL, and that a test run succeeds.
6. Optionally, open Process Explorer in Kudu and confirm the loaded modules: CoreCLR 10, your connector DLL at its new version, and the Workflows runtime at 1.194.31. That's the reliable way to see which runtime is running, because the settings don't tell you.
7. Compare run history with the .NET 8 version, then promote the same build and the same settings to production.

A local settings file doesn't configure the Azure app. After each deployment, check the app settings on the deployed resource rather than trusting the template.

If you need to roll back, redeploy the .NET 8 package and restore LOGICAPP_INPROC_REDIRECT=1. Restoring the setting on its own isn't enough, because the .NET 8 host can't run a .NET 10 connector.

Symptoms and causes

If something fails, start here. These are the errors we hit during validation:

Use the migration skill

We've prepared the logicapps-nuget-connector-net10-migration skill to guide a coding agent through the same process. It inspects your solution, plans configuration changes before applying them, and guides build and test verification. It preserves your connector code and workflows rather than rewriting them, and it doesn't change Azure resources: it lists the app-setting changes for you to make.

The skill is available in the custom-connector-migration-net10 repository, with a working sample. The main branch holds the migrated .NET 10 version and the net8.0 branch holds the .NET 8 baseline, so you can try the skill on the sample before your own projects.

With GitHub CLI (command-line interface) version 2.90.0 or later, inspect the skill and install it for Copilot across projects. These skill commands are currently in preview.

gh skill preview wsilveiranz/custom-connector-migration-net10 logicapps-nuget-connector-net10-migration
gh skill install wsilveiranz/custom-connector-migration-net10 logicapps-nuget-connector-net10-migration --agent github-copilot --scope user

Installation makes the skill available to Copilot; it doesn't run the migration. After installation, you can ask your agent:

Migrate this NuGet-based Logic Apps Standard app and its custom built-in connector to .NET 10 using the logicapps-nuget-connector-net10-migration skill. Preserve my connector code and workflows, back up the projects first, and list the Azure app settings I need to change.

Note: we're submitting this skill to Awesome Copilot. When it's available there, we'll update this post with the new install commands.

Your questions, answered

Do I need to change how my custom built-in connector registers?

No. The existing registration model remains applicable: retain your IWebJobsStartup registration and IServiceOperationsProvider implementation. We validated a custom built-in connector with this model on the .NET 10 host, locally and in Azure. Your connectors and their dependencies still need application-specific testing.

Microsoft.Azure.Workflows.WebJobs.Extension targets net8.0. Can a net10.0 app reference it?

Yes. The package's net8.0 target doesn't prevent a net10.0 application from referencing it. A target framework isn't a requirement that the consuming application use exactly that framework. What does have to be .NET 10 is the host that runs your app. You still need to validate dependency compatibility, and restore tells you where to look.

I'm already on 1.194.31. Do I need to downgrade to 1.170.91?

No. 1.194.31 is newer than the 1.170.91 minimum in our migration guidance, and it's the version we validated. Stay where you are.

Do I need to move to the isolated worker model?

No. You don't add a worker project or a Program.cs file, and your connector still loads into the host process. dotnet-isolated is only the value that makes Core Tools start its .NET 10 host on your machine. In Azure, FUNCTIONS_WORKER_RUNTIME stays dotnet.

What should I do with my existing .NET 8 deployment in the meantime?

Keep its existing app settings. They preserve the current compatibility configuration while you prepare and validate the migration. Remove LOGICAPP_INPROC_REDIRECT when you deploy the .NET 10 package, not before.

When will the official documentation cover NuGet-based apps and custom built-in connectors?

We know you need explicit guidance for this scenario, and this post is that guidance today. We don't have a confirmed publication date for the Microsoft Learn update. Don't wait for it: migrate to .NET 10 at your earliest opportunity.

Before you migrate: what we haven't covered

• We validated a sample connector with an action, not yours, and not a connector with triggers. Connectors that implement IServiceOperationsTriggerProvider, connectors with their own converters, and connectors with third-party libraries that pin older framework versions are where I'd expect surprises. Test every operation.
• We haven't validated an app that combines a NuGet-based project with a custom-code project.
• In our sample, the generateDebugSymbols prelaunch task in VS Code failed, because it looks up an extension bundle path and a NuGet-based project doesn't have one. Don't add a bundle to work around it; start the host from bin\Debug\net10.0 instead. We are working on a fix for this problem.
• The Microsoft Learn article Create custom built-in connectors for Standard workflows still describes a .NET Core 3.1 class library project. Until it's updated, use this post as the reference for the target framework.
• Don't pin your app to a specific extension bundle or Functions host version. Pinned apps needed manual updates during the out-of-proc migration, and they will again every time the platform moves.

Call to action

Retarget one connector this week and run it against a non-production app. If something fails, check the symptoms table first. If your error isn't there, post the connector shape (actions, triggers, converters), the package versions, and the error in the comments, without credentials or private data. I'll take the patterns back to the team and fold them into this post and the skill.

We're introducing support for Azure Container Apps Sandboxes in the Azure Container Apps extension for Visual Studio Code. The new experience brings sandbox groups and individual sandboxes into the Azure Resources view, putting everyday sandbox operations alongside your development workflow.

Instead of switching tools to create and manage sandbox resources, you can work with them directly in VS Code, see their current state, and follow operation results in the Azure output channel.

Your sandboxes, alongside your code

The new Container Apps Sandboxes node gives sandbox resources a dedicated home in the Azure Resources tree. Expand a sandbox group to find its sandboxes and see status labels such as Running and Stopped.

Start with Create Sandbox Group... and follow the guided workflow, including choosing an existing resource group or creating a new one. Once your sandbox group appears in the tree, right-click it and select Create Sandbox... to create a sandbox within that group.

The result is a straightforward path from creating a group to working with a running sandbox, all from your editor.

Execute commands without switching tools

With Execute Command in Sandbox..., you can run a command against a sandbox directly from VS Code. This brings command execution into the same resource-management experience you use to find and inspect your sandboxes.

 

Enter a command to run in the sandbox without leaving VS Code.

The Azure output channel reports operation results, helping you keep track of what happened without leaving the editor.

Create named snapshots

Use Snapshot Sandbox... to create a named snapshot of a sandbox. Snapshot creation is available alongside the other sandbox actions, so you can create a snapshot as part of your workflow rather than switching to a separate management tool.

 

Give your snapshot a name directly in the editor.

Stop and resume from the resource tree

Sandbox lifecycle controls are available directly in the extension:

• Stop Sandbox to stop a running sandbox.
• Resume Sandbox to resume a stopped sandbox.
• Delete Sandbox to remove a sandbox you no longer need.

Inline status labels make it easy to see the transition between running and stopped states. Operation results also appear in the Azure output channel.

 

Access sandbox actions from the resource tree.

Sandbox groups include familiar management actions such as Edit Tags..., View Properties, Open in Portal, and Refresh, as well as an option to delete a sandbox group.

Get started

To explore the new experience:

1. Install or update the Azure Container Apps extension to a release that includes Sandbox support, then sign in to Azure.
2. Open the Azure Resources view and find Container Apps Sandboxes under your subscription.
3. Use Create Sandbox Group... and follow the prompts to create a group.
4. Right-click the group and select Create Sandbox....
5. Explore command execution, named snapshots, and stop/resume controls from your sandbox's available actions.

Less context switching. More time in your development workflow. Azure Container Apps Sandbox support brings creation and day-to-day management into VS Code, right where you're already working.

Have feedback? Share it in the Azure Container Apps extension repository.

Episode 0036 - Edge + Hybrid Cloud: Building for Low Latency, Local Control, and Cloud Scale

The cloud is fast, but it cannot outrun physics or conjure an internet connection in the middle of the ocean. Carl and Brandon explore why latency, privacy, and unreliable connectivity push compute closer to the work. Chemical leak detection, robotics video, and financial trading show how local processing and cloud analysis serve different roles. The practical patterns keep real-time decisions and state local, then send insights or synchronize data when connectivity allows.

Cloud-native tools still fit at the edge, but containers do not erase the challenges of disconnected operation. Configuration twins, missed updates, and device retirement make compatibility and lifecycle management essential, while local compute still needs its own resilience plan. The trade-offs span central control versus autonomy, data residency, and hardware costs. Neither moving everything to the cloud nor putting Kubernetes at every site is a universal answer. Good hybrid architecture models reality: what must happen locally, what can wait, and what keeps working when the connection disappears?

Links

• Device twins: desired and reported state in Azure IoT Hub
• Azure ExpressRoute overview
• GitHub Actions self-hosted runners

Visit us at:

• twitter.com/CloudChatTech
• discord.cloudchat.tech
• cloudchatpodcast@gmail.com
• linkedin.com/company/cloudchat

Download audio: https://traffic.libsyn.com/secure/dfd84fca-7055-4605-98ce-3b0f8cbd6e15/cc-0036.mp3?dest-id=4423448