A multi-architecture image tag points to an image index, which lists one manifest per platform. Pin the index digest if the same reference must run on several architectures. Pin a platform manifest digest if you want one exact image for one architecture. Both are fixed, but they cover different things.
What an index is
The OCI image specification defines an image index as a higher-level manifest that points to one or more image manifests, typically one per platform. Each entry has a platform object with required architecture and operating system fields, and optional fields such as variant. The values for architecture and OS come from Go's naming.
When a client pulls a multi-arch tag, it compares its own platform with each entry. The spec says that if several manifests match, the first matching entry should be used.
Kubernetes describes the same idea: a registry can serve a container image index that can point to multiple image manifests for architecture-specific versions of a container.
Two digests, two meanings
- Index digest. A hash of the index document. It fixes the whole list, so every platform entry is fixed. An amd64 node and an arm64 node each pick their matching manifest, and each of those is fixed too.
- Platform manifest digest. A hash of one platform's manifest. It fixes one image for one architecture. A node of another architecture cannot run it.
Because a digest is a hash of content, changing anything inside changes the digest. That is why the index digest is stable if and only if every platform entry stays the same.
Which should you choose?
Use the index digest when:
- Your cluster mixes architectures, for example some nodes on a different CPU family.
- Developers on laptops and CI on servers must share one reference.
- You want a single value in your deployment files.
Use a platform digest when:
- You run one architecture only and want the smallest surprise.
- You are investigating a difference between platforms.
- A policy or signature was created against that specific manifest.
For most teams with mixed hardware, the index digest is the practical default. For single-architecture shops, either works, and the index digest still lets you add a platform later without editing every file.
The gotchas
Tags do not tell you which platform you got. The same tag gives different content to different machines. When you debug "works on my laptop," check platform first.
Signatures and attestations attach to a digest. If you sign the index but verify a platform manifest, or the reverse, verification can fail or miss. Decide which one your tooling signs and verify the same one. Build attestations in BuildKit, for example, are stored in the image index, with each attestation manifest referring to one platform image manifest.
Updating one platform changes the index. Rebuild only arm64 and the index digest changes, even though amd64 content is the same.
Scan every platform. A finding can exist in one architecture's image and not another, for example in architecture-specific packages. Scan the platform that you deploy, not only the tag.
How to look inside
Use your registry client to fetch the manifest for a tag and read the manifests list with its platform fields. Then fetch each by digest. Compare the digests to what your deployment file references.
Safeguard's SBOM and dependency scanning can inventory the image you actually deploy, and you can try a free scan. For the tag versus digest basics, see why pinning matters.
Quick check
Does pinning the index guarantee the same bytes on every node?
It guarantees the same list of images. Each node then fetches the entry for its own platform, so different architectures get different, but fixed, content.
Can a tag point to an index and later to a single manifest?
Tags are movable pointers, so yes, a publisher can repoint one. A digest cannot be repointed.
Sources
Last reviewed: 19 October 2026.
