Upgrade on Kubernetes using Helm

Upgrade a Helm deployment of Anchore Enterprise to a newer release within the same major version.

This procedure upgrades a Helm deployment of Anchore Enterprise to a newer release within the same major version. Before you begin, review Prepare for the Upgrade.

This procedure applies to upgrades within v6.x only. If you are migrating from v5.x, follow the v5.x → v6.x Migration Guide.

If you use your own secret (useExistingSecrets: true), add ANCHORE_AUTH_SECRET to your Anchore Enterprise secret before upgrading to v6.1 or later. If you do not, some services will not start after the upgrade.

If you use the chart’s default secret (useExistingSecrets: false), you do not need to do anything. The chart creates this value automatically.

Database column encryption is optional and off by default, so it is not a prerequisite for this upgrade. To enable it, supply a key — either anchoreConfig.database.encryption.currentKey in your values file, or ANCHORE_DB_ENCRYPTION_KEY_CURRENT in your own secret if you use useExistingSecrets: true. You can do this during this upgrade or at any later point. See Encrypting Database Secrets at Rest.

Upgrading a cluster with no outbound internet access? See Air-Gapped Upgrade before you begin — you’ll need to mirror the new chart version and any updated images, including kubectlImage, before running helm upgrade below.

A Helm pre-upgrade hook initiates a Kubernetes job that scales down all active Anchore Enterprise pods and handles the Anchore Enterprise database upgrade.

The Helm upgrade is marked as successful only upon the job’s completion. This process causes the Helm client to pause until the job finishes and new Anchore Enterprise pods are initiated. To monitor the upgrade, you can follow the logs of the upgrade jobs:

kubectl get jobs -n ${NAMESPACE}
kubectl logs -f job/<JOB_NAME> -n ${NAMESPACE}

These jobs are automatically removed after a subsequent successful Helm upgrade.

Helm waits for the upgrade job to complete, with a default timeout of 5 minutes. On a very large deployment, or when a release includes database schema changes or similar data migrations, the upgrade job can run for much longer than that; if the timeout is reached, Helm marks the release as failed even though the job may still be working. For such upgrades, consider passing a longer --timeout to the helm upgrade command (for example --timeout 3600s for a one-hour window), sized to your deployment.

An alternative post-upgrade hook is available to perform Anchore Enterprise upgrades without forcing all pods to terminate prior to running the upgrade. To enable the post-upgrade hook, set upgradeJob.usePostUpgradeHook=true in your values file.

View both the Helm Chart Release Notes for any necessary steps prior to upgrading and also review the Anchore Enterprise Release Notes
Update the Helm repository to get the latest chart version.
```
helm repo update
```

Upgrade Anchore Enterprise using the Helm chart.

export NAMESPACE=anchore
export RELEASE=my-release

helm upgrade ${RELEASE} -n ${NAMESPACE} anchore/enterprise -f anchore_values.yaml

Review the helm upgrade command output
Once upgraded, you can review the new state of your Anchore Enterprise install to verify the new version is running using the regular system status command.
```
anchorectl system status
```

1 - 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.