Requirements

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 6.0+ will require the pg_cron extension in addition to PostgreSQL 17. Planning for this now avoids additional migration steps later.

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.

Reduce Total Cost of Ownership with an 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.

PostgreSQL in Anchore Enterprise Deployments

A PostgreSQL database ships with the default deployment mechanisms for Anchore Enterprise. This is often referred to as the Anchore-managed database. This can be run in a container, as configured in the example Docker Compose file and default Helm values file.

The PostgreSQL database requirement can also be provided as an external service to Anchore Enterprise. PostgreSQL databases, such as Amazon RDS for PostgreSQL, can be used for highly-scalable cloud deployments.

An external PostgreSQL database is recommended for any production Helm deployment.

PostgreSQL Requirements for Anchore Enterprise 6.0

As of Anchore Enterprise 6.0, PostgreSQL 17 or higher with the pg_cron extension is required. Be aware of the following changes by deployment type:

Helm: The Anchore Enterprise 6.0 Helm chart will not include a bundled PostgreSQL chart. The pg_cron extension must be available in your PostgreSQL instance before beginning the Anchore Enterprise 6.x migration. Helm deployments may need to build a custom PostgreSQL 17 image with the pg_cron extension and push it to a container registry accessible by the Kubernetes cluster.
Docker Compose: Docker Compose deployments will continue to include PostgreSQL. The provided docker-compose YAML file references a Dockerfile that adds the pg_cron extension automatically.
AECI: AECI deployments will continue to include PostgreSQL.

The pg_cron extension can be added to an existing PostgreSQL instance at any time. However, this may require replacing the PostgreSQL container image with one that includes the extension, and running SQL statements directly against the database as the postgres superuser to create and configure the extension.

For both Helm and Docker Compose deployments, we suggest using a managed database such as Amazon RDS whenever possible. If a managed database is not available, we suggest using CloudNativePG (CNPG).

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.

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
Ensure you enable reporting data egress.
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.

Last modified May 6, 2026