GitHub Enterprise Local and Foundry Local: What Stays Local, What Doesn't

In an October 20 post on the Microsoft Azure Arc Blog, Sushil Jarwal announced GitHub Enterprise Local on Azure Local, with a choice between cloud-connected GitHub Copilot and local models through Foundry Local. Jarwal says GitHub Enterprise Local is expected to become generally available at Microsoft Ignite. As of October 26, 2026, that is a planned milestone, not a claim that the product is already generally available.

There is a useful security question behind the announcement: what does "local" actually keep local? The answer depends on which part of the workflow you mean: repositories, inference, identity, model downloads, updates, or management. Those boundaries matter when deciding whether a particular workflow meets your requirements.

Follow the data and management paths

The diagram separates the repository boundary from the inference boundary. Green paths stay inside the Azure Local environment; the orange path sends AI requests to GitHub Copilot. Azure Arc management is shown separately below the request paths. The connected workflow uses GitHub.com identity and licensing; disconnected deployments use the identity and endpoint options supported by their local environment.

Repository hosting, inference, identity, and management can follow different paths. Confirm each path for the product version and deployment mode you plan to use.

"Local" describes a location, not one security property

For this design, I would write down at least four separate locations: where source repositories are hosted, where prompts and model inputs are processed, where identity is checked, and where management or updates come from. A product can keep the first two on customer-controlled infrastructure while still using an external identity provider, license service, update channel, or cloud feature.

That distinction is easy to miss when "local" is used as shorthand for private, disconnected, or sovereign. Those terms are related, but they do not mean the same thing. A workload can be physically on premises and still have cloud dependencies. A connected system can keep inference data on premises while reaching a cloud service for identity or licensing.

Foundry Local comes in two different shapes

Foundry Local is the device-oriented runtime and SDK. Microsoft's documentation describes embedding it in an application, downloading models from its curated catalog, and running inference on the device. After the required model files are present, an app can work offline and keep its inference data on that device. This is useful for a desktop or edge application with one local user and a model that fits the available hardware.

Offline inference does not mean there is never network traffic. Foundry Local may need to download model files and hardware execution components the first time they are used. Microsoft's documentation also describes optional diagnostic sharing. For an offline deployment, plan how those files are acquired and staged, and review the applicable product and model terms.

Foundry Local on Azure Local is a different deployment. It runs on an Arc-enabled Kubernetes cluster and is managed through an Azure Arc extension and Kubernetes-native resources. Microsoft's Learn page describes this version as a way to run inference on customer infrastructure, with model lifecycle management and secured endpoints. Documented endpoint options include API keys, Microsoft Entra ID tokens, and Kubernetes service account tokens, with TLS-enabled gateway patterns. Those options depend on deployment mode: Microsoft's disconnected-deployment guidance says authentication uses the environment-configured directory configured for that environment rather than public Microsoft Entra ID endpoints. In-cluster requests can also use Kubernetes service account tokens. The page currently labels it as preview. Treat its capabilities and operational requirements as subject to change until Microsoft documents general availability.

The distinction is practical. The device runtime is for putting inference inside an application on an endpoint. The Azure Local option is for deploying inference services on a local cluster. They have different hardware assumptions, operational models, and user concurrency expectations.

Option	What it does well	Limits to plan for
Foundry Local on an end-user device	Local inference, offline use after model acquisition, no per-token cloud inference charge, and an SDK that can be integrated into an application.	The catalog is curated rather than open-ended. Performance depends on endpoint memory and CPU, GPU, or NPU support. Microsoft describes this runtime as optimized for hardware-constrained devices and single-user access, not as a general multi-user inference server. First-use model and execution-provider downloads need to be planned for offline use.
Foundry Local on Azure Local	Cluster-based local inference with Kubernetes operations, Azure Arc management, and secured endpoints for local applications.	Microsoft Learn currently labels it preview. You need a supported Azure Local and Arc-enabled Kubernetes environment, compatible hardware, and the operational capacity to manage the cluster and models.
GitHub Enterprise Local on Azure Local	GitHub Enterprise Server workflows and source hosting on customer-controlled Azure Local infrastructure, with a guided deployment using Azure Workload Orchestration announced.	The announcement describes a planned Ignite GA milestone. Do not assume every GitHub.com service is included or that cloud connectivity is unnecessary for every feature.

