Skip to main content

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.

​
Summary

Use this path when the cluster (or your regulated network) cannot pull from Arize 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 to mirror images, or you must move payloads offline.

​
Choose your path

SituationImage sourceTypical ./arize.sh flow
A — Bastion or CI can reach both Arize and your private registryMirror from hub into your registry on one hostload-remote-images
B — One host has internet; another reaches only your registry and the clusterPull/save on internet host; transfer images/; push/install insidepull-images → save-images → transfer → load-images → push-images
C — Cluster is isolated; runtime pulls only from your registrySame as A or B for loading images; pullRegistry / pushRegistry always point at your registrySee A or B
./arize.sh load-remote-images requires a host that can reach Arize (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 has given you a different layout.
  • Use the quick start and walkthrough 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:
  • User or gcloud (common on a bastion):
gcloud auth configure-docker
For Artifact Registry, scope to the host you use, for example: 
gcloud auth configure-docker us-docker.pkg.dev
  • Service account or CI: JSON key or access token and docker login, or gcloud auth activate-service-account then gcloud auth configure-docker, per your platform standard.
GKE nodes pull using the chart’s configuration (for example Workload Identity). Confirm any extra pull secrets 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’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). 
./arize.sh -f none -y load-remote-images 'hubJwt=<BASE64_JWT>,cloud=gcp,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.
StepNeeds hub or registry settings?
pull-images, save-imagesYes — hubJwt, cloud
load-imagesNo — imports Docker data from the images/ folder only
push-imagesYes — push-images requires pushRegistry
Phase 1 — Internet-connected host 
./arize.sh -f none -y pull-images 'hubJwt=<BASE64_JWT>,cloud=gcp'
./arize.sh save-images
Transfer the 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,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 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 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.

​
Next steps

  1. Provision or use a GKE cluster (or Terraform).
  2. Install Arize (quick start) or detailed walkthrough after images are in your registry—for operator values and ./arize.sh.
  3. Configure ingress or another controller.
  4. Validate the deployment.