Container runtime images (source of truth)

Purpose: Single reference for which container images run when the platform is up, for security reviews, supply-chain questions, and Chainguard or registry planning.

Last updated: 2026-06-09

How to read this

• Runtime image = what actually executes in a long-running container (the effective image: after build, or the final stage of a multi-stage Dockerfile).
• First-party images = built from this repository (Go services, UIs, ai-analysis-service). They are published to your registry (for example ECR) in production; locally they are built by Docker from Dockerfile.dev / Dockerfile.prod.
• Third-party images = pulled from a public or vendor registry as-is.

Default registry: References without a host (for example postgres:17-alpine) resolve to Docker Hub (docker.io). Override only if your org uses mirrors or pull-through caches.

Maintenance: When you add a service, change a FROM, or change a compose image:, update this file. Compose files are partly generated from standards/service-registry.yaml (make generate); infrastructure exceptions stay in root docker-compose*.yml.

First-party runtime images (application workloads)

These images contain Vista code. Production references below use ${ECR_REGISTRY}crypto-inventory/<name>:${IMAGE_TAG} from docker-compose.prod.yml (substitute your registry and tag). Local development builds the same logical services from Dockerfile.dev via docker-compose.yml.

Local development (UI only): web-ui/Dockerfile.dev and admin-ui/Dockerfile.dev run on node:24-alpine (Vite dev server), not Caddy.

Build-time bases (not the running container for Go services): All Go services above use golang:1.26-alpine as the compile stage; the shipped runtime remains alpine:3.24.1.

Third-party runtime images (pulled directly)

docker-compose.prod.yml (production-style stack)

Not in docker-compose.prod.yml today: notification-service, discovery-processor-service (they appear in local dev compose and in sample EKS manifests).

docker-compose.yml (local full stack) — extra / different

Same third-party set as prod, plus:

Local stack note: docker-compose.yml does not include ai-analysis-service; docker-compose.prod.yml does.

Sample Kubernetes (k8s/eks/)

• Application images: *.dkr.ecr.us-east-1.amazonaws.com/crypto-inventory/<service>:latest (see 04-deployments-backend.yaml, 06-deployments-frontend.yaml). Includes notification-service and discovery-processor-service.
• api-gateway: traefik:v3.3
• nats: nats:2.9-alpine (different patch stream than compose’s 2.10-alpine; align intentionally if both are used).

Postgres/Redis/Influx in real EKS deployments are often managed services rather than images in this repo; treat those as environment-specific.

Other template (k8s/production-balanced/deployments.yaml)

Placeholder gcr.io/PROJECT_ID/... images for a subset of services (GCP-oriented sample).

Deduplicated third-party catalog (compose-based product)

Unique public images referenced by docker-compose.prod.yml and docker-compose.yml for a full local run:

Additional bases inside first-party images (not separate compose services): alpine:3.24.1, golang:1.26-alpine (build), node:24-alpine (UI build or dev runtime), caddy:2-alpine (UI prod runtime), python:3.11-slim (ai-analysis-service).

Environment summary

For compliance answers, state which compose file or cluster defines the deployment; the sets are not identical.