Connected and disconnected workflows are not the same

Jarwal's announcement separates the AI choice by connectivity. In a connected environment, developers can use GitHub Copilot from supported tools while repositories remain on GitHub Enterprise Local. The announcement says this option requires a GitHub.com identity and license. Repository location and AI-service location are therefore separate decisions.

For a restricted or disconnected environment, the announcement describes using approved models through Foundry Local on Azure Local. The inference request is handled within the customer environment, through the supported local endpoint and tooling. The article is explicit that this is a focused local AI option, not the full cloud-backed GitHub Copilot experience. Model availability and supported capabilities can vary.

Workflow	What can work	What not to assume
Connected GitHub Enterprise Local	Keep repository hosting on Azure Local and use GitHub Copilot in supported developer tools when outbound connectivity, GitHub.com identity, and the required license are available.	Do not describe the Copilot request path as fully local. Confirm which data is sent to the cloud service and which organizational policies apply.
Restricted or disconnected environment	Run supported local models through Foundry Local on Azure Local and call the local inference endpoint from supported GitHub tooling.	Do not expect feature parity with GitHub Copilot, every model, or every extension. Confirm the supported model list, tooling, network requirements, and preview status for the target environment.
Device-local application	Embed Foundry Local in a supported client app, acquire the selected model, and run inference on the device, including offline scenarios after setup.	Do not treat the client runtime as a centrally operated, high-concurrency service. Model size, memory, hardware acceleration, and update distribution still matter.

Control shifts to the team running the local systems

Moving repositories and inference closer to the organization changes the operational work. GitHub Enterprise Server is a self-hosted appliance. GitHub's documentation makes the customer responsible for instance upgrades and recommends planning maintenance, backup, storage, and hardware capacity. Local control can help with data handling requirements, but it also means the organization owns more of the availability and patching work.

Azure Local has its own platform requirements and per-core pricing, with additional Azure service charges where used. Foundry Local on an endpoint avoids per-token cloud inference costs, but it still uses device resources and takes engineering effort to distribute models, test hardware performance, and keep the application current. For the Azure Local Foundry deployment, budget for cluster operations and preview risk as well as the hardware.

For a disconnected deployment, test the full lifecycle, not only a successful prompt. Document how you obtain and stage model artifacts, updates, certificates, identity configuration, and recovery media under the supported process. An inference endpoint that works without internet access does not prove that deployment, updates, authentication, telemetry, or support workflows also work offline.

Checks I would make before adopting it

Classify repository data, prompts, completions, and model artifacts separately. Write down which systems receive each one.
For GitHub Copilot, confirm the required GitHub.com identity, license, network paths, and data-handling terms with your security and legal teams.
For Foundry Local, test the exact approved model on the actual device or cluster hardware. Measure latency and memory under the expected workload rather than using a different model or a developer workstation as a proxy.
For disconnected operations, verify setup, model staging, certificates, identity, updates, backups, and recovery without assuming that the inference path represents the entire service.
Track preview dependencies explicitly. Do not make a production commitment based only on an announced general-availability target.
Keep identity and authorization review separate from data-residency review. Check the app actually making each request, how tokens are issued, and what permissions those tokens carry.

The boundary still needs to be proved

GitHub Enterprise Local and Foundry Local give organizations more choice about where source code and AI inference run. That can be useful for regulated environments, sites with unreliable connectivity, and workloads where data should stay near its source. The trade is that local infrastructure brings more responsibility for capacity, updates, recovery, and testing.

I would evaluate each boundary on its own evidence, then document which services remain connected and which are genuinely able to operate offline. "Local" should describe a verified data path, not stand in for a complete security or sovereignty claim.