Anchore Enterprise and its components are delivered as Docker container images which can be deployed as co-located, fully distributed, or anything in-between. Anchore Enterprise can run on a single host or be deployed in a scale out pattern for increased analysis throughput.
To get up and running, jump to the following guides of your choosing:
Anchore Enterprise Container Images
You need a Dockerhub PAT from Anchore Customer Success in order to download the Anchore Enterprise Container Images
This section details the general requirements for running Anchore Enterprise. For a conceptual understanding of Anchore Enterprise, please see the Overview topic prior to deploying the software.
Runtime
Anchore Enterprise requires a Docker compatible runtime (version 1.12 or higher) on either AMD or Intel-based amd64 architecture.
Deployment is supported on:
Docker Compose (only recommended for testing, for example demo or proof-of-concept < 1000 SBOMs)
Any Kubernetes Certified Service Provider (KSCP) as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
Any Kubernetes Certified Distribution as certified by the Cloud Native Computing Foundation (CNCF) via Helm.
Amazon Elastic Container Service (ECS) via Helm.
Resourcing
Use-case and usage patterns will determine the resource requirements for Anchore Enterprise. When deploying via Helm (package manager for Kubernetes), requests and limits are set in the values.yaml file. When deploying via Docker Compose, add reservations and limits into your Docker Compose file. The following recommendations can get you started:
Requests specify the desired resource amounts for the container, while limits specify the maximum resource amounts the container is allowed. To achieve best QoS (quality-of-service) with Helm deployments, it’s recommended to set requests equal to limits for allocated memory units and to set requests only with no limits set for allocated CPU units.
It’s not recommended to set less than 1 CPU unit for any container. Less than this could result in unexpected behaviour and should only be used in testing scenarios.
For the api, catalog, policy, and postgresql service containers, a minimum of 2 CPU units is recommended.
For Production use with Helm deployments, it’s recommended to set memory units to a minimum of 16G for the analyzer and policy services and 8G for all other services - where requests equals limits for all services. Less than these values could result in OOM errors or containers restarting unexpectedly.
If you intend on using Kubernetes, the default values.yaml found in the Anchore Enterprise Helm Chart provides some resourcing recommendations to get you started.
The memory footprint for Production use is recommended to better support performance improvements with the image analysis system in recent versions of Anchore Enterprise in addition to high-volume workloads, where a substantial number of images are being analyzed.
When considering horizontal scaling, generally look to maintain a 4:1 analyzer service to core services (api, catalog, and policy) ratio. For example, an 4 analyzer deployment should generally have 1 api, 1 catalog, and 1 policy replica. An 8 analyzer deployment should generally have 2 api, 2 catalog, and 2 policy replicas.
Database
The only service dependency strictly required by Anchore Enterprise is a PostgreSQL database (17.x or higher) that all services connect to. The database is centralized simply for ease of management and operation. For an architectural overview, go to Anchore Enterprise Architecture.
Anchore Enterprise v6 now requires the pg_cron extension in addition to PostgreSQL 17 or higher. We also recommend setting cron.use_background_workers = on in the PostgreSQL configuration.
Use a managed service such as Amazon RDS for PostgreSQL, or a self-managed instance such as CloudNativePG (CNPG).
For production deployments, Anchore Enterprise does not ship with a database service.
Helm: The Anchore Enterprise Helm chart does not include a bundled PostgreSQL database. Provision an external PostgreSQL 17 instance with the pg_cron extension before deploying. This may mean building a custom PostgreSQL 17 image that includes pg_cron and pushing it to a registry your cluster can reach.
Docker Compose: The Compose deployment includes a PostgreSQL container, built from a Dockerfile that adds pg_cron automatically. Docker Compose is intended for testing and evaluation only; use an external, managed database for production.
Anchore Enterprise is database-intensive. Depending on the scale of the deployment, hundreds to thousands of concurrent connections may be required. The PostgreSQL database used for Anchore Enterprise should be dedicated and not co-located with any other applications that use a PostgreSQL backend. Anchore Enterprise requires a readable and writable PostgreSQL endpoint; read replica endpoints are not supported at this time.
Anchore Enterprise uses this database to provide persistent storage for image, policy and analysis data. Database storage requirements are based on the number of SBOMs and how long these need to be stored in the active set (i.e. not archived to analysis archive/s3 or deleted). Each SBOM and its respective packages are indexed in the DB, so SBOM complexity also requires increased database storage. Runtime adds a further requirement here.
As an Anchore Enterprise deployment grows (whether through a larger volume of SBOMs, higher analysis throughput, or longer data retention), the database requires proportionally more storage, CPU, and memory. Plan to scale these resources in step with your deployment’s growth.
We suggest configuring a default artifact lifecycle policy and/or archival rules and monitoring database storage usage closely according to your use-case. Size your initial DB as roughly 50MB per image in your active set and use object storage for archive (see below).
For production deployments, we recommend monitoring database storage, CPU, and memory usage continuously (for example, using Prometheus and Grafana). Set alerts for approaching resource thresholds so you can scale proactively. Also keep in mind that certain backup strategies (for example, logical dumps or snapshot-based backups) may temporarily require a significant amount of additional free storage on the database volume.
Anchore Enterprise upgrade paths are forward-only; rollback is not supported. A database backup taken immediately before an upgrade is your only recovery path. Due to the wide variation in deployment methodologies and configurations inherent to on-premise software, Anchore cannot prescribe a specific backup strategy. You are responsible for establishing and testing a backup and recovery procedure that is appropriate for your environment.
We recommend against using connection pooling for your database (such as pg_bouncer), as it has been known to cause issues with Anchore Enterprise, which does its own connection pooling using SQLAlchemy.
Shared Memory
Anchore Enterprise ingests SBOMs through PostgreSQL queries that may execute in parallel. PostgreSQL’s parallel workers communicate via dynamic shared memory (/dev/shm on Linux), and ingesting large SBOMs can request 20 MiB or more per query. Ensure the database host has sufficient shared memory available:
Kubernetes / Helm: If running PostgreSQL in-cluster, mount a tmpfs volume at /dev/shm of at least 1 GiB on the database container, with 2-4 GiB recommended for high-throughput deployments or when work_mem is tuned above defaults. When using an external managed database, this is handled by your provider.
Amazon RDS / Aurora: AWS sizes shared memory per instance class. No customer-side tuning is required, but very small instance classes (for example db.t3.micro) may struggle with large SBOMs under concurrency. Size your instance to your expected SBOM workload.
Self-managed PostgreSQL: The Linux tmpfs default (typically half of system RAM) is generally sufficient. If you have explicitly constrained /dev/shm, size it as roughly work_mem × max_parallel_workers_per_gather per concurrent query, with a minimum of 1 GiB.
Insufficient shared memory typically manifests as transient could not resize shared memory segment errors during SBOM upload, particularly for SBOMs containing many thousands of packages.
External Object Store
Configuring an external object store can significantly reduce database size and total cost of ownership (TCO) by offloading analysis data to object storage (for example, Amazon S3).
When using an external object store alongside the database, both must be backed up at the exact same point in time to ensure data consistency. Use a coordinated backup service (for example, AWS Backup) that can snapshot both resources simultaneously.
Network
An Anchore Enterprise deployment requires the following three categories of network access:
Service Access
Connectivity between Anchore Enterprise services, including access to an external database.
Registry Access
Network connectivity, including DNS resolution, to the registries from which Anchore Enterprise needs to download images.
Anchore Data Service (ADS) Access
Anchore Enterprise requires access to the datasets in order to perform analysis and vulnerability matching. See Anchore Enterprise Data Feeds for more information.
The Data Syncer service needs to communicate with the Anchore Data Service and it may be necessary to whitelist the Anchore Data Service endpoint if it’s blocked within your environment for proper dataset retrieval. See Data Synchronization for more information.
Security
Anchore Enterprise is deployed from source repositories or container images that can be run manually using Docker Compose, Kubernetes, or any other supported container platform.
By default, Anchore Enterprise does not require any special permissions. It can be run as an unprivileged container with no access to the underlying Docker host.
Anchore Enterprise can be configured to pull images through the Docker socket. However, this configuration is not recommended, as it grants the Anchore Enterprise container added privileges and may incur a performance impact on the underlying Docker host.
Storage
Anchore Enterprise can be configured to depend on other storage for various artifacts. For full details on storage configuration, see Storage Configuration.
Configuration volumes:
this volume is used to provide persistent storage to the container from which it will read its configuration files, and optionally - certificates. Requirement: Less than 1MB.
[Optional] Scratch space:
this temporary storage volume is recommended but not required. During the analysis of images, Anchore Enterprise downloads and extracts all of the layers required for an image. These layers are extracted and analyzed, after which, the layers and extracted data are deleted. If a temporary storage is not configured, then the container’s/worker node’s ephemeral storage will be used to store temporary files. However, performance is likely be improved by using a dedicated volume. Scratch volumes do not need storage redundancy. For further information see Scratch
[Optional] Layer cache:
another temporary storage volume may also be used for image-layer caching to speed up analysis. This caches image layers for re-use by analyzers when generating an SBOM / analyzing an image. For further information see Layer Caching
When configuring scratch and layer cache, the size of these volumes should generally be three times the uncompressed image size to be analyzed.
A temporary volume is required to work around a kernel driver bug for container hosts that use OverlayFS or OverlayFS2 storage, with a kernel older than 4.13.
[Optional] Object Storage and Analysis Archiving:
Anchore Enterprise stores image analysis data and policy documents as JSON objects. By default these are stored in PostgreSQL. For larger deployments, the active data set can be offloaded to Amazon S3 or an S3-compatible provider, and completed analyses can be moved to a separate archive to reduce database load. Requirement: approximately 10MB per image. For further information, see Object Storage Configuration and Analysis Archive Configuration.
The estimated storage requirements for object should be the total number of images x 10MB
Anchore Enterprise UI
The Anchore Enterprise UI module interfaces with Anchore API using the external API endpoint. The UI requires access to the Anchore database where it creates its own namespace for persistent configuration storage. Additionally, a Redis database deployed and managed by Anchore Enterprise through the supported deployment mechanisms is used to store session information.
Network
Ingress
The Anchore Enterprise UI module publishes a web UI service by default on port 3000, however, this port can be remapped.
Egress
The Anchore Enterprise UI module requires access to three network services at the minimum:
External API endpoint (typically port 8228)
Redis Database (typically port 6379)
PostgreSQL Database (typically port 5432)
Redis Service
Version 7.4.6 or higher
Optimize Your Deployment
Optimizing your Anchore Enterprise deployment on Kubernetes, involves various strategies to enhance performance, reliability, and scalability. Here are some key tips:
Ensure that your Analyzer, API, Catalog, and Policy service containers have adequate CPU and memory resources. Each service has reference recommendations which can be found in the Anchore Enterprise chart values.yaml.
Each pod can make between 30 and 100 connections to the database so ensure max_connections is set appropriately (at least 500).
Integrate with monitoring tools like Prometheus and Grafana to monitor key metrics like CPU, memory usage, analysis times, and feed sync status. You can also Set up alerts for critical thresholds. Follow our guide on Prometheus and Grafana setup Monitoring guides
For large deployments, it is good practice to Schedule regular vacuuming, indexing, and performance tuning to keep the database running efficiently.
Layer caching in Docker can significantly speed up the image build process by reusing layers that haven’t changed, reducing build times and improving efficiency. Follow our guide on Layer Caching setup
Keep in mind Anchore Enterprise supports tenancy by means of Accounts. We suggest at a minimum creating an
account besides the admin account to use for normal Anchore Enterprise tasks.
Next Steps
If you feel you have a solid grasp of the requirements for deploying Anchore Enterprise, we recommend following one of our installation guides.
2 - Deploy using Docker Compose
In this topic, you’ll learn how to use Docker Compose to get up and running with a stand-alone Anchore Enterprise deployment.
Deploying in an air-gapped (offline) environment? Start with Deploy Air-Gapped using Docker Compose, which covers preparing and moving the container images before you return to the deployment steps on this page.
Docker Compose is only recommended for testing (e.g. demo or proof-of-concept) (< 1000 SBOMs), production is by support exception from Anchore Customer Success. For all other usage patterns, customers should use either the Anchore Enterprise Cloud Image, or a Helm-based deployment on K8s which enables easier scaling, modular deployment and fine-grained configuration
Before moving further with Anchore Enterprise, it is highly recommended to read the Overview sections to gain a deeper understanding of fundamentals, concepts, and proper usage.
The following instructions assume you are using a system running Docker Engine v20.10 or later, have access to APT resources, and a version of Docker Compose that supports at least v2 of the Compose configuration format.
A stand-alone deployment requires at least 32GB of RAM and enough disk space available to support the largest container images or source repositories that you intend to analyze. It is recommended to consider three times the largest source repository or container image size. We suggest at least 40GB of disk space, the more the better.
To access Anchore Enterprise, you need a valid license.yaml file that has been issued to you by Anchore Customer Success. If you do not have a license yet, visit the Anchore Contact page to request one.
You need root or sudo access to the system where you will be running docker and deploying Anchore Enterprise, all commands in this document are run as root.
External Database Requirements
Anchore Enterprise v6.0 requires PostgreSQL 17 or greater with the pg_cron extension. This Compose deployment does not use a stock PostgreSQL image — the anchore-db service is built from the provided Dockerfile.anchore-db, which produces a PostgreSQL 17 image with pg_cron already installed. If you point Compose at your own external database instead, it must be PostgreSQL 17+ with pg_cron available.
Get Started
Follow the steps below to get up and running!
Step 1: Authenticate with the Official Anchore Registry
You’ll need authenticated access to the anchore/enterprise and anchore/enterprise-ui repositories on Docker Hub to pull the images. The Anchore Account or Customer Success team will provide a Docker Hub PAT (Personal Access Token) for access to images. Log in with your Docker PAT to push and pull images from Docker Hub:
Create a dedicated project directory to store your configuration files, system license, and database variables. Subsequent steps assume you are working from this directory.
mkdir anchore-enterprise && cd anchore-enterprise
Step 3: Download the Deployment Files
Download the Docker Compose file and the Dockerfile database into your working directory, alongside the license file you received from Anchore. You may need to rename that file to license.yaml.
Place your license.yaml file in the working directory:
cp /path/to/your/license.yaml ./license.yaml
Download the official Anchore Enterprise v6.0 Docker Compose configuration file:
Edit docker-compose.yaml to set the deployment secrets. Several of the variables ship commented out and must be uncommented and given a value, while others ship with a default. The secrets fall into two groups, configured in different services.
We strongly recommend changing any default secret values you find before starting the stack.
Database password — set this on the anchore-db service only:
Variable
Description
POSTGRES_PASSWORD
The password PostgreSQL initializes with. Set on the anchore-db service only. ANCHORE_DB_PASSWORD (below) must be set to this same value.
For example, the environment block of the anchore-db service looks like this:
The ui service connects to the database through its ANCHORE_APPDB_URI variable, which embeds the default database password (postgres://postgres:mysecretpassword@anchore-db:5432/postgres). If you change POSTGRES_PASSWORD from the default, update the password in ANCHORE_APPDB_URI on the ui service to match, or the GUI will fail to connect to the database.
Anchore Enterprise service secrets — set these on every Anchore Enterprise service, but not on the anchore-db service. Each value must be identical across all of those services:
Variable
Description
ANCHORE_ADMIN_PASSWORD
Strong password for the Anchore Enterprise admin account.
ANCHORE_AUTH_SECRET
Shared authentication secret used for internal service communication.
ANCHORE_DB_PASSWORD
Database password the Anchore Enterprise services use to connect to PostgreSQL. Must match POSTGRES_PASSWORD above.
For example, the environment block of each Anchore Enterprise service should look like this:
The Anchore Enterprise service secrets must be identical across every Anchore Enterprise service, and ANCHORE_DB_PASSWORD must match POSTGRES_PASSWORD on the anchore-db service. Mismatched secrets prevent services from starting or authenticating.
Step 5: Start the Deployment
Start your environment from the working directory. This builds the database image and starts Anchore Enterprise:
docker compose up -d
[+] up 14/14
✔ Network anchore-6000_default Created 0.4s
✔ Container anchore-6000-anchore-db-1 Healthy 43.5s
✔ Container anchore-6000-ui-redis-1 Healthy 43.6s
✔ Container anchore-6000-queue-1 Healthy 37.3s
✔ Container anchore-6000-catalog-1 Healthy 43.4s
✔ Container anchore-6000-reports_worker-1 Started 43.3s
✔ Container anchore-6000-analyzer-1 Started 42.8s
✔ Container anchore-6000-notifications-1 Started 43.3s
✔ Container anchore-6000-component-catalog-1 Started 43.3s
✔ Container anchore-6000-reports-1 Started 42.8s
✔ Container anchore-6000-api-1 Healthy 53.6s
✔ Container anchore-6000-data-syncer-1 Healthy 48.4s
✔ Container anchore-6000-policy-engine-1 Started 48.7s
✔ Container anchore-6000-ui-1 Started 54.0s
Step 6: Install AnchoreCTL
anchorectl is the native CLI utility used to manage and orchestrate Anchore Enterprise.
In this step, we’ll install the lightweight Anchore Enterprise client tool, quickly test it using the version operation, and set up a few environment variables to allow it to interact with your deployment using the admin password you set during configuration.
In this guide, AnchoreCTL is installed to /usr/local/bin/ and uses environment variables throughout. For more details on using and configuring AnchoreCTL, see Using AnchoreCTL.
Download and Install the Binary
Run the curl command below to download anchorectl and install it into your /usr/local/bin directory, which should be in your $PATH:
To persist these settings for future terminal sessions, append these lines to your shell profile (~/.bashrc or ~/.zshrc).
Step 7: Verify Service Availability
After a few minutes (depending on system speed) Anchore Enterprise and Anchore UI services should be up and running, ready to use. You can verify the containers are running with docker compose, as shown in the following example.
docker compose ps
NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
anchore-6000-analyzer-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" analyzer 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-anchore-db-1 anchore-6000-anchore-db "docker-entrypoint.s…" anchore-db 2 minutes ago Up 2 minutes (healthy) 5432/tcp
anchore-6000-api-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" api 2 minutes ago Up 2 minutes (healthy) 0.0.0.0:8228->8228/tcp, [::]:8228->8228/tcp
anchore-6000-catalog-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" catalog 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-component-catalog-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" component-catalog 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-data-syncer-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" data-syncer 2 minutes ago Up 2 minutes (healthy) 0.0.0.0:8778->8228/tcp, [::]:8778->8228/tcp
anchore-6000-notifications-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" notifications 2 minutes ago Up 2 minutes (healthy) 0.0.0.0:8668->8228/tcp, [::]:8668->8228/tcp
anchore-6000-policy-engine-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" policy-engine 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-queue-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" queue 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-reports-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" reports 2 minutes ago Up 2 minutes (healthy) 0.0.0.0:8558->8228/tcp, [::]:8558->8228/tcp
anchore-6000-reports_worker-1 docker.io/anchore/enterprise-dev:v6.0.0-rc16 "/docker-entrypoint.…" reports_worker 2 minutes ago Up 2 minutes (healthy) 8228/tcp
anchore-6000-ui-1 docker.io/anchore/anchore-on-prem-ui-dev:v6.0.0-rc4 "/docker-entrypoint.…" ui 2 minutes ago Up 2 minutes (healthy) 0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp
anchore-6000-ui-redis-1 docker.io/library/redis:7.4.6 "docker-entrypoint.s…" ui-redis 2 minutes ago Up 2 minutes (healthy) 6379/tcp
You can then run a command to get the status of the Anchore Enterprise services:
anchorectl system status
✔ Status system
┌───────────────────┬────────────────────┬───────────────────────────────┬──────┬────────────────┬────────────┬──────────────┐
│ SERVICE │ HOST ID │ URL │ UP │ STATUS MESSAGE │ DB VERSION │ CODE VERSION │
├───────────────────┼────────────────────┼───────────────────────────────┼──────┼────────────────┼────────────┼──────────────┤
│ simplequeue │ anchore-quickstart │ http://queue:8228 │ true │ available │ 6000 │ 6.0.0 │
│ data_syncer │ anchore-quickstart │ http://data-syncer:8228 │ true │ available │ 6000 │ 6.0.0 │
│ reports_worker │ anchore-quickstart │ http://reports_worker:8228 │ true │ available │ 6000 │ 6.0.0 │
│ notifications │ anchore-quickstart │ http://notifications:8228 │ true │ available │ 6000 │ 6.0.0 │
│ reports │ anchore-quickstart │ http://reports:8228 │ true │ available │ 6000 │ 6.0.0 │
│ analyzer │ anchore-quickstart │ http://analyzer:8228 │ true │ available │ 6000 │ 6.0.0 │
│ component_catalog │ anchore-quickstart │ http://component-catalog:8228 │ true │ available │ 6000 │ 6.0.0 │
│ catalog │ anchore-quickstart │ http://catalog:8228 │ true │ available │ 6000 │ 6.0.0 │
│ apiext │ anchore-quickstart │ http://api:8228 │ true │ available │ 6000 │ 6.0.0 │
│ policy_engine │ anchore-quickstart │ http://policy-engine:8228 │ true │ available │ 6000 │ 6.0.0 │
└───────────────────┴────────────────────┴───────────────────────────────┴──────┴────────────────┴────────────┴──────────────┘
The first time you run Anchore Enterprise, vulnerability data will sync to the system in a few minutes. For the best experience, wait until the core vulnerability data feeds have completed before proceeding.
You can check the status of your feed sync using AnchoreCTL:
As soon as you see RecordCount values set for all vulnerability groups, the system is fully populated and ready to present vulnerability results. Note that data syncs are incremental, so the next time you start up Anchore Enterprise it will be ready immediately. The AnchoreCTL includes a useful utility that will block until the feeds have completed a successful sync:
anchorectl system wait
✔ API available system
✔ Services available [10 up] system
✔ Vulnerabilities feed ready system
Step 8: Verify Functionality and Start Using Anchore Enterprise
Add an image to confirm that analysis works end to end. The --wait flag blocks until analysis completes:
If the command prints the success message, point your browser at the Anchore Enterprise GUI at http://localhost:3000/ and log in with the username admin and the ANCHORE_ADMIN_PASSWORD you set in Step 4. If it instead reports a connection error, wait a few moments for the ui service to finish starting and try again.
To put your deployment to work, follow the end-to-end workflows in the documentation:
Uncomment the following section at the bottom of the docker-compose.yaml file:
# # Uncomment this section to add a prometheus instance to gather metrics. This is mostly for quickstart to demonstrate prometheus metrics exported# prometheus:# image: docker.io/prom/prometheus:latest# depends_on:# - api# volumes:# - ./anchore-prometheus.yml:/etc/prometheus/prometheus.yml:z# logging:# driver: "json-file"# options:# max-size: 100m# ports:# - "9090:9090"#
For each service entry in the docker-compose.yaml file, enable metrics in the API by changing:
ANCHORE_ENABLE_METRICS=false
to
ANCHORE_ENABLE_METRICS=true
Download the example Prometheus configuration into the same directory as the docker-compose.yaml file, with the name anchore-prometheus.yml:
curl https://docs.anchore.com/current/docs/deployment/anchore-prometheus.yml > anchore-prometheus.yml
docker compose up -d
Result: You should see a new container started, and can access Prometheus via your browser at http://localhost:9090.
Enable Swagger UI
Uncomment the swagger-ui-nginx and swagger-ui services at the bottom of the docker-compose.yaml file (the section is labelled with a “Uncomment this section to run a swagger UI service” comment).
Download the nginx configuration into the same directory as the docker-compose.yaml file, with the name anchore-swaggerui-nginx.conf:
curl https://docs.anchore.com/current/docs/deployment/anchore-swaggerui-nginx.conf > anchore-swaggerui-nginx.conf
docker compose up -d
Result: You should see a new container started, and can access Swagger UI via your browser at http://localhost:8080.
2.1 - Deploy Air-Gapped using Docker Compose
Anchore Enterprise can run in an air-gapped environment with no outbound internet access. The only air-gapped-specific work is getting the container images onto the air-gapped network: you pull and build them on an internet-connected system, then move them across. Once the images are in place, deployment follows the standard Docker Compose procedure.
Throughout this guide, the low side is the internet-facing system and the high side is the air-gapped system.
Prerequisites
Low side (internet-facing) — the Docker static binary, used only to pull, build, and save images.
High side (air-gapped) — Docker Engine/CE and a Docker Compose that supports at least v2 of the Compose configuration format, used to run Anchore Enterprise.
Detailed sizing and other requirements are in Requirements.
Building the anchore-db image installs pg_cron, which requires APT access. If APT resources are not reachable on your network, work with Anchore Customer Success for alternatives.
Prepare the Images (low side)
Run these commands on the low side. You will need the Anchore-provided Docker Hub credentials and PAT (Personal Access Token), and roughly 2–4 GB of free disk space for the pulled images.
Download the current Docker Compose file and the database Dockerfile:
Build the database image from Dockerfile.anchore-db. This Dockerfile produces the PostgreSQL 17 image with pg_cron that Anchore Enterprise requires; see External Database Requirements for details.
Choose one of the following. A private container registry is the recommended path; use a local image tarball only if no registry is available on the air-gapped network.
Re-tag the images for your private registry, replacing <registry> with your registry domain (for example, core.harbor.domain):
docker tag docker.io/anchore/enterprise:v6.0.0 \
<registry>/anchore/enterprise:v6.0.0
docker tag docker.io/anchore/enterprise-ui:v6.0.0 \
<registry>/anchore/enterprise-ui:v6.0.0
docker tag docker.io/redis:7.4.6 <registry>/redis:7.4.6
docker tag anchore:db <registry>/anchore:db
If the registry is only reachable from the high side, save the tagged images and transfer them across (along with docker-compose.yaml, Dockerfile.anchore-db, and your license.yaml), then load them on the high side:
# Low sidedocker save -o anchore-airgap-images.tar \
<registry>/anchore/enterprise:v6.0.0 \
<registry>/anchore/enterprise-ui:v6.0.0 \
<registry>/redis:7.4.6 \
<registry>/anchore:db
# High sidedocker load -i anchore-airgap-images.tar
Push the images to your private registry from a system that can reach it:
Besides the images, the air-gapped host needs your docker-compose.yaml and license.yaml in the working directory. You downloaded the Compose file on the low side in Prepare the Images; if you have not already copied it and the license across with the images, do so now. The database is deployed from the pre-built anchore:db image you moved, so there is nothing to build here. Configure the deployment as described in Step 4: Configure Secrets, with two additional air-gapped-specific changes:
Point every image: line at your air-gapped images instead of Docker Hub. Use your private-registry tags for Option 1, or the local names you loaded for Option 2. The enterprise image is referenced by many services (api, catalog, analyzer, policy-engine, and others), so update every instance. The anchore-db service builds its image from the Dockerfile by default, so replace its build: section with a reference to the anchore:db image you built and moved earlier.
For example, the api service ships referencing Docker Hub, and anchore-db builds its image locally:
Remove the build: section (the context and dockerfile lines) from the anchore-db service when you add its image: line. The database image was already built and moved, so there is no need to build it again on the air-gapped host.
Configure the deployment for air-gapped feed handling. Because the deployment cannot reach the Anchore Data Service, you must disable the Data Syncer’s automatic feed sync and then download and import feed bundles manually with AnchoreCTL. Both steps are described in Air-Gapped Feed Configuration.
Until you complete the air-gapped feed configuration, you will not be able to upload feed bundles into the system, and the deployment will have no vulnerability data.
The supported method for deploying Anchore Enterprise on Kubernetes is with Helm. The Anchore Enterprise Helm Chart includes configuration options for a full Enterprise deployment.
Anchore Enterprise 6.0 does not support a helm deployment, this will be released with 6.1. This page and subsequent pages will be updated with the 6.1 release.
3.1 - Deploying Anchore Enterprise on Azure Kubernetes Service (AKS)
Instructions for deploying Anchore Enterprise on Azure Kubernetes Service (AKS) with Helm are coming in Anchore Enterprise 6.1.
3.2 - Deploying Anchore Enterprise on Amazon EKS
Instructions for deploying Anchore Enterprise on Amazon Elastic Kubernetes Service (EKS) with Helm are coming in Anchore Enterprise 6.1.
3.3 - Deploying Anchore Enterprise on Google Kubernetes Engine (GKE)
Instructions for deploying Anchore Enterprise on Google Kubernetes Engine (GKE) with Helm are coming in Anchore Enterprise 6.1.
3.4 - Deploying Anchore Enterprise on OpenShift
Instructions for deploying Anchore Enterprise on OpenShift with Helm are coming in Anchore Enterprise 6.1.
4 - Anchore Enterprise Cloud Image
Overview
The Anchore Enterprise Cloud Image (AECI) is a fully functional machine image with an Anchore Enterprise deployment that
is pre-configured with the goal of simplifying deployment complexity for our end users.
Anchore Enterprise Cloud Image is currently available for users of Amazon Web Services only. AECI 6.x is expected to be released in the coming weeks
All /v2 API endpoints referenced throughout our documentation are accessed via /api/v2 when using AECI.
AECI contains a proprietary tool known as Cloud Image Manager. It allows users to manage their deployment by providing an easy way to install, configure and upgrade. For more information about the Cloud Image
Manager, see the Cloud Image Manager.
To get started with deploying Anchore Enterprise Cloud Image, please see AECI - AWS.
Supported Limits
The Cloud Image has the following limits, independent of instance type:
10,000 Image SBOMs
Max Image Size is 10 GB
300 Report Executions
100 System Users
Non-supported Features
The Cloud Image does not currently support the following Anchore Enterprise features:
Air-gapped Deployment
Runtime Inventory
Application Groups and Source Code Analysis
Windows Image Analysis
Legacy Image Archive
To discuss further, contact Anchore Customer Success.
The baseline supported instance type on Amazon Web Services is the r7a.xlarge. This gives the best mix of
performance to cost for running Anchore Enterprise in alignment with the supported system limits.
Cloud Image Manager will not enforce the use of this instance type but will check for the minimum resources needed to run the software. If you would like to use a different instance type, please contact Anchore Customer Success for further guidance.
For more information on Amazon EC2 Instance types Please review the following links
Memory Requirement - Anchore Enterprise Cloud Image (AECI) requires a minimum of 32 GB of memory to operate.
Disk Requirement - AECI requires a minimum of 128 GB of disk space for root volume and 1 TB for data volume to operate.
Note: The data volume by default will not delete on termination of your AMI.
CPU Requirement - AECI requires a minimum of 4 vCPU to operate.
License
The Anchore Enterprise Cloud Image requires a valid license entitlement to operate. The license is provided by Anchore during the purchase process. The license file is required to be uploaded via the Cloud Image Manager during the initial setup. Please have it available before starting the installation process.
EC2 Key Pair Type
Anchore Enterprise Cloud Image is running with FIPS enabled. When creating your Key Pair, you must use an RSA key. The ED25519 key will be rejected as a non-FIPS-compliant algorithm.
A quick Demo on getting started with Anchore Enterprise Cloud Image
Once the instance is launched, please review the Cloud Image Manager documentation for the next steps on
Accessing the Cloud Image Manager. The Cloud Image Manager will walk you through the preflight checks, configuration,
and management of your Anchore Enterprise Cloud Image deployment.
Operations
With AECI up and running, there is some limited feeding and watering required. You’ll want to consider the following activities:
Backups
It is important that you have a backup and restore strategy in place to protect your data. Cloud Image Manager will prompt you to create a snapshot prior to upgrading your Anchore Enterprise Cloud Image or
expanding your disks. It is also reasonable for you to consider using AWS Backup and/or creating snapshots of your EBS volume on a regular basis:
During the course of using the product, you may wish to expand the size of your disks. It is strongly recommended
that you create a snapshot of your EBS volume prior to expanding your disks.
Once you have expanded your disk, you will need to resize the filesystem to take advantage of the additional space.
Cloud Image Manager provides a utility to resize the filesystem. Please refer to the Cloud Image Manager
Configuration Disk Expansion for more information.
Upgrade
Occasionally, Anchore will release updates to the Anchore Enterprise Cloud Image and the subsequent version of Anchore Enterprise shipped with it. The Cloud Image Manager will provide
you with upgrades that are available and allow you to determine when you want to upgrade. It is strongly
recommended that you create a snapshot of your EBS volume prior to upgrading your Anchore Enterprise Cloud Image.
During operation of Anchore Enterprise Cloud Image, you may require support from Anchore Customer Success. The
Cloud Image Manager provides you with a seamless way to generate a support bundle and upload it to Anchore.
The Cloud Image Manager is a proprietary tool that allows users to seamlessly manage their Anchore Enterprise
Cloud Image deployments. It walks users through the process of installing, configuring, and upgrading their
Anchore Enterprise Cloud Image deployment.
Best Practices
The Cloud Image Manager uses Textual (a TUI framework for Python) to provide
a terminal-based interface. For your best user experience, please use the following terminal emulators
when connecting to the Cloud Image Manager.
Note: We recommend against using the default macOS Terminal application as it may not render the TUI correctly. For more
information on why, please see Textual FAQ.
Access the Cloud Image Manager
After your instance is launched, you can access the Cloud Image Manager by connecting to the instance via SSH.
Using your private key file used for authentication (likely generated when setting up the instance) and the
public IP address of the instance, connect using the following example command:
Permissions on key file - If you get a WARNING: UNPROTECTED PRIVATE KEY FILE error, fix it by setting the
correct permissions on your key file. Run the following command to set the correct permissions:
chmod 400 ~/my-keypair.pem
Connection Issues - If you experience a Connection Timeout or Host Unreachable error, verify that the instance
is running and that the security group allows SSH traffic on port 22.
You should now be connected to the Cloud Image Manager.
Preflight Checks
The Cloud Image Manager will perform a series of preflight checks to ensure that the system is ready for installation.
These checks include ensuring that the machine image has met memory, disk space, and CPU requirements. If the system
does not meet the requirements, the preflight checks will fail and the installation will not proceed.
Initial Install
The Cloud Image Manager will walk you through the initial installation process. At the end of this process, the
Cloud Image Manager will provide you with the URL to access the Anchore Enterprise UI as well as your administrator
credentials.
Upgrade
The Cloud Image Manager will determine if there are any upgrades available for your Anchore Enterprise Cloud Image
deployment. If an upgrade is available, the Cloud Image Manager will walk you through the upgrade process. If
downtime is required, the Cloud Image Manager will notify you prior to proceeding. This will allow you to plan
for the upgrade when it is convenient for you. It is highly recommended that you take a snapshot of your EBS
volume prior to upgrade.
Configuration
The Cloud Image Manager configuration screen allows the following options:
Adding and updating the Anchore Enterprise License.
Providing any Server Certificates required for TLS access to Anchore Enterprise services.
Providing a custom Root Certificate if one is required for your environment.
Configuring any optional proxy settings required for your environment.
Disk Expansion
Reconfigure Proxy Settings
Changing Proxy settings after completing the installation process currently requires manual intervention for the settings to be fully applied.
If you must change the Proxy settings, please contact customer support for assistance.
Expand Disks
The Cloud Image Manager provides a utility to expand the root and data volumes once your virtual hard disk has been
increased in size. This step is necessary to take advantage of the additional space. The Cloud Image Manager will
shut down Anchore Enterprise during this operation. It is highly recommended that you take a snapshot of your EBS
volume prior to any operation that may modify your disk volumes.
System Status
The Cloud Image Manager provides a system status screen that shows the current service and container status
of the Anchore Enterprise services.
It also provides the list of currently deployed versions of Anchore Enterprise, Anchore Enterprise UI as well as
the other infrastructure components that are automatically deployed within the Anchore Enterprise Cloud Image.
Support
The Cloud Image Manager provides a support screen that allows you to:
Generate a support bundle. This will result with the location of the support bundle.
Upload a generated support bundle. This will be automatically uploaded to Anchore. You must create a support
ticket and provide the Support Bundle ID and Filename to the support team.
As part of the Cloud Image deployment, you have access to Grafana data that is collected for your deployment.
This data can be used to monitor the health of your deployment. The Cloud Image Manager provides a link and
credentials to access the Grafana dashboard.
5 - Deploying AnchoreCTL
In this section you will learn how to deploy and configure AnchoreCTL, the Anchore Enterprise Command Line Interface.
AnchoreCTL is published as a simple binary available for download either from your Anchore Enterprise deployment or Anchore’s release site.
Using AnchoreCTL, you can manage and inspect all aspects of your Anchore Enterprise deployments, either as a manual
human-readable configuration/instrumentation/control tool or as a CLI that is designed to be used in scripted environments
such as CI/CD and other automation environments.
Installation
AnchoreCTL’s major and minor release version coincides with the release version of Anchore Enterprise, however patch versions may differ. For example,
Enterprise v6.0.0
AnchoreCTL v6.0.0
AnchoreCTL should be version-aligned with Anchore Enterprise for major/minor releases. Please refer to the Enterprise Release Notes for the supported version of AnchoreCTL.
MacOS / Linux
Download a local (from your Anchore Enterprise deployment) or remote (from Anchore servers) version without installation:
Linux Intel/AMD64
[Local]
curl -X GET "https://my-anchore.example.com/v2/system/anchorectl?operating_system=linux&architecture=amd64"\
-H "accept: */*" | tar -zx anchorectl
