Upgrade using Docker Compose

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

This procedure upgrades a Docker Compose 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. It reuses your existing volumes and configuration, which is not valid when migrating from v5.x. For that, follow the v5.x → v6.x Migration Guide.

Upgrading a host with no outbound internet access? See Air-Gapped Upgrade before you begin — you’ll need to mirror the new image tags to your registry (or move them as a tarball) before restarting the stack below.

Upgrade Procedure

Step 1: Review the Release Notes

View the Anchore Enterprise Release Notes for the target version.

Step 2: Match the Project Name and Volumes to Your Existing Deployment

Review the ’name’ and volume(s) used in your new compose file. Failure to match these to your existing deployment and older Compose file will result in a new/clean deployment rather than an upgrade.

name: "anchore-6010"
volumes:
  # Since this is for a quickstart, each minor version has its own db, to use a previous db and upgrade, change this
  # to the db volume name you want to upgrade from. e.g. "anchore-enterprise-6.0-db" if upgrading from a 6.0 quickstart deployment.
  # IMPORTANT: Do not change this volume name - it is used to persist data across minor version upgrades within this major version.
  anchore-enterprise-db:
    # Set this to 'true' to use an external volume. In which case, it must be created manually with "docker volume create anchore-db-volume"
    external: false

Do not rename anchore-enterprise-db or name — this is the volume name shared across all v6.x minor releases. Renaming it will cause Compose to create a new, empty database volume instead of upgrading the existing one.

Step 3: Stop Anchore Enterprise

docker compose down

Step 4: Back Up Your Original Compose File

cp docker-compose.yaml docker-compose.yaml.backup

Step 5: Download the Latest Compose File

curl https://docs.anchore.com/current/docs/deployment/docker_compose/docker-compose.yaml > docker-compose.yaml

Step 6: Merge Your Customizations into the New File

Review the latest docker-compose.yaml and merge any edits/changes from your original docker-compose.yaml.backup to the latest docker-compose.yaml.

Step 7: Restart the Anchore Enterprise Containers

docker compose up -d

Step 8: Monitor the Upgrade

To monitor the progress of your upgrade, you can watch the docker logs from your catalog container, where you should see some initial output indicating whether or not an upgrade is needed or being performed, followed by the regular Anchore Enterprise log output.

docker compose logs -f catalog

Step 9: Verify the New Version Is Running

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 Docker Compose

A routine v6.x upgrade in an air-gapped Docker Compose deployment just needs the new image tags mirrored to your registry (or moved as a tarball) before you restart the stack. Unlike the major-version migration, there’s no new compose file, no new Dockerfile.anchore-db, and no rebuild required — you’re bumping versions on a running deployment, not standing up a new one. Your docker-compose.yaml stays as-is, provided you don’t touch the name or database volume name (see Step 2 of the main upgrade procedure).

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

Prepare the Images (low side)

Review the Release Notes for the target version to confirm which image tags actually changed. enterprise/enterprise-ui always move together; redis (and, less often, the PostgreSQL/pg_cron combination baked into anchore:db) can change independently, so don’t assume they’re unchanged from your last upgrade — diff the new reference docker-compose.yaml and Dockerfile.anchore-db against what you last mirrored if you’re unsure.

Pull the images that changed:

docker pull docker.io/anchore/enterprise:v6.1.0
docker pull docker.io/anchore/enterprise-ui:v6.1.0
docker pull docker.io/redis:7.4.6

Only if Dockerfile.anchore-db changed for this release, rebuild the database image:
```
docker build -f Dockerfile.anchore-db -t anchore:db .
```
This is uncommon for a routine upgrade — most releases don’t touch the database image at all. If it didn’t change, skip this step; there’s nothing new to move for anchore-db.

Move the Images to the High Side

Choose one of the following, matching the equivalent step in the Air-Gapped Docker Compose deployment guide, for only the images that actually changed in step 2 (and step 3, if it applied):

Private container registry (recommended) — re-tag, then push directly, or save/transfer/load/push, exactly as described in Option 1.
Local image tarball — for hosts with no registry available, as described in Option 2.

Update Your Compose File

If this deployment was already deployed air-gapped, your docker-compose.yaml already points every image: line at your private registry or local image names — you only need to bump the tag on the lines that changed. The enterprise image is referenced by many services (api, catalog, component-catalog, queue, policy-engine, analyzer, reports, reports_worker, notifications, data-syncer, db-preflight), so update every occurrence:

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

Leave everything else in the file untouched — in particular, do not touch name: at the top of the file or the database volume name, per Step 2 of the main upgrade procedure. Changing either causes Compose to stand up a new, empty deployment instead of upgrading this one.

Restart the Stack

Continue with the main Upgrade using Docker Compose procedure starting at Step 7: Restart the Anchore Enterprise Containers — monitoring the catalog logs and verifying the new version with anchorectl system status need no changes for an air-gapped host.