What’s new for small form factor infrastructure
At Microsoft Build, we introduced smaller form factor infrastructure in public preview. Today, we’re refreshing that preview with version 2607, available right now in the Azure portal. This release introduces several new features: Expanded support for multiple network interfaces (NICs) and additional disks Just-in-Time (JIT) device access through the new Connect experience Cloud-managed operating system updates and recovery using an A/B image model These new capabilities give operators greater flexibility in how edge devices are configured, accessed, and maintained throughout their lifecycle. Let’s look at what each capability delivers and what it looked like in practice when I deployed the release on an OnLogic Helix 521. Greater networking and storage flexibility Small form factor infrastructure now supports multiple network interfaces (NICs) and disks on a single device. To give you full control, each NIC appears natively in Azure Resource Manager (ARM) as a child resource of the Machine, which you can view and configure through Azure portal and Azure CLI. Distributed infrastructure often faces unique and challenging requirements: for example, a device on a factory floor may need one network for management traffic and a separate, isolated network for operational technology (OT) or workload traffic, while a retail or robotics deployment may need additional local storage for AI models, video, or sensor data that shouldn’t leave the site. Support for multiple NICs allows a single device to connect to more than one network for segmentation, redundancy, or reaching equipment on a dedicated segment, while support for additional disks lets customers size local capacity to the workload rather than constraining the workload to fit the device. From Azure, you can configure each network interface individually, applying values like IP address, DNS server, and more. Azure also automatically detects and flags configuration drift to help maintain consistency with the desired state. resolve. This is an exciting step forward since the initial preview. Previously, each device was limited to a single network path and its built-in storage, forcing customers to compromise on network separation, add external hardware, or offload data sooner than they would like. Now the same compact device can support real-world network topologies and larger local datasets, without stepping up to larger, more costly infrastructure. Together, these enhancements allow Azure Local devices to align more closely with real-world edge deployment requirements without requiring additional infrastructure. Secure access when you need it: Just-in-Time (JIT) access Connecting to a distributed edge device for maintenance has traditionally required a difficult trade-off. Troubleshooting a device requires administrative access and granting that access permanently means standing permissions that remain in place on the resource whether or not anyone is using them. Across a fleet of hundreds or thousands of devices, often deployed in physically exposed locations such as store back rooms, remote sites, or factory floors, those always-on credentials become a persistent and hard-to-audit part of the attack surface. Just-In-Time (JIT) access, delivered through the new Connect experience, eliminates standing access. Rather than holding permanent permissions, users are granted eligible roles through Microsoft Entra Privileged Identity Management (PIM) and activate them only when access is actually needed. Activation requires a business justification and administrator approval, is bound to a defined duration of up to eight hours and connects the user to the device over SSH using a short-lived certificate. When the window expires, the role is deactivated automatically. The result is a model where access is the exception rather than the default: every session is requested, justified, approved, time-bound, and logged. For organizations operating critical infrastructure at the edge, administrators retain the ability to reach any device the moment they need to, without maintaining persistent access on every device for the rest of the time. Simplified OS lifecycle management with A/B image updates Last month’s preview introduced a novel capability: provisioning a bare metal OS onto an edge machine from Azure. With 2607, we’re building on that capability with the capability to update a bare metal OS using an image-swap approach. Updates now use an A/B image-swap model, one of the most impactful reliability improvements in this release. The new image is installed on an inactive partition while the current operating system continues running. During reboot, the device switches to the updated image. If the new image fails to boot successfully, the device automatically rolls back to the last known-good version. This design keeps the risk of a failed update tightly contained. Because the update is staged in the inactive slot while the current image stays live, workload downtime is minimal, and because the previous image is always preserved, a failed update rolls back on its own rather than leaving a device stranded. Every device either comes up healthy on the new image or returns to the one that was working. For organizations managing thousands of devices in locations with no on-site IT, this safeguard can be very helpful because a failed update has historically been one of the most costly failures to recover from: a device that does not come back online can require a costly on-site visit or a physical replacement. Putting it to the test on an OnLogic Helix 521 To see how these capabilities come together in practice, I deployed the release on an OnLogic Helix 521, one of the validated small form factor devices for Azure Local. The Helix 521 is great for exercising the new networking features, with its I/O dense design featuring four Ethernet ports on its front side. These new features move small form factor infrastructure closer to what production edge deployments require: the flexibility to match real network and storage needs, access that is secure by default, and updates that can be rolled out across an entire fleet with confidence. To try preview version 2607 for yourself, visit Microsoft Learn for information about supported hardware and https://learn.microsoft.com/azure/azure-local/small-form-factor/small-form-factor-overview in Azure portal. The preview is free of charge and typically takes about an hour to set up.Episode 1: Onboarding Azure Arc at Scale | The Azure Arc Check-In
Once a month the Azure Arc team will release an episode covering a variety of topics. To request a topic or view additional episodes please visit: aka.ms/the-azure-arc-check-in Episode 1: Onboarding Azure Arc at Scale Scenario: Imagine your organization has 1,000 Windows and Linux servers spread across multiple locations. You want them all in Azure Arc, but first you need to deploy the Azure Connected Machine agent at scale. Try now in Azure aka.ms/aaci-episode1 Why onboarding strategy matters Interactive sign-in works well for testing and proof-of-concepts, but it quickly becomes impractical when you’re onboarding large server estates. At scale, organizations need a deployment model that can: Automate onboarding across many machines Align with existing management tooling Apply consistent configuration and governance from day one Minimize manual effort and human error This episode focuses on using non-interactive authentication and automation to onboard large server fleets efficiently. One of the key recommendations is to use a dedicated authentication mechanism designed for scale rather than relying on interactive administrator sign-ins. Onboard a Linux fleet with Ansible The Ansible deployment begins with an Ansible node that is already connected to Azure Arc. The deployment uses the credential on the Ansible node to deploy the Azure Connected Machine agent to the Linux fleet. To enable this, the managed identity of the Ansible node has the Azure Connected Machine Onboarding role in Azure assigned. Below are the steps for role assignment in the Azure portal: Open the resource group where the servers will be deployed. In Access control, add a role assignment. Select the Azure Connected Machine Onboarding role. Choose managed identities, select Machine - Azure Arc, and find the Ansible node. Review and assign the role. Configure the Ansible playbook With the permissions in place, the deployment uses three files: inventory.ini: Represents the machines configured by the playbook. arc-vars.yml: Contains non-secret configuration, including the resource group name, subscription and tenant IDs, location, and tags. arc-onboard.yml: References arc-vars.yml and configures the playbook to use managed identity, or MSI, for authentication. After the playbook runs, Ansible deploys the Azure Connected Machine agent to the Linux fleet. You can return to the resource group, refresh the view, and verify that your Linux machines appear as Azure Arc connected servers. Onboard Windows machines with Group Policy For Windows Server environments joined to Active Directory, Group Policy remains one of the simplest and most scalable deployment mechanisms. The process includes: Creating the required onboarding identity Preparing a shared location for deployment assets Downloading the Azure Arc GPO deployment package Generating a Group Policy Object with the required settings Linking that GPO to the appropriate organizational unit (OU) Allowing targeted servers to automatically onboard during policy refresh cycles For organizations that already manage Windows Server through Active Directory, this approach enables onboarding at scale without introducing additional management infrastructure. FAQs What is the best way to onboard servers to Azure Arc at scale? For large Windows and Linux server environments, use automated deployment with non-interactive authentication rather than signing in interactively on each machine. This approach lets you deploy the Azure Connected Machine agent consistently across many servers while reducing manual effort and human error. Azure Connected Machine Agent Deployment Options - Azure Arc Can I use Ansible to onboard Linux servers to Azure Arc? Yes. You can use an Azure Arc-enabled Ansible node to deploy the Azure Connected Machine agent across a Linux server fleet. In the approach demonstrated here, the Ansible node uses its managed identity, which is assigned the Azure Connected Machine Onboarding role, to authenticate the deployment. Connect machines to Azure Arc at scale using Ansible - Azure Arc Can I use Group Policy to onboard Windows servers to Azure Arc? Yes. Group Policy can automate Azure Arc onboarding for Windows Server machines that are joined to Active Directory. The process uses a Group Policy Object linked to the appropriate organizational unit, allowing targeted servers to onboard automatically during Group Policy refresh cycles. Connect machines at scale using Group Policy with a PowerShell script - Azure Arc What files are needed to onboard Linux servers to Azure Arc with Ansible? The Ansible deployment shown in this episode uses three files: inventory.ini to identify the target machines, arc-vars.yml to store non-secret configuration such as subscription, tenant, resource group, location, and tags, and arc-onboard.yml to run the onboarding playbook using managed identity authentication. Should I use Ansible or Group Policy for Azure Arc onboarding? Use Ansible when onboarding Linux servers in an environment that already uses Ansible playbooks and automation. Use Group Policy when onboarding domain-joined Windows servers managed through Active Directory. Both approaches help organizations automate Azure Connected Machine agent deployment by using tools already present in their server-management environment. Additional options are available for onboarding servers at scale. See Azure Connected Machine Agent deployment options.Generally Available: Windows Server 2016 Extended Security Updates enabled by Azure Arc
Today, the Azure Arc team is pleased to announce that Extended Security Updates (ESUs) enabled by Azure Arc is now generally available for Windows Server 2016. By connecting your Windows Server 2016 machines to Azure Arc-enabled servers, you can enroll in ESUs and receive security updates. Enroll machines into ESUs through the Azure portal, a streamlined, cloud-connected experience that protects your on-premises and multicloud workloads while you plan your upgrade or migration journey. Extended Security Updates give you access to Critical and Important security updates for Windows Server 2016 for up to three years after end of support, covering January 12, 2027 through January 2030. They provide a supported bridge for business-critical applications that need more time to migrate, without new features or non-security fixes, and without leaving systems exposed while you plan your move. Extended Security Updates enabled by Azure Arc Once your servers are connected to Azure Arc, ESUs enabled by Azure Arc provide flexible pricing and simpler delivery. Key benefits include: Pay-as-you-go billing means a monthly subscription you can stop when a server is migrated or decommissioned, so you only pay for the coverage you use. Azure-billed pricing draws down from your existing Microsoft Azure Consumption Commitment (MACC) and lets you analyze spend with Microsoft Cost Management and Billing. Built-in asset inventory shows the coverage and enrollment status of your machines directly in the Azure portal, highlighting gaps at a glance. Keyless delivery removes the need to acquire, install, or activate keys on each server. Access to Azure management services When you enroll eligible Azure Arc-enabled servers in Windows Server 2016 ESUs or you have Windows Server Software Assurance, you also gain free access to a set of Azure services that help you manage and secure those machines from the Azure portal: Azure Update Manager is a unified service which provides assessing, scheduling, deploying and managing OS updates across Azure and hybrid machines, including visibility into ESU patch compliance for your Windows Server 2016 estate. Change Tracking and Inventory provides a centralized asset inventory and tracks changes to servers hosted in Azure, on-premises, and other public cloud environments. Azure Policy guest configuration helps define, enforce, and audit compliance rules for Azure resources and guest OS settings across hybrid environments. It includes out of the box policy rules to help meet standards like CIS Benchmark. How to get started Everything starts by connecting your servers to Azure Arc, whether they run on-premises or in other public clouds. Getting started takes only a few steps: Connect your Windows Server 2016 machines to Azure Arc by installing the Azure Connected Machine agent. Enroll eligible servers in Extended Security Updates from the Azure portal, or at scale using Azure Policy (no keys required). Check out our click through demo to see how to apply Extended Security Updates using the Azure portal. Deliver ESU patches through Azure Update Manager or your existing patching solution once servers are enrolled. Extended Security Updates support the Standard and Datacenter editions of Windows Server 2016 and generally require Software Assurance through a Volume Licensing program (machines licensed through SPLA or a Server Subscription do not). For larger estates, you can onboard at scale using Configuration Manager, a Group Policy scheduled task, or VMware vCenter and SCVMM integration with Azure Arc. Beyond Extended Security Updates Enrolling in ESUs is often a customer's first step into Azure Arc — and it opens the door to more. Because your Windows Server 2016 machines are now attached to Azure Arc, you can manage, secure, and govern them alongside your wider hybrid and multicloud estate with Azure Policy, Azure Update Manager, and Microsoft Defender for Cloud. That same Arc foundation makes your next step easier when you are ready: upgrading to Windows Server 2025 or migrating to Azure. Learn more To plan for Windows Server 2016 end of support, explore these resources: Extended security updates enabled by Azure Arc guide Planning ahead for Windows Server 2016 end of support Windows Server and SQL Server End of Support | Microsoft Prepare to deliver Extended Security Updates through Azure Arc Join the Azure Arc customer and engineering virtual meetup Fill in this short intake form to join the quarterly Azure Arc and Windows Server customer meetup: https://aka.ms/arcserverforumsignupAzure Arc Server June Forum
Please find the recording for the monthly Azure Arc Server Forum on YouTube! During the June 2026 Azure Arc Server Forum, we discussed: Arc Server AI Agent assists with onboarding and troubleshooting through an integrated LLM with plans for surfacing the experience through Azure Copilot and in Azure Portal. Azure Arc Multicloud Connector Updates focused on both the Public Preview of the Google Cloud Platform (GCP) Connector and Public Preview of Azure Arc-enablement of detected EKS Clusters. WS 2016 ESU Updates with planned changes versus WS 2012 ESUs and expected timelines anticipating the WS 2016 end-of-support date of January 2027. Note, WS 2012 ESUs will end in October 2026. SQL 2016 ESU Updates discussed enrollment processes, licensing basics, and overall guidance with end-of-support in July 2026. To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/. For the latest agent release notes, check out What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn. We are skipping July and August, and will resume after summer holidays with the September forum to be held on Thursday, September 17 at 9:30 AM PST / 12:30 PM EST. Finally, I wanted to thank everyone for the attendance and community over the last few years, I will no longer be leading the community calls. Please stay in touch, and Mason Torres, Yunis Hussein, and Meagan McCrory from the Arc PM team will be taking the community forward. We look forward to you joining us, thank you!Plan for Upcoming Changes to Extended Security Updates on Azure Local
Beginning April 1 2026, Microsoft introduced a consistent pricing model for Extended Security Updates (ESU) for SQL Server and Windows products, including SQL Server 2016, Windows 10 Enterprise LTSB 2016 and Windows Server 2016. This update aims to simplify the Extended Security Update pricing so that customers pay the same list price for ESUs regardless of deployment location (Azure, on-premises, or other public clouds) or purchasing channel (Microsoft Customer Agreement, Enterprise agreements, Cloud Solution Provider program, or other licensing programs). ESUs on Azure Local This pricing change affects any new Extended Security Update offerings starting on or after April 1, 2026, including Windows 10 Enterprise LTSB 2016 (reaching end of support October 13, 2026) and Windows Server 2016 (reaching end of support January 12, 2027). Existing ESU offerings, including Windows Server 2012 or Windows 10 version 22H2, are not affected by this pricing change. This means that customers who already leverage ESUs will continue to have them available on Azure Local at no cost through Azure Verification for VMs. Next Steps As products reach end of support, it is recommended to upgrade your servers to the latest release available. For customers needing to remain on older versions after the end of support date has passed, further guidance on pricing and availability of ESUs will be shared in the coming months. Keep an eye on Extended Security Updates on Azure Local for more details. For More Information Microsoft Services: Pricing Consistency Update | Microsoft Licensing Resources Plan for Windows Server 2016 and Windows 10 2016 LTSB end of support - Windows IT Pro BlogAzure Arc Server May 2026 Forum
Please find the recording for the monthly Azure Arc Server Forum on YouTube! During the May 2026 Azure Arc Server Forum, we discussed: Private Preview of Windows Server 2016 Extended Security Updates (ESUs): Customers with Windows Server 2016 Servers with an NDA and willingness to provide feedback can sign up at https://aka.ms/WS2016ESU-PrivatePreview Special Announcement: Windows Server Hotpatch enabled by Azure Arc is now available at no additional cost for Windows Server 2025 machines connected to Azure Arc Feedback opportunity to product group on Azure Arc + RDP Capability: Customers can sign up at https://aka.ms/arc-rdp To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/. For the latest agent release notes, check out What's new with Azure Connected Machine agent - Azure Arc | Microsoft Learn. Our June 2026 forum will be held on Thursday, June 18 at 9:30 AM PST / 12:30 PM EST. We look forward to you joining us, thank you!
Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes
Foundry Local on Azure Local lets you run open-source models directly on your own Azure Local cluster, behind an OpenAI-compatible AP. It's the same experience you've gotten used to in the cloud, but the inference runs on hardware you own. Foundry Local on Azure Local is in public preview at the time of this writing. You've installed Foundry Local on your Azure Local cluster. The operator's pods are running, the CRDs are registered, you've checked it twice with kubectl get pods . Now what? This blog covers the part that comes right before all of that - the lifecycle pattern you'll use to deploy any model on Foundry Local on Azure Local. Our recent announcement covers the bigger picture: multi-node inference, vLLM as a first-class runtime alongside ONNX-GenAI, and an expanded catalog. We'll keep this walkthrough single-node for clarity, but the same ModelDeployment pattern scales without changes to your client code or workflow. By the end of this walkthrough, you'll have gone from an empty kubectl prompt to a working, OpenAI-compatible inference endpoint serving Phi-4. All in about ten minutes, using nothing but kubectl , Python, and a small sample script. We'll also show you how to switch that same flow to the new vLLM runtime by changing roughly five lines of YAML. All the code lives in Azure-Samples/foundry-local-model-catalog. Clone it and follow along. What you'll build The sample walks through five steps, each driven by the same Python script with different flags: Query the model catalog - read the ConfigMap the operator syncs from the Microsoft Foundry catalog API. Deploy a model - create a ModelDeployment custom resource pointing at one catalog entry. Wait for ready - the operator pulls the model image, schedules pods, and reports state. Run inference - call the OpenAI-compatible /v1/chat/completions endpoint with an API key the operator generates for you. Clean up - delete the deployment. The same five steps apply whether you're serving an ONNX model on a CPU node or a vLLM model on a GPU node. We'll start with the simpler path: Phi-4 on CPU on the ONNX runtime, then show you the vLLM variant at the end. Before you start You'll need: An Azure Local cluster (or any Arc-enabled Kubernetes cluster) with the Foundry Local extension installed. If you haven't set this up yet, the Foundry Local on Azure Local install guide walks through the cluster, extension, and resource requirements. kubectl configured against that cluster, with permissions to read ConfigMaps and Secrets and to create ModelDeployment resources in the foundry-local-operator namespace. Python 3.9 or later. Verify the operator is alive before you go further: kubectl get pods -n foundry-local-operator kubectl get crd | grep foundry You should see operator pods in Running state and at least one CRD named modeldeployments.foundrylocal.azure.com . If you don't, the install docs are the right place to back up to. Then clone and install: git clone https://github.com/Azure-Samples/foundry-local-model-catalog.git && cd foundry-local-model-catalog && python3 -m venv .venv && source .venv/bin/activate && pip install -r requirements.txt Step 1 - See what's in your catalog Start with the lowest-risk command in the sample, it talks to the cluster but changes nothing: python catalog_sample.py --catalog-only A few things to notice in that table: Most models appear more than once. The same model gets packaged for different runtime/hardware combinations, and the operator picks the right container image based on which entry you reference. There's a RUNTIME column. We'll come back to vLLM at the end of this post; for now, the default Phi-4-generic-cpu ONNX entry is what we'll deploy. The catalog itself is just a ConfigMap. No magic, no hidden registry. The operator syncs it from the Microsoft Foundry catalog API on a CronJob, and the sample reads it the same way you would: kubectl get configmap foundry-local-catalog -n foundry-local-operator -o yaml If you ever wonder what's actually available on your cluster, that's the source of truth. Step 2 - Deploy a model Now the side-effecting part. We're going to ask the operator to deploy Phi-4 on CPU: python catalog_sample.py --deploy-only Under the hood, the sample builds and applies a ModelDeployment manifest that looks like this: apiVersion: foundrylocal.azure.com/v1 kind: ModelDeployment metadata: name: phi-4-generic-cpu namespace: foundry-local-operator spec: model: catalog: name: Phi-4-generic-cpu workloadType: generative compute: cpu replicas: 1 port: 5000 The operator takes it from there. It pulls the model container image, schedules a pod, generates an API-key Secret named phi-4-generic-cpu-api-keys , and walks the deployment through Pending → Creating → Running states. The sample polls until both status.state == Running and status.deploymentReady == true . Step 3 - Run inference The endpoint is up. Time to actually use it. If you're running this script from inside the cluster (say, from a debug pod), the endpoint lives at the in-cluster service DNS and the sample picks that up automatically. Most readers will be running from a laptop, though, so we'll cover that path explicitly. In one terminal, port-forward the deployment's service: kubectl port-forward svc/phi-4-generic-cpu 5000:5000 -n foundry-local-operator In another, run the sample's inference-only mode against the forwarded endpoint: python catalog_sample.py --infer-only --endpoint https://localhost:5000 --insecure The sample reads the API key from the auto-generated Secret and sends it as Authorization: Bearer <key>. same pattern as cloud OpenAI. The request body is the standard OpenAI chat-completions shape: { "model": "Phi-4-generic-cpu:1.0.0", "messages": [ {"role": "system", "content": "You are a helpful assistant."}, {"role": "user", "content": "What is the capital of France? Reply in one sentence."} ], "max_tokens": 256 } That response just traveled from your terminal, through kubectl port-forward , into a model serving inside your Azure Local cluster, and back. Step 4 - Clean up The sample's default flow deletes the deployment on its way out, so if you ran the full python catalog_sample.py (no flags) you're already clean. If you used --deploy-only or --skip-cleanup , drop it explicitly: kubectl delete modeldeployment phi-4-generic-cpu -n foundry-local-operator The operator garbage-collects the pod, service, and API-key Secret. The cached model image stays on its PersistentVolume, so your next deploy of the same model skips the image pull. Going beyond CPU: vLLM in 5 lines Now for the variant we've been pointing at. The same ModelDeployment CR, the same OpenAI-compatible endpoint, switched to a runtime built for concurrent users, demonstrated on a popular open-source model. The diff against the manifest from Step 2: spec: - compute: cpu + compute: gpu + runtime: vllm model: catalog: - name: Phi-4-generic-cpu + name: Mistral-7B-v0.2 The same sample script handles it: python catalog_sample.py \ --model Mistral-7B-v0.2 \ --compute gpu \ --runtime vllm What you get back is the same OpenAI-compatible endpoint your client code already knows, but now backed by vLLM's PagedAttention, continuous batching, and automatic planner-tuned configuration. Your application code doesn't need to know any of that; it's still POST /v1/chat/completions with a Bearer token. That's the point of the lifecycle pattern: ONNX or vLLM, CPU or GPU, the platform engineer's deployment loop looks the same. For the architectural "why" behind multi-node, vLLM, and the expanded catalog, read the announcement. What you've built Ten minutes ago you had an installed-but-empty Foundry Local cluster. You now have: A working OpenAI-compatible chat endpoint serving Phi-4. A clear sense of what the operator manages for you ( ModelDeployment CR, model image cache, API-key Secret) and what stays in your hands (which model, which runtime, which compute target). A small, modular script you can wire into three things: A smoke test for every new cluster you stand up ( --catalog-only → --deploy-only → --infer-only is a one-line CI step). An internal demo when you need to show a team that Foundry Local on Azure Local is real and reachable. The foundation for your team's own deployment automation - copy the manifest builder, drop the CLI, and wire it into your existing GitOps or platform tooling. From endpoint to chat surface The model deployment above exposes a standard OpenAI-compatible API - enough for any existing chat client to point at. If you'd like to see exactly that, Azure-Samples/local-chat-with-foundry-local picks up where this walkthrough ends: it wires the running endpoint into the Sovereign Chat Experience starter UI. About ten more minutes from working endpoint to working chat in the browser. Where to go from here Try the rest of the sample: --catalog-only , --deploy-only , --infer-only , and --skip-cleanup compose into whichever workflow you're testing. Read the announcement for the architectural why behind multi-node, vLLM, and the expanded catalog. Read the docs for the full operator and CRD reference. Feel free to share your feedback with us at FoundryLocalOnAzure@microsoft.com. The product is in public preview, so your feedback shapes what ships next.Build, deploy, and govern sovereign AI with Foundry Local on Azure Local
Not every AI workload can run in the cloud. For many of our customers, data needs to stay within defined boundaries, connectivity may be limited or absent, and latency, governance, and auditability are non-negotiable. With Foundry Local on Azure Local, you can use the same model catalog, developer workflows, and governance capabilities you know from Azure, while running AI entirely within your own environment where your data resides. Foundry Local provides the model catalog and developer experience. Azure Local provides the customer-managed infrastructure. Azure Arc provides unified policy, governance, and lifecycle management across cloud and local environments. This gives developers a consistent way to build, deploy, and operate AI. The same az commands, the same model catalog, the same Arc policies, all running on hardware you control. Expansion of Foundry Local on Azure Local We're expanding the Foundry Local model offering on Azure Local, with support for multi-node deployments and new agents and tools that run locally, in preview. Deploy and run AI models locally. Run models with Foundry Local in customer-managed environments on Azure Local, across sovereign, private, and edge scenarios, including fully disconnected operation. Choose from a flexible, high-performance model catalog. Access proprietary and community models through Foundry Local, now expanded with vLLM-optimized models alongside ONNX-based offerings. You explore and deploy through the same catalog API experience, then operate locally on Azure Local. Build for production realities. Bring governance, identity, and auditability into your applications while keeping execution inside your controlled boundary. See what’s new in Foundry Local on Azure Local in the Tech Community blog. From intelligence to action: agents and tools inside the enterprise boundary Most production AI use cases need two things: grounded answers and the ability to act on them, without sending data outside the environment. Here's how we're enabling that locally. Preview: Agentic retrieval with Foundry Local: Ground agents in enterprise data using retrieval-augmented generation across local Microsoft 365 services, including Exchange and SharePoint. Read the Tech Community blog to learn more. Preview: Agents and tools with Foundry Local: Build AI systems that reason, retrieve information, and take action within customer-controlled environments. Learn more. Preview: Developer acceleration templates: Jump-start local AI application development with new Foundry solution templates, including local chat experiences and video agents, powered by Azure AI Video Indexer. Read the Tech Community to learn more. GitHub Enterprise Local: Now available in public preview Sovereign AI is also about how systems are built and secured, not just where they run. With GitHub Enterprise Local on Azure Local, you can bring your full software development lifecycle on-premises: Source control and repositories CI/CD pipelines Security and DevSecOps workflows GitHub Enterprise Local deploys entirely within customer-owned infrastructure, so teams get the developer tools they expect without compromising on data residency or operational control. This extends modern DevSecOps practice into sovereign environments and pairs naturally with the AI development workflows above: build, secure, and ship your AI applications within the same boundary where they run. Read the tech community blog to learn more about GitHub Enterprise Local and how to join the preview. Accelerating High-performance AI at the Edge with NVIDIA We are expanding our collaboration with NVIDIA to deliver high-performance AI capabilities directly at the edge. At Build, we are bringing: Azure Local and Foundry Local on NVIDIA-powered GPUs, including NVIDIA RTX PRO 6000 Blackwell Server Edition, with expanded GPU support coming soon Integration with Nemotron models, optimized for enterprise performance A scalable foundation for data-intensive, low-latency workloads This partnership ensures that organizations can run advanced AI workloads where data is generated - without dependency on centralized cloud infrastructure. Hardware options: AI factory configurations are available now in the catalog Alongside our hardware partners, we’re bringing integrated solutions to customers building AI within sovereign environments. The Azure Local hardware catalog now includes AI factory configurations from our OEM partners, including NVIDIA-certified 8xH100 systems, with options from DataON, Dell, HPE, and Lenovo. These configurations are sized for the performance that model serving and agentic workloads require on customer-managed infrastructure. Together with Microsoft, we are advancing sovereign AI by bringing the open NVIDIA Nemotron model family to Microsoft Foundry Local on Azure Local. This collaboration gives organizations a production-ready AI platform that enables them to deploy AI where their data resides while maintaining the governance, control, and performance needed to scale AI across the enterprise.” Kari Briski, VP Generative AI Software Products, NVIDIA ”Sovereign AI is becoming increasingly important for governments, regulated industries, and enterprises that want to use AI while maintaining control of their data, location, and operations. Lenovo’s ThinkAgile MX Series delivers trusted, enterprise-grade infrastructure with global deployment expertise to help customers run AI wherever their data resides. Co-engineered with Foundry Local and Azure Local, this solution provides an optimized platform to deploy, run, and scale AI locally with greater simplicity, consistency, and control, while helping meet strict data residency, security, and compliance requirements." Scott Patti - VP Infrastructure Solutions Group (ISG), Lenovo From AI models to trusted, mission-critical systems: what this unlocks for developers and operators AI is evolving from systems that answer questions to systems that plan, reason, and take action across workloads. These capabilities move AI from a cloud-only assumption to something you can deploy where sensitive work actually happens, with governance and operational controls intact. For our customers, this means you can now: Keep data, identities, and audit trails inside your sovereign boundary. Run AI inference and agentic workloads in connected, intermittently connected, or fully disconnected modes. Apply consistent policy and governance across cloud and local environments through Azure Arc. Use the same Foundry catalog and developer experience you already know, on infrastructure you own. Build, secure, and ship your AI applications with GitHub Enterprise Local, keeping source control, CI/CD, and DevSecOps workflows inside the same sovereign boundary. Resources Join us at Build OD837 Shipping physical AI to the edge with Azure Local and Foundry Local https://github.com/microsoft/build26-OD837 OD839 Foundry Local: AI solutions for industrial and sovereign needs https://github.com/microsoft/build26-OD839 LTG425 Expanding horizons: Foundry Local for devices and on-prem https://build.microsoft.com/en-US/sessions/LTG425 Request to join the Foundry Local on Azure Local preview Hands-on walkthrough: Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes | Microsoft Community Hub Read our Tech Community blogs: Foundry Local announcing multi-node and vLLM support Agentic Retrival with Foundry Local blog: https://aka.ms/AgentsAndToolsBuildBlog2026 Code sample / model catalog blog: https://aka.ms/foundry-local-model-catalog-blog For more details on the expanded capabilities of Foundry Local for highly secure environments, contact your Microsoft account team Discover Microsoft Sovereign Cloud Explore product documentation at: Foundry Local models on Azure Local: https://aka.ms/FoundryLocalonAzureLocal_documentation Local Agentic retrieval with Foundry Local: https://aka.ms/edge-agentic-retrieval-docsUnlock On-Prem Productivity with Agentic Retrieval in Foundry Local
In today’s connected world, customers expect instant, context-rich interactions, even in environments where cloud connectivity isn’t guaranteed. That’s where Retrieval-Augmented Generation at the edge comes in. Since we launched into public preview, we’ve watched teams across regulated, disconnected, and mission-critical environments push this technology into places cloud GenAI simply couldn’t reach. What we heard back shaped everything in this release: customers don’t just want retrieval. They want reasoning, they want agency, and they want an end-user experience that feels as natural as the one they already use in the cloud. Today at Build 2026, we're excited to introduce Agentic Retrieval, the next evolution of our on-prem RAG platform, enabled by Azure Arc and powered by Foundry language models. Agentic Retrieval is part of Microsoft's Adaptive Cloud approach, which extends Azure capabilities to wherever customer data and workloads actually live, with Edge AI focused on bringing reasoning and grounding to on-prem, distributed, and disconnected environments. Together with Foundry Local, Agentic Retrieval continues to shape Microsoft's Foundry Anywhere commitment: flexibility, resilience, and intelligence wherever customers operate. What’s new at Build 2026 This release introduces three major pillars that work independently or together: Agentic Retrieval engine: a first-party orchestration runtime for planning, reasoning, conversation state, and tool calls over your local data Knowledge: a dedicated layer for organizing, curating, and governing your grounding data, exposed via MCP and connectable to any agentic retrieval layer Chat UI: a production-ready, polished conversational experience that ships as the default UX for Agentic Retrieval and can also be deployed standalone Alongside, we’re delivering the platform upgrades customers asked for: flexible deployment modes (Agentic-only, Knowledge-only, or Combined), BYOM with pluggable backends, Foundry Local model catalog integration, Entra ID support, disconnected-ready, and hybrid search combined with agentic retrieval. Agentic Retrieval: From Answering to Reasoning Classic RAG retrieves, then generates. Agentic Retrieval plans, reasons, and acts, running multi-step retrieval and tool invocation under a first-party orchestration runtime, entirely on your infrastructure. Under the hood it manages query planning, iterative multi-hop retrieval, tool calls via MCP, conversation state, and mandatory grounding with citations and audit logging built in. What customers can achieve: Compliance, policy, and permit workflows for public sector, regulators, and defense operations, with data never leaving sovereign infrastructure Multi-document synthesis across standards, technical manuals, contracts, and field procedures for industrial operators An agentic chat experience for regulated and operational teams (engineers, inspectors, analysts) that reasons like a subject-matter expert Auditable AI for sovereign and mission-critical environments, with every answer traceable to its source Knowledge: A First-Class, Governed Data Layer Great answers start with great knowledge. Knowledge is now a standalone component customers can deploy on its own or alongside Agentic Retrieval, exposed through an MCP wrapper so it can connect to any agentic retrieval layer, ours or yours. This release brings Collections (segmented groups of indexed knowledge with granular access permissions), multi-source ingestion across documents, tables, images, and SharePoint (indexed source moving to public preview), high-fidelity parsing for complex enterprise content, Bring Your Own MCP to connect customer-owned data sources directly into Agentic Retrieval and the chat experience, and governance enforced at the data layer itself. ent view - collections, sources, and permission scopes What customers can achieve: Scope knowledge access to different slices of the same corpus, by plant, site, classification, or jurisdiction Enforce data sovereignty, residency, and regulatory compliance at the knowledge layer itself Ground both first-party Agentic Retrieval and BYO orchestration through a single governed source of truth across distributed sites Keep classified, proprietary, and operational data fully on-prem while delivering premium chat experiences Chat UI: Production-Ready Conversational Experience Agentic Retrieval now ships with a polished, production-ready Chat UI as its default experience, and the same component can be deployed standalone for customers building their own stack on Foundry Local. Highlights include Entra ID authentication (MSAL login, Bearer tokens, user identity display), pluggable backends across AI Foundry, BYOM, or mock mode with zero code changes, Chain-of-Thought visibility and inline citations that make grounding transparent to end users, standalone frontend deployment via Helm chart and container image, and disconnected-ready operation for air-gapped environments. What customers can achieve: Deliver a polished end-user experience to operators, inspectors, and analysts without building UI from scratch Build trust in regulated and industrial workflows through transparent, inspectable reasoning and grounding Run the same UI across air-gapped facilities, sovereign clouds, and connected industrial sites Accelerate rollout across public sector, defense, manufacturing, and other mission-critical environments Why This Release Matters Every update to our on-prem RAG platform has moved us toward a simple conviction: GenAI should be useful wherever customers operate, whether regulated or open, connected or disconnected, centralized or distributed. With Agentic Retrieval, Knowledge, and Chat UI coming together, backed by Foundry on Arc, BYOM, and fully disconnected support, this is no longer “cloud RAG, but local.” It’s an agentic knowledge platform purpose-built for the realities of enterprise data: on-prem, governed, and increasingly autonomous. Learn More Explore Agentic retrieval documentation Read Foundry Local on Azure Local model inferencing blog post For more information reach out to the team at FoundryLocalOnAzure@microsoft.com
Scale On-Prem AI with Foundry Local on Azure Local: Multi-Node Inference and vLLM Support
Since announcing the public preview of Foundry Local on Azure Local for single-node, we’ve seen strong adoption in regulated industries and consistent customer demand to expand the platform for scalable deployments. Today, we’re expanding Foundry Local model offering on Azure Local (preview) with three additions that broaden where and how you can use it: Multi-node scheduling - distribute inference workloads across the GPU capacity in your Azure Local cluster, not just a single node vLLM runtime support - a high-throughput serving engine purpose-built for large language models and concurrent workloads An expanded model catalog - new models available in vLLM optimized format alongside the existing ONNX offerings Together, these additions let you scale to higher concurrency, serve more users from a single endpoint, and run larger models on-premises. They round out Foundry Local on Azure Local into a more complete, production-grade on-premises inference platform - covering a wider range of model sizes, concurrency profiles, and hardware footprints, while preserving the same Kubernetes-native, OpenAI-compatible patterns you're already using. Runs disconnected - no cloud round-trip required Foundry Local on Azure Local is designed to run fully on-premises, including in disconnected and intermittently-connected environments. Model weights, prompts, and inference traffic stay entirely inside your Arc-enabled cluster - there is no per-request call to Azure, no data exfiltration to the cloud, and no dependency on a live WAN to serve inference. Models are cached locally on Persistent Volumes after the first pull. Once cached, the inference endpoint keeps serving even when the WAN is down - across reboots, network outages, and extended disconnected operation. API-key authentication continues working uninterrupted during disconnected periods. Microsoft Entra ID auth resumes seamlessly when connectivity returns. The control plane is local to the cluster. The Foundry Local operator, the model catalog, and the inference runtimes all live inside Azure Local - Arc is used for fleet management and updates, not for the inference data path. For factory floors, offshore platforms, sovereign data centers, classified sites, and remote branch offices where cloud connectivity is unreliable, restricted, or prohibited, this is what makes on-premises AI inference actually viable in production. Multi-node scheduling: more scenarios, more capacity Foundry Local on Azure Local now expands to support multiple nodes in your cluster. The inference operator schedules and manages deployments across the GPU capacity available cluster-wide, so you can: GPU capacity from any node in the cluster, not just a single node’s resources Place inference workloads where the hardware lives, with the operator managing deployments across nodes The same Model Deployment custom resource you already use defines the workload, and it is served through the standard OpenAI-compatible endpoint (POST /v1/chat/completions). The API used to interact with conversational AI models by sending structured messages and receiving model-generated responses. Existing applications work against multi-node deployments with zero code changes. vLLM runtime: high-throughput serving for production workloads Alongside ONNX-GenAI, Foundry Local now offers vLLM as a first-class inference runtime. vLLM is an open-source, high-throughput serving engine that has become the standard for production LLM inference in the cloud. Bringing it to Foundry Local on Azure Local means the same performance characteristics are available on your factory floor, in your sovereign data center, or at your remote site. Why vLLM matters for edge and on-premises inference Capability ONNX-GenAI vLLM Hardware CPU and GPU GPU only Throughput Optimized for single-user, low-latency Optimized for high-throughput, multi-user concurrency Memory management Standard allocation PagedAttention - efficient KV-cache management reduces VRAM waste Continuous batching Not supported Supported - incoming requests are batched dynamically for higher GPU utilization FP8 KV cache Not supported Supported on compatible models and GPUs - roughly doubles token capacity Best for Compact models, CPU-only nodes, single-client scenarios Larger models, multi-user workloads, GPU-equipped clusters Automatic GPU inference tuning with the vLLM planner One of the operational challenges with vLLM is configuration tuning - setting GPU memory utilization, context length, batch sizes, and other parameters for a given model on a given hardware profile. Get it wrong and the pod either OOMs (runs out of memory) on startup or wastes GPU capacity. Foundry Local addresses this with the vLLM planner, an automatic tuning component that inspects the available GPU resources, analyzes the target model's footprint, and generates a memory-safe, high-performance configuration before the model server starts. You declare what model you want to run; the planner figures out how to run it optimally on your hardware. Full configuration reference is in the vLLM planner docs. Identity-based access for multi-user workloads Serving more concurrent users isn't only a throughput problem - it's also an access-control problem. Foundry Local supports two authentication modes side by side on the same endpoint: API keys - primary and secondary keys per deployment, with zero-downtime rotation. Ideal for service-to-service traffic and automated pipelines. Microsoft Entra ID with Azure RBAC - per-identity access using the Cognitive Services OpenAI User role (or any role granting the equivalent data-plane action). JWT validation runs inside the inference pod; authorization is enforced through the cluster's Arc-managed identity. Enable both, and clients can present either credential type in the same Authorization: Bearer header - the platform detects which one was sent and routes to the right validation path. API-key callers also keep working uninterrupted if external connectivity is briefly lost, giving you a natural degradation story for edge and disconnected sites. For a multi-user AI assistant on the factory floor or in a sovereign data center, this is the difference between a shared service account and a per-user audit trail. Expanded model catalog: ONNX and vLLM side by side The Foundry Local model catalog now includes models in both ONNX and vLLM formats. The same model can appear multiple times in the catalog - once per runtime/compute target - so you can pick the build that matches your hardware without leaving the platform. The operator selects the right container image automatically based on the entry you reference. Broader open-model support Beyond the Phi and GPTOSS families, the catalog now includes additional models across multiple open-source lineups that customers have requested for on-prem and sovereign deployments, including Mistral and NVIDIA Nemotron. Both are available as catalog entries, served by the vLLM runtime on GPU, and accessible through the same OpenAI-compatible endpoint you already use. In collaboration with NVIDIA, Foundry Local now supports the latest Nemotron models, optimized for enterprise performance on NVIDIA powered Azure Local hardware including NVIDIA RTX Pro 6000. Nemotron models are tuned for reasoning, instruction-following, and agentic workflows, and run on the vLLM runtime with PagedAttention, continuous batching, and FP8 KV cache on compatible GPUs. The vLLM planner handles GPU memory utilization and context-length sizing automatically. you declare the catalog entry, the platform sizes the deployment to your hardware. Models available in vLLM format (see the model catalog docs for the full, regularly updated list) Model ONNX vLLM Notes Phi-4 ✓ ✓ Microsoft's flagship SLM Phi-4-mini ✓ ✓ Compact, fast inference Phi-4-mini-reasoning ✓ ✓ Chain-of-thought reasoning Phi-4-reasoning — ✓ vLLM-only, reasoning-focused gpt-oss-20b ✓ ✓ Mid-range generative gpt-oss-120b — ✓ Large generative, vLLM-only Mistral-7B-v0.2 ✓ ✓ Popular open-source LLM DeepSeek-R1 (7b/14b) ✓ — Reasoning-focused Qwen2.5 (0.5b–14b) ✓ — Multilingual, coder variants Qwen3 (0.6b–14b) ✓ — Latest generation Whisper (multiple sizes) ✓ — Speech-to-text Nemotron ✓ (CPU) ✓ The catalog now includes a growing list of models across both runtimes. Models in vLLM format are served using the vLLM engine with all its performance benefits - PagedAttention, continuous batching, FP8 KV cache - while ONNX models continue to serve on CPU or GPU through the ONNX-GenAI runtime. Bring-your-own model (BYOM) When you need a model that isn’t in the catalog, bring-your-own model still works the same way: package your model as an OCI artifact in any ORAS-compatible registry (Azure Container Registry, GitHub Container Registry, Docker Hub) and reference it from your ModelDeployment. The operator caches it locally and reuses the cached copy on subsequent deployments. Choosing the right runtime ONNX-GenAI when you're running on CPU-only hardware, serving a single application with a compact model, or need the broadest model compatibility including speech and predictive workloads. vLLM when you have GPU hardware, need to serve concurrent users, want to run larger models, or need production-grade throughput from your inference endpoint. Both runtimes expose the same OpenAI-compatible REST API - the choice is transparent to application code. vLLM ModelDeployment is as simple as this: Everything else - memory utilization, context length, batch sizing - is handled by the vLLM planner. See the model catalog docs for the BYO pattern and full configuration options. What hasn't changed Everything from the public preview remains fully supported: Two installation paths - Azure Arc extension (recommended for fleet management) and Helm chart (for platform engineers who need full control) OpenAI-compatible REST endpoints - POST /v1/chat/completions and standard patterns API key and Microsoft Entra ID authentication - secured with bearer tokens, with the per-identity RBAC model described above TLS-enabled ingress - encrypted traffic in transit Disconnected operation - models cached on local PersistentVolumes continue serving when WAN connectivity drops Bring-your-own predictive models - deploy custom ONNX models from OCI registries Multi-model orchestration - agent-style patterns coordinating multiple local models Your existing ModelDeployment manifests continue to work. Applications targeting the ONNX-GenAI runtime don't need any changes. The new capabilities are additive. Real-world scenarios, now at scale Over the past few months, we’ve partnered with customers in early preview to build and validate real-world scenarios. A consistent theme across these engagements is the need to run AI where data resides—on-premises—while maintaining the governance and consistency enabled by Azure Arc. "In energy operations, AI needs to run where the work happens – at remote facilities, offshore platforms, and field locations where connectivity is often limited, and safety is paramount. Foundry Local gives us a path to bring AI-driven decision-making closer to our operational data, with the governance our industry demands. The ability to deploy and run AI workloads consistently across edge and field environments, even when disconnected, is critical as we advance Chevron's vision for autonomous and intelligent operations." (Chevron) Ed Moore - OT Strategist and Distinguished Engineer With multi-node and vLLM, the scenarios from our initial preview scale to meet production demands: Manufacturing: multi-user quality inspection A quality-control system on a production line previously ran Phi-4-mini for single-station anomaly explanation. With vLLM's continuous batching, the same Foundry Local endpoint now serves 10+ inspection stations concurrently - each sending defect images and sensor telemetry for real-time root-cause analysis - without response-time degradation. Sovereign: identity-scoped document processing A government agency processing sensitive casework needs production-grade throughput and a strict audit trail. Foundry Local serves the workload on-premises across multiple GPU nodes, with per-analyst access enforced through Entra ID and Azure RBAC, so every inference call is tied to a real identity - and no data leaves the cluster. Energy: disconnected multi-user operations An offshore platform runs Foundry Local on a multi-node Azure Local cluster. When WAN connectivity drops, the vLLM-powered endpoint continues serving safety procedure lookups, maintenance guidance, and operational queries to multiple crew members simultaneously - each accessing the inference endpoint from their local application. API-key auth keeps working through the outage; Entra ID resumes seamlessly when the WAN comes back. Getting started If you're already running Foundry Local on Azure Local in the public preview: Once installed the Foundry Local extension is automatically kept up to date, with multi-node and vLLM support included. Browse the updated catalog to discover models available in vLLM format Deploy a vLLM model by setting runtime: vllm in your ModelDeployment manifest Let the vLLM planner optimize - override only the preferences you care about and let the planner handle the rest If you're new to Foundry Local on Azure Local: Follow the get-started code-sample blog to see the end-to-end flow Request preview deployment access to get started Read the documentation for architecture overview and deployment guide What's next Multi-node and vLLM are just the beginning. We're continuing to invest in: Distributed LLM serving with LLM-D - KV-cache-aware routing and disaggregated serving for large models that span multiple nodes Autoscaling for inference workloads - dynamic capacity that follows demand Broader model catalog expansion - more model families, more sizes, more task types Enhanced monitoring and observability for inference workloads Performance optimization for specific Azure Local hardware profiles Expanded GPU hardware validation across the Azure Local catalog We're building Foundry Local to be the production AI inference platform for edge and sovereign environments. Your feedback is shaping every release - keep it coming. Learn more: Foundry Local Model and inferencing on multi node demo Foundry Local for devices (GA) For more information reach out to the team at FoundryLocalOnAzure@microsoft.com
