SQL Server, no internet required
SQL Server on Azure Local is now generally available in disconnected environments, per Microsoft’s September 29 update. The capability extends SQL Server support to Azure Local disconnected operations, where instances run with no connection to the Azure public cloud. Until now, running SQL Server on Azure Local assumed you could reach Azure for management, which quietly ruled out the exact organizations that most want on-premises SQL Server: defense, government, healthcare with data residency mandates, and anyone running a mine site or ship with no reliable link back to civilization.
If you lost track of the naming, Azure Local is what Microsoft rebranded Azure Stack HCI into, and it is the company’s platform for running Azure-consistent infrastructure on hardware you own. Disconnected operations take that one step further. The control plane moves into your environment. There is no phone-home, no Azure Resource Manager call that leaves the building, nothing.
How the disconnected model works
Microsoft’s overview documentation describes the design plainly: you get a local control plane, operated by your organization, that presents a subset of Azure capabilities. The Azure portal, Resource Manager templates, role-based access control, and CLI tooling all work locally, so operational muscle memory built in the cloud carries over. Supported services include Azure Key Vault for secrets and certificates, Azure Policy for governance, Azure Container Registry for local image workflows, and AKS for Kubernetes where your deployment supports it. There is also Microsoft 365 Local, which runs Exchange Server, SharePoint Server, and Skype for Business Server on the same infrastructure.
The generally available release requires Azure Local 2602 or later. Deployments are tied to a single site, though the disconnected control plane can be shared across sites if you provide the private connectivity between them yourself. Two connectivity models exist: limited connectivity, where the appliance still reaches Azure for support and updates, and fully air-gapped, where every data transfer in or out is a manual import and export job.
Operationally, the disconnect changes the maintenance rhythm as much as the security posture. In an air-gapped configuration, patching SQL Server, updating the appliance, and pulling in new container images are all physical logistics: media gets carried in, changes get tested and scheduled around production windows, and there is no cloud to cover a missed backup. Teams that already run isolated networks will recognize the workload. Teams moving from connected Azure Local should inventory everything that currently leans on the cloud side, telemetry, monitoring, and identity integration included, before planning the cutover.
Who this is actually for
Read the eligibility section before you get excited, because this is not a download. Microsoft gates disconnected operations behind a validated business need, an eligible enterprise agreement, and a stated regulatory or operational requirement to run without Azure connectivity. Deployment requires supported, customer-owned hardware plus a dedicated management cluster to host the infrastructure components, which is real capacity you must budget for on top of your workload nodes. The appliance installer itself is large, measured in hundreds of gigabytes of virtual hard disks, and initial deployment takes hours, not minutes.
Licensing follows the same pattern: pricing is based on the total physical cores across the Azure Local deployment on an annual term, with a limited trial available. The gating is deliberate. Microsoft is not trying to sell this to everyone, it is trying to sell it to organizations whose alternative was never touching Azure at all.
The SQL Server piece
With SQL Server supported on these disconnected instances, the database workloads that usually anchor regulated environments, OLTP systems, data warehouse and BI loads, and increasingly AI analytics, can run on the same platform with high availability from Windows Server failover clustering and Always On availability groups. That combination is what many enterprise database teams already run, so the operational model is familiar even though the host platform is newer.
Why it matters
This lands squarely in Microsoft’s sovereign cloud push. A sovereign, classified, or heavily regulated organization previously had two realistic options: run SQL Server on Windows Server the traditional way, or buy into a dedicated sovereign cloud region if one existed near them. ALDO offers a third path that keeps the Azure tooling and architecture without sending any data or control traffic to a Microsoft datacenter. Whether that appeals to buyers depends heavily on trust in the platform, but the technical story is coherent, and it puts pressure on other on-premises virtualization vendors whose enterprise agreements are up for renewal every year.
If you are considering it
Start with the paperwork, not the hardware. The eligibility request goes through your Microsoft account team and approval is not automatic, so begin months before your planned rollout. Read the known issues page in the disconnected operations documentation before committing, since early deployments have real limitations documented there. Size the dedicated management cluster honestly, three machines is the floor, and remember that in a fully air-gapped configuration you own the update logistics: getting those multi-hundred-gigabyte appliance images onto a network with no internet is a physical problem, and it is your problem.