catalog
DHI definition files and catalog metadata
Docker Hardened Images catalog publishes declarative definitions for minimal container images
A repository of declarative YAML specs that build secure, minimal, production-ready container images and Helm charts, pulled from the dhi.io registry.
What the catalog contains
This repository is the home of the Docker Hardened Images definition files. It holds declarative specifications for building secure, minimal, and production ready container images and Helm charts. The README states that every image is built with a minimal attack surface and hardened configurations, kept continuously updated with the latest security patches, configured with best practices for enterprise deployments, and fully open source so the definitions can be audited or customized. The image set spans a wide range of categories. Base images include alpine-base, debian-base, and busybox. Language runtimes include python, node, golang, rust, and several Java distributions such as OpenJDK, Eclipse Temurin, Amazon Corretto, and Azul. Databases include postgres, mysql, mongodb, redis, valkey, clickhouse, elasticsearch, and opensearch. Infrastructure images include nginx, haproxy, traefik, and envoy. Observability images include prometheus, grafana, loki, tempo, alloy, and fluent-bit. Kubernetes tooling includes kubectl, helm, kustomize, argocd, istio, cilium, and kyverno. Security tooling includes vault, cert-manager, cosign, trivy, and grype. Development tooling includes maven, gradle, git, and jenkins. Each definition is a YAML file describing metadata, base OS, packages, the build pipeline, security configuration, runtime settings, and automated tests. Variants cover a minimal runtime image, a dev image with build tools and a shell, and a compatibility image for Helm charts.
How images and charts are defined
The repository is laid out so that each image, chart, and reusable package is a separate declarative definition. An image definition lives under image and follows a structure of per OS variants, each holding one or more YAML config files, with an optional logo. For example, the nginx image carries alpine and debian variants, and the debian variant carries mainline, mainline-dev, stable, and other config files. The YAML files record the image name, supported tags and platforms, the base OS and packages, the multi stage build steps, user and group configuration, file permissions, the entrypoint and command, environment variables, exposed ports, and validation tests. Charts live under chart and describe applications deployed with hardened images. Each chart directory holds an info.yaml with the display name and category, an overview.md, a guides.md, a logo, and the Helm chart files themselves. The README lists example charts such as alertmanager, cert-manager, grafana-agent, vault, traefik, and minio. A third kind of definition, under package, holds shared components that multiple image definitions reference, which the project says promotes consistency and reduces duplication. The listed packages include binutils, expat, git-lfs, go-yq, golang, gosu, gradle, node, python, and datawire-envoy. The structure keeps the human readable source of each image in one place, separate from the compiled artifact that users pull.
Using and contributing to the definitions
Pre built images are served from Docker's registry rather than built by end users from this source. The README shows pull commands such as docker pull dhi.io/nginx:1.29.3-debian13, docker pull dhi.io/python:3.12-debian13, and docker pull dhi.io/postgres:17-debian13. On the security side, the project states that images are built from minimal base images, configured with least privilege principles, scanned for vulnerabilities, updated regularly with security patches, and run as non root users by default. Vulnerability reports follow a responsible disclosure process documented in the repository security policy. Contributions are welcomed for several activities: adding new image definitions, improving existing configurations, updating documentation, reporting issues, and sharing best practices. The contribution guide and a code of conduct sit at the repository root alongside the license file. The catalog is presented as a collaborative effort, with the tagline that the community builds secure containers together. Because the definitions are plain text, a user can read exactly what packages and permissions an image carries before pulling it, and can fork the repository to adjust a definition to local requirements. The repository is part of Docker's broader hardened images product, and the README points to a commercial support channel for production use. Each published image therefore maps to a readable definition in this repository, so a security team can review the exact build steps before deployment. Each published image therefore maps to a readable definition in this repository, so a security team can review the exact build steps before deployment.
Editorial conclusion
The repository is published under the Apache 2.0 license and its most recent commit was recorded on 2026-08-26. The source lives at https://github.com/docker-hardened-images/catalog.
Community notes