Go to Chainguard.dev
Send feedback Contact
Chainguard Containers

Overview of Chainguard Containers

Chainguard Containers Overview
Chainguard Containers Product

Chainguard Containers are a collection of container images designed for security and minimalism.

Many Chainguard Containers are distroless; they contain only an open-source application and its runtime dependencies. These images do not even contain a shell or package manager, and are often paired with an equivalent development variant (sometimes referred to as a dev variant) that allows further customization, for build and debug purposes. Chainguard Containers are built with Chainguard OS, designed from the ground up to produce container images that meet the requirements of a secure software supply chain.

The main features of Chainguard Containers include:

Chainguard Containers are primarily available from Chainguard’s registry, but a selection of developer images is also available on Docker Hub. You can find the complete list of available Chainguard Containers in our public Containers Directory or within the Chainguard Console.

Why Minimal Container Images

The fewer dependencies a given piece of software uses, the lower likelihood that it will be impacted by CVEs. By minimizing the number of dependencies and thus reducing their potential attack surface, Chainguard Containers inherently contain few to zero CVEs. Chainguard Containers are rebuilt nightly to ensure they are completely up-to-date and contain all available security patches. With this nightly build approach, our engineering team sometimes fixes vulnerabilities before they’re detected.

Note that there is often a development variant of each Chainguard Container available. These are sometimes called the -dev variant, as their tags include the -dev suffix (as in :latest-dev). For example, the development variant of the mariadb:latest container image is mariadb:latest-dev. These container images typically contain a shell and tools like a package manager to allow users to more easily debug and modify the image.

Why Multi-Layer Container Images

Chainguard originally took a single-layer approach to container images built with apko in order to offer simplicity and clarity. However, in an effort to deliver better stability, security, and efficiency for larger and more complex applications, Chainguard introduced multi-layer container images in May 2025. This approach leverages container runtime caching so that a layer used by multiple images does not need to be downloaded more than once, and you don’t need to download the whole image each time there is an update on one layer.

Chainguard’s approach to layering is a “per-origin” strategy, where packages that derive from the same upstream source are grouped in the same layer because they tend to receive updates together.

We observed that this approach achieved the following:

  • A ~70% reduction in the total size of unique layer data across our image catalog compared to the single-layer approach
  • A 70-85% reduction in the cumulative bytes transferred when simulating sequential pulls of updated images like PyTorch and NeMo

To maximize the stability and re-useability of our layers, Chainugard identified, analyzed, and implemented three additional technical changes:

  • Added in an additional final layer that captures frequently updated OS-level metadata
  • Developed intelligent layer ordering to optimize compatibility
  • Ensured sufficient layer counts to optimize parallel downloads by container clients

The primary benefit of this layered approach is that when one package changes it impacts only its particular layer, requiring only that layer to be downloaded again. Because the other layers don’t need to be downloaded again, Chainguard’s multi-layer container images support greater efficiency and developer velocity.

Production and Starter Containers

Chainguard offers a collection of container images that are publicly available and don’t require authentication, being free to use by anyone. We refer to these images as Starter containers, and they cover several use cases for different language ecosystems. Starter images are limited to the latest build of a given image, tagged as latest and latest-dev.

Production containers are enterprise-ready images that come with patch SLAs and features such as Federal Information Processing Standard (FIPS) readiness and unique time stamped tags. Unlike Starter containers, which are typically paired with only the latest version of an upstream package, Production containers offer specific major and minor versions of open source software.

You can access our container images directly from Chainguard’s registry. Chainguard’s registry provides public access to all public Chainguard Containers, and provides customer access for Production Containers after logging in and authenticating.

For a complete list of Starter containers that are currently available, check our Containers Directory. Registered users can also access all Starter and Production containers in the Chainguard Console. After logging in you will be able to find all the current Starter containers in the Public containers tab. If you’ve selected an appropriate Organization in the drop-down menu above the left hand navigation, you can find your organization’s Production containers in the Organization images tab.

Comparing Container Images

The following graph shows a comparison between the official Nginx image and Chainguard’s Nginx container image, based on the number of CVEs (common vulnerabilities and exposures) detected by Grype:

Nginx

Comparing the latest official Nginx image with cgr.dev/chainguard/nginx

The major advantage of distroless images is the reduced size and complexity, which results in a vastly reduced attack surface. This is evidenced by the results from security scanners, which detect far fewer potential vulnerabilities in Chainguard Containers.

You can review more comparisons of Chainguard Containers and external images by checking out our Vulnerability Comparisons dashboard.

chainctl, Chainguard’s command line interface tool, comes with a useful diff feature that also allows you to compare two Chainguard Containers.

Architecture

By default, all Wolfi-based images are built for x86_64 (also known as AMD64) and AArch64 (also known as ARM64) architectures. Being able to provide multi-platform Chainguard Containers enables the support of more than one runtime environment, like those available on all three major clouds, AWS, GCP, and Azure. The macOS M1 and M2 chips are also based on ARM architecture. Chainguard Containers allow you to take advantage of ARM’s power consumption and cost benefits.

You can confirm the available architecture of a given Chainguard Container with Crane. In this example, we’ll use the latest Ruby image, but you can opt to use an alternate image.

crane manifest cgr.dev/chainguard/ruby:latest |jq -r '.manifests []| .platform'

Once you run this command, you’ll receive output similar to the following.

{
  "architecture": "amd64",
  "os": "linux"
}
{
  "architecture": "arm64",
  "os": "linux"
}

This verifies that the Ruby Chainguard Container is built for both AMD64 and ARM64 architectures.

You can read more about our support of ARM64 in our blog on Building Wolfi from the ground up.

Last updated: 2025-05-27 08:49

Chainguard Containers FAQs   Next