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 linux/amd64 (AMD or Intel-based) or linux/arm64 hosts.

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.

Architectures

Anchore Enterprise v6.1.0 and later publish multi-architecture images, so the same image tag resolves to the right platform on both linux/amd64 and linux/arm64 hosts. A deployment must not mix architectures within a single cluster node pool unless your scheduler places pods by platform.

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, component-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.

• Give the component-catalog service the same CPU and memory as catalog.

• Set an ephemeral-storage request on every service. See Ephemeral Storage below.

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.

Ephemeral Storage

Several Anchore Enterprise services write large temporary files to local disk, under the directory set by tmp_dir (/analysis_scratch in the Helm chart and the Docker Compose file):

New vulnerability data is published several times a day, so keep the component catalog’s update space free at all times rather than treating it as an occasional spike. The update’s temporary file is also hard to see. The component catalog removes the file’s name from the directory as soon as it opens it, then keeps writing to it until the update finishes, at which point the space is released. While the update runs, df counts that space, but du, ls, and docker system df do not show the file.

On Kubernetes, the chart gives each pod an emptyDir volume for this directory by default, so everything written there counts toward the pod’s ephemeral storage (as do the pod’s logs). When a node runs short of disk, the kubelet evicts pods, starting with the ones using more ephemeral storage than they requested. A pod with no ephemeral-storage request counts all of its usage as excess, so it is among the first evicted. Set an ephemeral-storage request on every Anchore Enterprise pod. The scheduler also uses these requests to avoid placing more pods on a node than its disk can hold.

Starting points for the Helm chart, set under each component’s resources.requests:

componentCatalog:
  resources:
    requests:
      ephemeral-storage: 40Gi
policyEngine:
  resources:
    requests:
      ephemeral-storage: 8Gi

Avoid setting an ephemeral-storage limit unless you need one. A pod that exceeds its limit is evicted, even when the node has disk to spare.

Size the Component Catalog’s Scratch Space

Allocate at least 40 GB of scratch space for the component catalog. Vulnerability data updates consume ~35 GB while running (see Ephemeral Storage), and the remainder accommodates database growth. If space runs out, the update fails and the component catalog keeps using the previous vulnerability data until a later update succeeds. On Docker Compose, or on Kubernetes with the default emptyDir, this directory shares disk space with other services, so they all run out at the same time.

SBOM imports need additional space, because they can run at the same time as an update. Each SBOM stays on disk until its import finishes, so usage scales with the total size of the SBOMs being imported at once (for example, four 158 MB SBOMs use ~635 MB). For high-volume or large-SBOM environments, plan for an extra 50 GB to 200 GB for SBOM imports on top of the 40 GB update baseline.

How you provide it depends on where you run:

• Amazon EKS: give the component catalog a dedicated EBS-backed scratch volume through componentCatalog.scratchVolume.details, as shown in PVCs in the EKS guide. The volume does not count toward ephemeral storage, so the ephemeral-storage request no longer has to include the scratch space.
• On-premises Kubernetes: if your default storage class replicates volumes across nodes, a PVC copies every scratch write to other nodes, which is wasted work for data that is thrown away. Keep the default emptyDir, which uses the node’s local disk, and raise the ephemeral-storage request to the scratch size you need.
• Docker Compose: with the provided Docker Compose file, the component catalog writes this directory inside its container, which Docker keeps under its data root, usually on the host’s root disk. Either size the host’s disk as described in System Requirements, or bind-mount a directory from a separate disk that has at least 40 GB free to /analysis_scratch in the component-catalog service.

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.

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.

Database Sizing and Scaling

The database’s storage, CPU, and memory should scale together as the deployment grows. Use the values below as starting points and adjust based on continuous monitoring rather than provisioning for a fixed target once.

Database Tuning

Beyond sizing, several PostgreSQL parameters can improve performance for the Anchore Enterprise workload. These are optional and depend on your storage backend, workload size, and instance resources, so treat them as knobs to turn while monitoring — not one-size-fits-all defaults. Check an instance’s current value with SHOW <parameter>; before changing it, and change one category at a time so you can attribute any effect.

For self-managed deployments (for example CloudNativePG), the following are reasonable starting points for a moderately sized, write-active deployment. Scale them with instance memory and write volume:

min_wal_size: "2GB"
max_wal_size: "8GB"
shared_buffers: "5GB"

• shared_buffers — PostgreSQL’s dedicated cache. Roughly 25% of instance RAM is a common target (the 5GB example suits an instance with around 20GB of RAM); avoid exceeding ~40%. Requires a database restart.
• min_wal_size / max_wal_size — Larger WAL limits reduce checkpoint frequency under heavy write load, such as high analysis throughput, which smooths I/O spikes. Increase for write-heavy deployments and ensure the data volume has room for the larger WAL.

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.

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

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.

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 temporary storage is not configured, files default to the container or worker node’s ephemeral storage. However, using a dedicated volume usually improves performance. Scratch volumes do not need storage redundancy. For further information see Scratch. The component catalog and policy engine use the same directory for their copies of the vulnerability database and for SBOMs being imported or scanned; see Ephemeral Storage for sizing each service.
• [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

• [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.

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. See Database Tuning for the specific PostgreSQL parameters we recommend adjusting.
• 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.