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.

Answers to common self-hosted install questions. For step-by-step instructions, follow the linked pages.

Distribution and access

Release versions are listed in Self-hosted Releases. The tarball is not a public download; Arize provides the distribution access JWT or download command, along with any storage or registry guidance for your environment. See Download and unpack the distribution.
Check Self-hosted Releases and use an exact published version. Review any upgrade notes for that release before installing.
Use the online docs for the current install flow and planning guidance. Use the docs shipped inside the distribution tarball for release-specific commands, chart behavior, and troubleshooting tied to that release.

Cluster and infrastructure

No. You can use Terraform from Arize, your own automation, or an existing cluster. Terraform is optional. The requirement is that the cluster and supporting resources match the install path you choose. See Prerequisites.
Common production values are small1b and medium2b, and each profile requires nodes that match the sizing table in Prerequisites. Do not pick small1b or medium2b for clusters whose nodes are smaller than the table specifies. Contact Arize AI for guidance.
  • Connected: install workstation and cluster nodes can reach Arize distribution and image registry endpoints directly.
  • Semi-air-gapped: install workstation can reach Arize endpoints, but cluster nodes pull images from an internal registry.
  • Fully air-gapped: neither workstation nor cluster can reach Arize endpoints. Distribution files and images must move through your approved offline process.

Running the install

Run it from the extracted distribution directory, the same directory that contains arize.sh and your values.yaml. See Download and unpack the distribution.
In the extracted distribution directory, next to arize.sh. Start from the installation page that matches your environment in Deployment options.
No. Use dedicated namespaces for Arize AX, such as the default arize and arize-operator namespaces. If your environment uses different namespace names, keep them dedicated to this Arize install. Do not mix unrelated workloads into the Arize namespaces, because upgrades, support commands, and cleanup steps assume the namespaces belong to Arize AX.
Secret-bearing fields (such as hubJwt, postgresPassword, cipherKey, minioPassword) must be base64-encoded. Plain identifiers (cluster names, organization names, bucket names, storage class names, registry hostnames, URLs) must not.
Plan for roughly 30 to 90 minutes from arize.sh install to all pods running, depending on cluster size, image pull speed, and whether the cluster has a separate ArizeDB node pool. The default arize.sh timeout is short for slower clusters; pass -t 5400 to allow 90 minutes for the full install. Time is mostly spent pulling images and waiting for init jobs (install-postgres-init, install-minio-init, install-gazette-init, install-druid-init) to complete.
Yes, but treat it as a planned change. Update clusterSizing in values.yaml and re-apply with arize.sh. Sizing changes can move pods between node pools and resize PVCs, so confirm node capacity matches the new profile before applying. Contact Arize AI before moving between major profiles (for example, nonha to medium2b).
For connected installs, the workstation needs outbound HTTPS to Arize AX distribution endpoints (ch.hub.arize.com) and to the image registry referenced by your distribution. The cluster nodes need outbound HTTPS to the same image registry, or to your internal mirror for restricted-network installs. See Deployment Types for connected, semi-air-gapped, and fully air-gapped flows.
Download the new distribution into a separate release directory (see Create a release directory), copy or update your values.yaml, and run arize.sh from the new release directory. The bundled docs inside that release explain release-specific upgrade steps. Contact Arize before upgrading across major versions.
Follow Fresh reinstall cleanup. The procedure works on any Kubernetes cluster, including managed cloud, OpenShift, Rancher, and bare metal. It covers the order of helm uninstall, namespace cleanup, force-deleting pods stuck on long graceful termination, and the last-resort namespace finalizer step. The PVC deletion in that procedure is destructive; do not run it without a backup or restore plan.