Documentation Index
Fetch the complete documentation index at: https://arize-ax.mintlify.dev/docs/llms.txt
Use this file to discover all available pages before exploring further.
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.
Connected
Semi-restricted
Air-gapped
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.
- 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) 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).
-
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>
-
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:
./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>'
-
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>
-
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 instead of this page’s mirror shortcut.Next steps
- Install Arize AX after images are in your registry—for operator values and
./arize.sh.
- Configure ingress or another controller.
- Validate the deployment.
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 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.
- 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 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 metadataus-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 (for example Existing cluster and Terraform pages for GCP, Azure, or AWS).Private registry mirror
If policy requires images in your registry:
-
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>
-
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:
./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>'
-
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>
-
Verify that your images have arrived in your registry.
Next steps
- Install Arize AX after images are in your registry—for operator values and
./arize.sh.
- Configure ingress or another controller.
- Validate the deployment.
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 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 for the full operator field list when you reach install. Plan DNS and TLS for the UI inside the isolated network; ingress 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:
gcloud auth configure-docker us-central1-docker.pkg.dev
gcloud auth activate-service-account followed by gcloud auth configure-docker, or a JSON key with docker login.
-
AWS ECR:
aws ecr get-login-password --region <region> \
| docker login --username AWS --password-stdin <account>.dkr.ecr.<region>.amazonaws.com
-
Azure ACR:
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).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)../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 |
./arize.sh -f none -y pull-images 'hubJwt=<BASE64_JWT>,cloud=<gcp|aws|azure>'
./arize.sh save-images
images/ directory to the internal host (encrypted media, approved gateway, etc.).Phase 2 — Internal host (registry + cluster access)./arize.sh load-images
./arize.sh -f none -y push-images 'cloud=<gcp|aws|azure>,pushRegistry=<YOUR_REGISTRY>,pullRegistry=<YOUR_REGISTRY>'
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
- Install Arize AX after images are in your registry—for operator values and
./arize.sh.
- Configure ingress or another controller.
- Validate the deployment.
