Upgrade Air-Gapped using Helm

A routine v6.x upgrade in an air-gapped cluster needs the new chart version and any updated images mirrored to your registry before you run helm upgrade. This mirrors the same low-side/high-side process as Air-Gapped Helm deployment, but there’s less to move — you’re bumping versions on a running deployment, not standing up a new cluster.

Throughout this guide, the low side is the internet-facing system and the high side is the air-gapped cluster.

Prepare the Chart and Images (low side)

Find the new chart version and download it:

helm repo update
helm search repo anchore/enterprise

export CHART_VERSION="<new-chart-version-from-above>"

helm pull anchore/enterprise --version ${CHART_VERSION}

Check what images that chart version actually references — redis and kubectlImage can change between chart releases independent of the Anchore Enterprise application version, so don’t assume they’re unchanged from your last upgrade:
```
helm show values anchore/enterprise --version ${CHART_VERSION} | grep -E "^image:|repository:|tag:"
```
Pull the images:
```
docker pull docker.io/anchore/enterprise:v6.1.0
docker pull docker.io/anchore/enterprise-ui:v6.1.0
docker pull docker.io/redis:<redis-tag-from-step-2>
docker pull docker.io/bitnamilegacy/kubectl:<kubectl-tag-from-step-2>
```
The v6.1.0 / v6.1.0 shortcodes always resolve to the version this documentation site currently covers. If you are upgrading to a different release, substitute that release’s actual tag instead.
Unlike a fresh install, kubectlImage is always required for an upgrade, minor or major — the pre-upgrade hook (or the post-upgrade hook, if upgradeJob.usePostUpgradeHook: true) uses it to scale Anchore Enterprise pods during the upgrade.

Move the Chart and Images to the High Side

Choose one of the following, matching the equivalent step in the Air-Gapped Helm deployment guide:

Private container registry (recommended) — re-tag, then save/transfer/load, then push from the high side, exactly as described in Option 1, but for the images pulled above.
Local import onto cluster nodes — for small clusters with no registry available, as described in Option 2.
Internal Helm repository or GitOps source — push the chart .tgz to your OCI registry or chart repository as described in Push the Chart to an Internal Helm Repository or GitOps Source.

Also transfer enterprise-${CHART_VERSION}.tgz to the high side along with the images.

Update Your Values File

If this cluster was deployed air-gapped, your existing anchore_values.yaml already points image, ui.image, and ui-redis.image at your private registry — you only need to bump the tags to the new version:

image: <registry>/anchore/enterprise:v6.1.0

ui:
  image: <registry>/anchore/enterprise-ui:v6.1.0

ui-redis:
  image:
    tag: <redis-tag-from-step-2>

kubectlImage: <registry>/bitnamilegacy/kubectl:<kubectl-tag-from-step-2>

If kubectlImage isn’t already set — for example, if this cluster’s values file hasn’t changed since a fresh install, which never uses it — add it now. See Deploy on the High Side on the deployment air-gapped page for the full registry-override block if you need the other image fields too.

Run the Upgrade from the Local Chart

Substitute the local chart archive — or your internal registry reference — for anchore/enterprise:

export NAMESPACE=anchore
export RELEASE=my-release

helm upgrade ${RELEASE} -n ${NAMESPACE} ./enterprise-${CHART_VERSION}.tgz -f anchore_values.yaml --timeout 3600s

or, from an internal OCI registry:

helm upgrade ${RELEASE} -n ${NAMESPACE} oci://<registry>/charts/enterprise --version ${CHART_VERSION} -f anchore_values.yaml --timeout 3600s

Continue with the rest of Upgrade on Kubernetes using Helm — monitoring the upgrade job logs and verifying with anchorectl system status — exactly as written.