Foundry Local on Azure Local in disconnected environments overview

You can deploy Foundry Local on Azure Local in disconnected environments by using a deployment model that largely matches connected scenarios. However, several key differences exist when internet connectivity isn't available.

This article explains how disconnected deployments of Foundry Local on Azure Local differ from connected deployments, so you can plan secure, offline model operations.

What changes in disconnected deployments

In disconnected environments, extension availability, certificate management, model artifact sourcing, telemetry behavior, identity, and access flows differ from connected deployments.

• Extension availability: Before you can install the Foundry Local Azure Arc extension, you must download and import the Foundry Local expansion pack into the disconnected environment.

• Model catalog source: Foundry Local pulls model artifacts from the local edgeartifacts container registry. Model expansion packs populate this registry.

• Bundled networking dependencies: In disconnected deployments, the Foundry Local expansion pack provides the networking dependencies that connected deployments pull from online sources. During expansion pack installation, these assets are imported into edgeartifacts, including Istio control plane components (istio-base, istiod), Kubernetes Gateway API custom resource definitions (CRDs), Gateway API Inference Extension CRDs (including InferencePool), and the Endpoint Picker (EPP) container image.

• Deployment-time internet dependency: Because these dependencies are imported locally through the expansion pack, deployment doesn't require outbound internet connectivity to install those networking components.

• Certificate management: The azure-cert-manager extension isn't available in disconnected environments. Instead, you must install:

  cert-manager trust-manager

  These Helm charts and container images are included in the Foundry Local expansion pack.

• Telemetry: Telemetry isn't transmitted to Microsoft. To collect diagnostics for support, use the az k8s-extension troubleshoot command.

• Authentication: Authentication doesn't use public Microsoft Entra ID endpoints. Instead, Foundry Local integrates with the Active Directory infrastructure configured in the disconnected Azure Local environment.

• Authorization: Authorization uses standard Azure RBAC roles on the Foundry extension resource:

  • Reader is for read-only operations, such as listing and getting model catalog entries.
  • Contributor is required for control plane write operations (for example POST, PUT, PATCH, DELETE for models and deployments) and for data plane inference operations such as predict and chat/completions.

  This authorization model differs from connected deployments, which typically use roles such as Cognitive Services OpenAI User to grant access to inference endpoints.

• GPU dependency packaging: In disconnected Autonomous environments, mirror nvidia/k8s-device-plugin:v0.11.0 into edgeartifacts at the path expected by the auto-deployed DaemonSet.

• Model evaluation: Evaluations run fully on the cluster. No evaluation data leaves the disconnected environment.

Capacity considerations for disconnected clusters

When you size a disconnected cluster, include baseline capacity for both model serving and supporting components.

• For multireplica vLLM deployments, plan for one extra EPP pod per ModelDeployment.
• The default EPP resources are about 512 MiB memory request and 2 GiB memory limit per deployment.
• The default az aksarc create worker size (Standard_A4_v2) is usually too small for Foundry Local model caching and serving workflows.

For configuration details, see ModelDeployment and operator configuration reference. For failure symptoms and remediation guidance, see Troubleshoot Foundry Local on Azure Local in disconnected environments.

Architecture summary

Foundry Local on Azure Local in disconnected environments uses the same Arc-enabled Kubernetes cluster and operator-based control plane as connected deployments. The key difference is that catalog model artifacts and extension components are imported into the disconnected environment through locally installed expansion packs, rather than pulled from internet-connected registries.

At a high level:

• The Kubernetes inference operator watches cluster state and reconciles model resources, as in connected deployments.
• You define Model and ModelDeployment resources as the declarative units for model metadata and runtime intent.
• For catalog models, a cache job pulls model artifacts from the local EdgeArtifacts container registry instead of fetching from the Foundry cloud catalog. You populate this registry by importing Foundry model expansion packs before installation.
• You can pull BYO models from a customer-managed OCI-compatible container registry within the disconnected environment.
• Applications call inference endpoints through internal services or gateway API routes. Authentication integrates with your local Active Directory infrastructure instead of relying on public Microsoft Entra ID endpoints.
• You can evaluate deployed models against test datasets by using NLP metrics or a second model as a judge. Evaluation data stays on the cluster and doesn't leave the environment.

The following diagram shows how these components work together in a disconnected environment.

For connected architecture context, see What is Foundry Local on Azure Local?

Next step

Related content

• Deployment overview for Foundry Local on Azure Local
• Deploy Foundry Local on Azure Local in a disconnected environment
• Deploy your first model in a disconnected environment
• Configure authentication and authorization for Foundry Local on Azure Local in disconnected environments
• Troubleshoot Foundry Local on Azure Local in disconnected environments