Skip to main content
Artifact Store provides container registry functionality compatible with the Docker Registry API v2. Push and pull container images, Helm charts, and other OCI artifacts using standard tooling. All artifact data persists through DFS with built-in deduplication.

​
System components

Registry server

Implements Docker Registry API v2 for push, pull, and manifest operations. Handles blob uploads, content addressing, and tag management.

Scan worker

Background service that analyzes pushed images for vulnerabilities using Trivy. Stores results alongside artifact metadata.

GC worker

Reclaims storage from deleted repositories, unreferenced blobs, and abandoned uploads through mark-and-sweep garbage collection.

IAM integration

Repository-level access control through Platform’s authorization system. Supports viewer, editor, and owner roles.

​
Storage architecture

Artifact Store uses a content-addressable storage model. Blobs (image layers, configs) are stored by their SHA256 digest, enabling automatic deduplication across repositories.

​
Blob storage

All blobs persist to DFS under a canonical path structure: 
/registry/blobs/<algorithm>/<digest>
When multiple repositories reference the same layer, they share the underlying blob. This significantly reduces storage for common base images.

​
Repository metadata

Each repository maintains metadata in FoundationDB:
  • Manifests: OCI image manifests indexed by digest and tag
  • Blob references: Links between repository and shared blobs
  • Tags: Named references to manifest digests
Repositories are scoped to projects. The full path follows the pattern: 
projects/<project_id>/repositories/<repository_name>

​
Vulnerability scanning

Artifact Store integrates with Trivy for container image vulnerability scanning. When enabled, images are analyzed automatically after push.

​
Scan-on-push

The registry server enqueues a scan task whenever a manifest is pushed. The scan worker picks up tasks from a distributed queue and processes them in order.

​
Scan process

  1. Scan worker pulls the image from the registry using service account credentials
  2. Trivy analyzes layers and reports vulnerabilities
  3. Results are converted to Parquet format and stored in DFS
  4. Vulnerability statistics update on the manifest metadata

​
Vulnerability statistics

Each scanned image includes aggregated counts:
SeverityDescription
CriticalVulnerabilities requiring immediate attention
Medium/HighSignificant vulnerabilities
Low/UnknownMinor or unclassified vulnerabilities
These statistics are queryable through the API and displayed in the management UI.

​
Garbage collection

Artifact Store runs continuous garbage collection to reclaim storage from deleted content.

​
What gets collected

Content typeTriggerGrace period
Orphaned blobsNo manifest references24 hours
Deleted repositoriesRepository deletionImmediate
Abandoned uploadsNo activity1 hour
Expired uploadsUpload timeoutConfigurable

​
Mark-and-sweep process

The GC worker operates in two phases: Mark phase scans repository blob references and identifies digests with zero live references. These are marked as pending deletion with a timestamp. Sweep phase processes pending deletions that have exceeded the grace period. It removes repository-scoped links first, then deletes the canonical blob only when no repository references remain. This two-phase approach prevents accidental deletion of blobs during concurrent uploads.

​
Access control

Artifact Store inherits permissions from Platform’s IAM system. Roles can be assigned at organization, project, or repository level.

​
Repository roles

RolePullPushDeleteManage
viewer✓
editor✓✓
owner✓✓✓✓
Roles inherit through the resource hierarchy. A user with artifact_store_editor on a project has editor access to all repositories in that project.

​
Authentication

The registry accepts Docker credentials in two forms:
  • User credentials: Username and password authenticated against Platform
  • Service account keys: JSON key files for CI/CD automation
For Docker CLI authentication: 
docker login <registry-host> -u <username> -p <password>
For service accounts, use base64-encoded JSON credentials: 
docker login <registry-host> -u _json_b64 -p <base64-credentials>

​
Configuration

​
Registry server

VariableDescriptionRequired
ARTIFACT_STORE_ADDRESSBind address for the serverNo (default: 0.0.0.0:7111)
ARTIFACT_STORE_DIRECTORYFoundationDB directory for registry metadataNo (default: registry)
ARES_CLIENT_ADDRESSAddress of the DFS metadata serviceNo (default: http://localhost:9182)
ARTS_SCAN_ON_PUSHEnable vulnerability scanning on pushNo (default: true)
ARTS_SCAN_QUEUEQueue name for scan tasksNo (default: arts-scan)
DEBUGEnable debug loggingNo (default: false)

​
Scan worker

VariableDescriptionRequired
FDB_DIRECTORYFoundationDB directory for registry metadataNo (default: registry)
ARTS_METADATA_DIRECTORYFoundationDB directory for Platform metadataNo (default: topaz)
ARES_CLIENT_ADDRESSAddress of the DFS metadata serviceNo (default: http://localhost:9182)
ARTS_SCAN_QUEUEQueue name to consume scan tasks fromNo (default: arts-scan)
ARTS_TRIVY_PATHPath to Trivy binaryNo (default: trivy)
ARTS_REGISTRY_HOSTRegistry hostname for Trivy to pull fromNo (default: localhost:7111)
ARTS_SCAN_BATCH_SIZEImages to scan per batchNo (default: 8)
ARTS_SCAN_RESCHEDULE_SECSInterval for re-scanning repositoriesNo (default: 3600)

​
GC worker

VariableDescriptionRequired
FDB_DIRECTORYFoundationDB directory for registry metadataNo (default: registry)
ARES_CLIENT_ADDRESSAddress of the DFS metadata serviceNo (default: http://localhost:9182)
ARTS_GC_REPOSITORY_QUEUEQueue for repository GC tasksNo (default: arts-gc)
ARTS_GC_CANONICAL_QUEUEQueue for canonical blob GCNo (default: arts-gc-canonical)
ARTS_GC_BATCH_SIZEEntries to process per batchNo (default: 256)
ARTS_GC_PENDING_GRACE_SECSGrace period before deletionNo (default: 86400)

​
Deployment

​
Requirements

Artifact Store requires:
  • Access to a FoundationDB cluster
  • Running DFS deployment (for blob storage)
  • Running Platform deployment (for IAM)
  • Trivy binary (for vulnerability scanning)

​
Service topology

A complete Artifact Store deployment includes:
  1. Registry server: Handles Docker API requests
  2. Scan worker: Processes vulnerability scan queue (optional but recommended)
  3. GC worker: Maintains storage efficiency (required for production)
All components are stateless and can run multiple instances for availability.

​
Trivy setup

The scan worker requires Trivy installed and accessible. It uses Trivy in client mode, pulling images from the registry for analysis. Install Trivy on scan worker nodes: 
# Linux
curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/main/contrib/install.sh | sh -s -- -b /usr/local/bin

# Or via package manager
apt-get install trivy  # Debian/Ubuntu
The scan worker automatically authenticates with the registry using a system service account.

​
Network considerations

The registry server needs to be accessible to:
  • Docker clients pushing and pulling images
  • Scan worker for vulnerability analysis
  • Platform UI for repository browsing
Configure appropriate firewall rules and load balancer settings based on your network topology.