Storage Configuration

Anchore Enterprise uses three categories of storage, each serving a distinct purpose. This page describes each type and provides configuration guidance.

Configure Scratch Space

During image analysis, Anchore Enterprise downloads and extracts image layers to a local directory on each analyzer worker. This scratch space is ephemeral and must not be shared between services.

Sizing guidance: Without layer caching, size the scratch volume to at least three times the uncompressed size of the largest image you expect to analyze.

By default, Anchore Enterprise uses /tmp inside the container. To use a dedicated volume, mount it and set tmp_dir in your config.yaml:

tmp_dir: '/scratch'

For full details, see Scratch Configuration.

Configure Layer Caching

Layer caching reduces analysis time and network usage by storing previously downloaded image layers so they can be reused across analyses.

Sizing guidance: Size the layer cache to at least three times the uncompressed image size plus 4GB. The minimum supported size is 1GB. The cache uses a least recently used (LRU) eviction policy and stores files in the anchore_layercache directory under your configured tmp_dir.

Helm

In your values.yaml:

anchoreConfig:
  analyzer:
    layer_cache_max_gigabytes: 4

Docker Compose

In your config.yaml under the analyzer service:

services:
  analyzer:
    layer_cache_max_gigabytes: 4

For full details, see Layer Caching Configuration.

Configure Object Storage and Analysis Archiving

Anchore Enterprise stores less-structured data — image manifests, analysis reports, and policy evaluations — in an internal object store. By default this uses PostgreSQL, but it can be offloaded to Amazon S3 or an S3-compatible provider for improved scalability and cost management.

Anchore Enterprise separates storage into two logical data sets:

• Active Data Set: The working set of current image analyses, queried frequently by the policy engine and API. Configured via the catalog’s object_store key.
• Archive Data Set: Completed analyses moved out of active storage to reduce database size. Can be restored on demand. Configured via the catalog’s analysis_archive key.

Sizing guidance: Estimate approximately 10MB per image across both data sets.

Active Data Set

PostgreSQL is the default and requires no additional configuration. To offload to Amazon S3, update the catalog’s object_store in your config.yaml:

services:
  catalog:
    object_store:
      compression:
        enabled: false
        min_size_kbytes: 100
      storage_driver:
        name: 's3'
        config:
          iamauto: true
          region: <AWS_REGION>
          bucket: 'anchore-object-store'
          create_bucket: true

For the full list of driver options (PostgreSQL, Amazon S3, S3-compatible), see Object Storage Configuration.

Archive Data Set

The analysis archive uses the same storage drivers as the active data set but is configured separately. This lets you direct archived data to lower-cost storage independently of your working set.

Example — keep the active data set in PostgreSQL while archiving to Amazon S3:

services:
  catalog:
    object_store:
      compression:
        enabled: false
        min_size_kbytes: 100
      storage_driver:
        name: db
        config: {}
    analysis_archive:
      compression:
        enabled: false
        min_size_kbytes: 100
      storage_driver:
        name: 's3'
        config:
          iamauto: true
          region: <AWS_REGION>
          bucket: 'anchore-archive'
          create_bucket: true

For full details and instructions on migrating between backends, see Analysis Archive Configuration.