podman-manifest-add(1)
π podman-manifest-add π
okay bestie, gather round, because this one is literally from the General Commands Manual and it's giving main character energy for your manifest lists. it's podman-manifest-add, and it's about to be your new obsession π«Ά
β¨ NAME β¨
podman-manifest-add β add an image or artifact to a manifest list or image index π
β¨ SYNOPSIS β¨
podman manifest add [options] listnameorindexname [transport]:imagename imageorartifactname [...]
β¨ DESCRIPTION β¨
so basically? it adds the image you picked to the manifest list or image index you picked. OR β plot twist β it creates an artifact manifest and adds that to the image index you specified. either way you're adding something to a list and it's iconic π
β¨ RETURN VALUE β¨
the list image's ID. that's it, that's the tea. π
β¨ OPTIONS β¨
--allβ if the image you're adding is itself a list or index, this adds all of its contents to the local list. default behaviour is only adding one image from such a list or index. ngl, combining--allwith any of the other options down below is NOT recommended, so don't do that to yourself bestie π--annotation=annotation=valueβ sets an annotation on the entry for the image or artifact you specified.--arch=architectureβ overrides the architecture that the list or index records as a requirement for the image. ifimageNamepoints at a manifest list or image index, the architecture info gets pulled from there. otherwise it comes from the image's configuration information.--artifactβ creates an artifact manifest and adds it to the image index. arguments after the index name get interpreted as file names instead of image references. in most scenarios you should also be passing--artifact-typetoo, just saying.--artifact-config=pathβ when you're creating an artifact manifest and adding it to the image index, this uses the specified file's contents as the configuration blob in the artifact manifest. in most scenarios the preferred move is leaving the default value alone, and that default means an empty configuration. π--artifact-config-type=typeβ when creating an artifact manifest and adding it to the image index, this uses the specified MIME type as the mediaType tied to the configuration blob in the artifact manifest. again, in most scenarios the preferred move is leaving the default value unchanged β that default signifies either an empty configuration or the standard OCI configuration type.--artifact-exclude-titlesβ when creating an artifact manifest and adding it to the image index, this stops it from setting"org.opencontainers.image.title"annotations equal to the file's basename for each file added to the artifact manifest. tools that retrieve artifacts from a registry may use those values to choose file names when saving artifacts to disk, so this option is not recommended unless a particular registry requires it for interoperability. β οΈ--artifact-layer-type=typeβ when creating an artifact manifest and adding it to the image index, this uses the specified MIME type as the mediaType tied to the files' contents. if you don't specify it, guesses get made based on either the file names or their contents β but if you need certainty, specify it.--artifact-subject=imageNameβ when creating an artifact manifest and adding it to the image index, this sets the subject field in the artifact manifest, marking the artifact manifest as associated with the specified image in some way. an artifact manifest can only be associated with, at most, one subject. periodt.--artifact-type=typeβ when creating an artifact manifest, this uses the specified MIME type as the manifest's artifactType value instead of the less informative default value.--authfile=pathβ path of the authentication file. default is${XDG_RUNTIME_DIR}/containers/auth.jsonon Linux, and$HOME/.config/containers/auth.jsonon Windows/macOS. the file is created bypodman login. if the authorization state isn't found there,$HOME/.docker/config.jsongets checked, which is set usingdocker login.
note: there's also the option to override the default path of the authentication file by setting theREGISTRY_AUTH_FILEenvironment variable. you do it like this:export REGISTRY_AUTH_FILE=path.
--cert-dir=pathβ uses certificates at path (*.crt,*.cert,*.key) to connect to the registry. (default:/etc/containers/certs.d) for the deets, seecontainers-certs.d(5). (heads up: this option is not available with the remote Podman client, including Mac and Windows machines, excluding WSL2) π--creds=[username[:password]]β the[username[:password]]to use when authenticating with the registry, if that's required. if one or both values aren't supplied, a command line prompt shows up and you can type the value in. the password gets entered without echo.
note that the credentials you specify are only used to authenticate against target registries. they are not used for mirrors, and not used when the registry gets rewritten (seecontainers-registries.conf(5)). to authenticate against those, consider using acontainers-auth.json(5)file instead.
--features=featureβ specifies the features list that the list or index records as requirements for the image. this option is rarely used. (rare queen energy β¨)--os=OSβ overrides the OS that the list or index records as a requirement for the image. if imagename refers to a manifest list or image index, the OS information is retrieved from it. otherwise it's retrieved from the image's configuration information.--os-version=versionβ specifies the OS version that the list or index records as a requirement for the image. this option is rarely used too.--tls-verifyβ require HTTPS and verify certificates when contacting registries (default:true). if explicitly set totrue, TLS verification is used. if set tofalse, TLS verification is not used. if not specified, TLS verification is used unless the target registry is listed as an insecure registry incontainers-registries.conf(5). π₯--variantβ specifies the variant that the list or index records for the image. this option is typically used to distinguish between multiple entries that share the same architecture value, but which expect different versions of its instruction set. iykyk.
π Transport π
multiple transports are supported, bestie. here's the whole roster:
docker://docker-reference (default)
an image in a registry implementing the "Docker Registry HTTP API V2". by default it uses the authorization state in $XDG_RUNTIME_DIR/containers/auth.json, which is set using (podman login). if the authorization state isn't found there, $HOME/.docker/config.json gets checked, which is set using (docker login).
$ podman manifest add mylist:v1.11 docker://quay.io/username/myimage
containers-storage:oci-reference
an image in oci-reference format stored in the local container storage. oci-reference must contain a tag.
$ podman manifest add mylist:v1.11 containers-storage:quay.io/username/myimage
dir:path
an existing local directory path storing the manifest, layer tarballs, and signatures as individual files. this is a non-standardized format, primarily useful for debugging or noninvasive container inspection.
$ podman manifest add dir:/tmp/myimage
docker-archive:path[:docker-reference]
an image is stored in the docker save formatted file. docker-reference is only used when creating such a file, and it must not contain a digest.
$ podman manifest add docker-archive:/tmp/myimage
docker-daemon:docker-reference
an image in docker-reference format stored in the docker daemon internal storage. the docker-reference can also be an image ID (docker-daemon:algo:digest).
$ sudo podman manifest add docker-daemon:docker.io/library/myimage:33
oci-archive:path:tag
an image tag in a directory compliant with "Open Container Image Layout Specification" at path.
$ podman manifest add oci-archive:/tmp/myimage
πΈ EXAMPLES πΈ
add the specified default image from a source manifest list to a destination manifest list:
podman manifest add mylist:v1.11 docker://fedora
71c201d10fffdcac52968a000d85a0a016ca1c7d5473948000d3131c1773d965
add all images from a source manifest list to a destination manifest list:
podman manifest add --all mylist:v1.11 docker://fedora
71c201d10fffdcac52968a000d85a0a016ca1c7d5473948000d3131c1773d965
add a selected image matching arch and variant from a source manifest list to a destination manifest list:
podman manifest add --arch arm64 --variant v8 mylist:v1.11 docker://71c201d10fffdcac52968a000d85a0a016ca1c7d5473948000d3131c1773d965
π¦ SEE ALSO π¦
and that's the whole page babes, straight outta the General Commands Manual β podman-manifest-add(1), go add some images to your lists and slay π
β¨ππ«Ά
π¦ where this page comes from
- arch rolling: podman-docker 6.1.4-1 Β· Apache-2.0
- fedora 43: podman-docker 5:5.6.2-1.fc43 Β· Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0
- fedora 43: podman-docker 5:5.8.4-1.fc43
- fedora 43: podman-docker 5:5.8.8-1.fc43
- fedora 43: podman-docker 5:5.8.9-1.fc43 Β· Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0
- fedora 44: podman-docker 5:5.8.1-1.fc44 Β· Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0
- fedora 44: podman-docker 5:5.8.7-1.fc44
- fedora 44: podman-docker 5:5.8.9-1.fc44 Β· Apache-2.0 AND BSD-2-Clause AND BSD-3-Clause AND ISC AND MIT AND MPL-2.0
- ubuntu resolute: podman-docker 5.7.0+ds2-3build1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms