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.

Check your database’s pg_cron logging settings. If cron.log_run and cron.log_statement are still at their default of on, pg_cron records every maintenance-job run in a table that is never pruned, and in the database server log. Anchore recommends turning both off. This is a database setting, separate from the chart, and it can be changed before or after this upgrade. See Limit pg_cron Logging.

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
```

Rebuild an In-Cluster CloudNativePG Image

If you run PostgreSQL in-cluster with CloudNativePG (CNPG) and built your pg_cron image on the plain ghcr.io/cloudnative-pg/postgresql:17 tag, rebuild it on a current base. That tag points to a Debian 11 (bullseye) image that CNPG no longer updates, and the PostgreSQL APT repository no longer serves pg_cron packages for Debian 11, so the image can no longer be rebuilt. This is separate from the Anchore Enterprise upgrade, so you can do it before or after running helm upgrade.

Move built-in Barman Cloud backups to the plugin first. Check whether your cluster uses CNPG’s built-in barmanObjectStore backups:
```
kubectl get cluster anchore-pg -n anchore -o jsonpath='{.spec.backup.barmanObjectStore}'
```
If this prints anything, migrate to the Barman Cloud Plugin before you change images. The new base image does not include the Barman Cloud tools that built-in backups run, so WAL archiving would fail and PostgreSQL would keep WAL files until the volume fills. Empty output means no action is needed.
Rebuild the image with the Dockerfile in Run PostgreSQL In-Cluster with CloudNativePG, and push it under a new tag, such as 17-trixie. Do not push over the tag your cluster already uses.
Point the cluster at the new tag. CNPG updates running instances only when imageName changes, so an image pushed under the existing tag is never rolled out. Set imageName in cnpg-cluster.yaml to the new tag, then apply it:
```
kubectl apply -f cnpg-cluster.yaml
kubectl get cluster anchore-pg -n anchore -w
```
CNPG restarts the instances one at a time, primary last. With a single instance, the database is unavailable while its pod restarts.
Reindex if you changed the collation. The new base moves PostgreSQL from Debian 11 to Debian 13, which ships a newer glibc. A cluster created as shown in the deployment guide uses the C collation, which this change does not affect. Check yours:
```
kubectl exec -it anchore-pg-1 -n anchore -- \
  psql -U postgres -d anchore -c "SELECT datcollate FROM pg_database WHERE datname = 'anchore';"
```
If the result is anything other than C, run REINDEX DATABASE anchore; during a maintenance window after the rollout.

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.3.0
docker pull docker.io/anchore/enterprise-ui:v6.3.0
docker pull docker.io/redis:<redis-tag-from-step-2>
docker pull docker.io/bitnamilegacy/kubectl:<kubectl-tag-from-step-2>
```
The v6.3.0 / v6.3.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.3.0

ui:
  image: <registry>/anchore/enterprise-ui:v6.3.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.