> ## Documentation Index
> Fetch the complete documentation index at: https://arize-ax.mintlify.site/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Deployment types

> Choose how your cluster reaches the Arize AI distribution hub and container registries: connected, semi-restricted, or air-gapped.

Before you install, pick the path that matches your network and registry policy. Each tab describes one deployment type and links forward to cluster setup and install steps for your platform.

<Tabs>
  <Tab title="Connected">
    ## Summary

    Use this path when your install host can reach the distribution hub at **`ch.hub.arize.com`** and your cluster can pull container images from Arize AI's registries over the internet. **`ch.hub.arize.com`** covers distribution metadata and JWT-authenticated downloads; **`us-central1-docker.pkg.dev`** hosts the container images the chart pulls by default. Mirroring images into **your own** registry is optional unless policy requires it.

    ## Network and images

    * **Distribution:** Download with your JWT from `ch.hub.arize.com` as described in [Download and extract the distribution](/ax/selfhosting/getting-started/download-and-unpack-the-distribution).
    * **Images:** By default, workloads pull using the chart's **`pullRegistry`** (defaults align with Arize AI's hub and the Google Artifact Registry hosting for Arize AX images—see your release's **Advanced → Helm** for the exact strings).
    * **Telemetry (Call Home):** Defaults keep optional hub connectivity for platform alerts and metrics. Anything other than the defaults—including compliance-driven restrictions—is documented only under **Advanced → Helm** in the offline **`docs/`** bundle from your distribution archive (open `docs/index.html` locally).

    ## Firewall and script checks

    When you run `./arize.sh` operations that pull from the hub, the script may verify HTTPS reachability to **`ch.hub.arize.com`** and **`us-central1-docker.pkg.dev`**. If a step fails with a connectivity error, allowlist both endpoints (see [Semi-restricted](/ax/selfhosting/getting-started/deployment-types)) or ask your network team to open them for the install host.

    ## Private registry mirror

    If policy still requires every workload image to live in **your** registry—even though nodes have internet egress—mirror first, then point **`pullRegistry`** / **`pushRegistry`** at your hostname in `values.yaml` (see the platform-specific install walkthrough under [Installation](/ax/selfhosting/installation/index)).

    1. Authenticate Docker to your registry using your cloud provider's login flow. Common examples:
       * **GCP Artifact Registry:** `gcloud auth configure-docker us-central1-docker.pkg.dev`
       * **AWS ECR:** `aws ecr get-login-password | docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com`
       * **Azure ACR:** `az acr login --name <registry-name>`

    2. Run `./arize.sh` to pull from the Arize AI hub and push into your registry. Pass **`hubJwt`** as the **base64-encoded** JWT Arize AI gave you, **`cloud`** for your platform (`gcp`, `aws`, or `azure`), and **`pushRegistry`** set to your registry endpoint:

       ```bash theme={null}
       ./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>'
       ```

    3. Example registry hostnames (replace project, location, account, and repository):
       * **GCP Artifact Registry:** `us-central1-docker.pkg.dev/<project>/<repository>` (or legacy `gcr.io/<project-id>`)
       * **AWS ECR:** `<account>.dkr.ecr.<region>.amazonaws.com/<repository>`
       * **Azure ACR:** `<registry-name>.azurecr.io/<repository>`

    4. Verify images exist in your registry before `helm upgrade --install`.

    If **no single host** can reach both the public hub **and** your private registry **and** the cluster (common in split networks), use the workflows on [Air-gapped](/ax/selfhosting/getting-started/deployment-types) instead of this page's mirror shortcut.

    ## Next steps

    1. [Install Arize AX](/ax/selfhosting/installation/index) after images are in your registry—for operator values and **`./arize.sh`**.
    2. [Configure ingress](/ax/selfhosting/installation/ingress/configuring-endpoints) or [another controller](/ax/selfhosting/installation/ingress/other-controllers).
    3. [Validate the deployment](/ax/selfhosting/installation/validate-deployment).
  </Tab>

  <Tab title="Semi-restricted">
    ## Summary

    Use this path when outbound traffic is limited to allowlisted destinations or must go through a corporate proxy. You will open the same endpoints Arize AI uses for distribution and images, then follow the same install flow as a [connected](/ax/selfhosting/getting-started/deployment-types) deployment unless policy requires a private registry mirror.

    ## Network and images

    * **Distribution:** Download with your JWT from `ch.hub.arize.com` as described in [Download and extract the distribution](/ax/selfhosting/getting-started/download-and-unpack-the-distribution).
    * **Images:** By default, workloads pull from Arize AI's hub (`pullRegistry` defaults to `ch.hub.arize.com` in the chart)—once egress to those hosts is allowlisted or routed through your proxy.
    * **Telemetry (Call Home):** Same defaults as the [Connected](/ax/selfhosting/getting-started/deployment-types) deployment type. Non-default configuration is covered only in **Advanced → Helm** in the offline **`docs/`** bundle from your distribution archive.
    * **Private registry:** Optional; only if policy requires every workload to pull from your own registry.

    ## Allowlist

    Ensure these can be reached from your build hosts and, where applicable, from nodes or pull-through caches:

    * `ch.hub.arize.com` — distribution downloads and metadata
    * `us-central1-docker.pkg.dev` — Arize AX container images

    `./arize.sh` may perform HTTPS reachability checks against both endpoints when pulling from the hub. Add any proxy or firewall exceptions your security team requires.

    ## Cluster egress

    Nodes still need to reach your cloud provider's APIs (Kubernetes control plane, object storage for Gazette and ArizeDB buckets, and any other services you enable). Work with your platform team to confirm egress paths for those APIs. For platform-specific cluster, bucket, IAM, and identity setup, see the cluster guides under [Installation](/ax/selfhosting/installation/index) (for example *Existing cluster* and *Terraform* pages for GCP, Azure, or AWS).

    ## Private registry mirror

    If policy requires images in **your** registry:

    1. Authenticate Docker to your registry using your cloud provider's login flow. Common examples:
       * **GCP Artifact Registry:** `gcloud auth configure-docker us-central1-docker.pkg.dev`
       * **AWS ECR:** `aws ecr get-login-password | docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com`
       * **Azure ACR:** `az acr login --name <registry-name>`

    2. Run `./arize.sh` to pull from the Arize AI hub into your registry. Pass **`hubJwt`** as the **base64-encoded** JWT, **`cloud`** for your platform (`gcp`, `aws`, or `azure`), and **`pushRegistry`**:

       ```bash theme={null}
       ./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>'
       ```

    3. Example registry hostnames (replace project, location, account, and repository):
       * **GCP Artifact Registry:** `us-central1-docker.pkg.dev/<project>/<repository>` (or legacy `gcr.io/<project-id>`)
       * **AWS ECR:** `<account>.dkr.ecr.<region>.amazonaws.com/<repository>`
       * **Azure ACR:** `<registry-name>.azurecr.io/<repository>`

    4. Verify that your images have arrived in your registry.

    ## Next steps

    1. [Install Arize AX](/ax/selfhosting/installation/index) after images are in your registry—for operator values and **`./arize.sh`**.
    2. [Configure ingress](/ax/selfhosting/installation/ingress/configuring-endpoints) or [another controller](/ax/selfhosting/installation/ingress/other-controllers).
    3. [Validate the deployment](/ax/selfhosting/installation/validate-deployment).
  </Tab>

  <Tab title="Air-gapped">
    ## Summary

    Use this path when the **cluster** (or your regulated network) cannot pull from Arize AI's image registry or reach `ch.hub.arize.com`. You still need the distribution tarball and container images in a **private registry** your nodes can reach. Pick **one** workflow below depending on whether any machine can reach Arize AI to mirror images, or you must move payloads offline.

    ## Choose your path

    | Situation                                                                                    | Image source                                                                                         | Typical `./arize.sh` flow                                                  |
    | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------- |
    | **A** — Bastion or CI can reach **both** Arize AI's image registry and your private registry | Mirror from hub into your registry on one host                                                       | `load-remote-images`                                                       |
    | **B** — One host has internet; another reaches only your registry and the cluster            | Pull/save on internet host; transfer `images/`; push/install inside                                  | `pull-images` → `save-images` → *transfer* → `load-images` → `push-images` |
    | **C** — Cluster is isolated; runtime pulls **only** from your registry                       | Same as A or B for loading images; `pullRegistry` / `pushRegistry` always point at **your** registry | See A or B                                                                 |

    `./arize.sh load-remote-images` **requires a host that can reach Arize AI** (it logs in to the hub and pulls). It is **not** a substitute for cluster egress—it is how you **populate** a private registry before the isolated cluster pulls from it.

    ### Step 0 — Distribution without cluster internet

    If you cannot run `curl` from the target network, obtain the tarball through your approved transfer process, then extract it. See [Download and extract the distribution](/ax/selfhosting/getting-started/download-and-unpack-the-distribution) for layout (`arize.sh`, `arize-operator-chart.tgz`, bundled docs).

    ## Network and images

    * Workloads must pull from **your** registry only: set **`pullRegistry`** (and **`pushRegistry`** when mirroring) to that registry's hostname. **Helm and the operator** use `pullRegistry` for pod image strings; **`arize.sh`** needs `pushRegistry` when pushing mirrored layers—use the **same** registry hostname for both unless Arize AI has given you a different layout.
    * Use the [installation page for your platform](/ax/selfhosting/installation/index) for the full operator field list when you reach install. Plan DNS and TLS for the UI inside the isolated network; [ingress](/ax/selfhosting/installation/ingress/configuring-endpoints) applies once workloads are running.

    ## Authenticate Docker to your registry

    The host that runs **`push-images`** or **`load-remote-images`** must be able to **push** to `pushRegistry`. Use whichever login flow your registry expects:

    * **GCP Artifact Registry:**

      ```bash theme={null}
      gcloud auth configure-docker us-central1-docker.pkg.dev
      ```

      For service accounts and CI, use `gcloud auth activate-service-account` followed by `gcloud auth configure-docker`, or a JSON key with `docker login`.

    * **AWS ECR:**

      ```bash theme={null}
      aws ecr get-login-password --region <region> \
        | docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com
      ```

    * **Azure ACR:**

      ```bash theme={null}
      az acr login --name <registry-name>
      ```

    * **Generic private registry:** use `docker login <registry-host>` with the credentials your platform team provides.

    Cluster nodes pull using the chart's configuration (Workload Identity, IRSA, AAD Pod Identity, or an explicit pull secret depending on your platform). Confirm any required pull secrets or identity bindings with your platform team.

    ## Choose one workflow

    Work from the extracted directory that contains `arize.sh`, `arize-operator-chart.tgz`, and the bundled chart and docs (see [Download and extract](/ax/selfhosting/getting-started/download-and-unpack-the-distribution)).

    ### A — Bastion can reach the internet and your private registry

    Use one machine that can reach both Arize AI's hub and your registry.

    Authenticate Docker to your registry, then mirror with **`-f none`** and **`-y`** for non-interactive runs, passing comma-separated `key=value` pairs in a single quoted string (no spaces inside the list). Set **`cloud`** to the platform you're installing on (`gcp`, `aws`, or `azure`).

    ```bash theme={null}
    ./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>'
    ```

    `load-remote-images` pulls from the hub into Docker, retags, and pushes to **`pushRegistry`** (see **`./arize.sh help`**).

    ### B — Split network (internet host vs internal host)

    Use when one host can reach **the internet** and another can reach **your registry and the cluster**, but not both.

    **Setup (both hosts):** Use the **same** **`hubJwt`**, **`cloud`**, registry endpoints, and optional flags on every step that reads them so image tags stay aligned.

    | Step                         | Needs hub or registry settings?                         |
    | ---------------------------- | ------------------------------------------------------- |
    | `pull-images`, `save-images` | Yes — **`hubJwt`**, **`cloud`**                         |
    | `load-images`                | No — imports Docker data from the `images/` folder only |
    | `push-images`                | Yes — **`push-images`** requires **`pushRegistry`**     |

    **Phase 1 — Internet-connected host**

    ```bash theme={null}
    ./arize.sh -f none -y pull-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>'
    ./arize.sh save-images
    ```

    Transfer the **`images/`** directory to the internal host (encrypted media, approved gateway, etc.).

    **Phase 2 — Internal host (registry + cluster access)**

    ```bash theme={null}
    ./arize.sh load-images
    ./arize.sh -f none -y push-images 'cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>,pullRegistry=<YOUR_REGISTRY>'
    ```

    Use `save-images` / `load-images` only when you must move image payloads between machines. **`hubJwt`** is required on any step that pulls from the hub (`pull-images`, or `load-remote-images` on path A).

    For digest-preserving copies without loading into local Docker, you can use **`./arize.sh --skopeo load-remote-images`** where supported; coordinate with Arize AI on upgrade expectations when changing pull modes.

    ## Image references and upgrades

    By default, image references use **tags**. The chart supports `imagePullMode` values that change how image strings are built (for example digest-style references). Pushing through Docker may not preserve the same digest as upstream; for immutable digest pulls from a private registry, consider **skopeo**-style workflows and coordinate with Arize AI on upgrades.

    ## Additional reference

    For multi-cloud variants and extended parameters, use **Advanced → Helm** in the offline HTML docs under **`docs/`** in the tarball (open `docs/index.html`) alongside materials from Arize AI.

    ## Next steps

    1. [Install Arize AX](/ax/selfhosting/installation/index) after images are in your registry—for operator values and **`./arize.sh`**.
    2. [Configure ingress](/ax/selfhosting/installation/ingress/configuring-endpoints) or [another controller](/ax/selfhosting/installation/ingress/other-controllers).
    3. [Validate the deployment](/ax/selfhosting/installation/validate-deployment).
  </Tab>
</Tabs>