It is difficult to give a full description of where you can find images because they come from many different places. Here are a few of the possible sources:

• If you go to the home page of one of the registries using a Web browser, you can often browse around in its public area and see what images they have there.
• If there is a particular application you are trying to run, the specifics pertaining to the image you want for it should be provided by whoever created the container.
• If someone tells you to download a certain image, they will probably give you the URI (Uniform Resource Identifier) for it. You might need to have an account at that registry to download the image, but generally, it will be publicly available. Registries may also include private repositories with images that are only shared with specific collaborators.

URI Syntax

An Apptainer URI looks very much like a URL. It has a URL-like prefix, followed by a path with slashes between the components, and possibly a tag after a colon at the end. Apptainer recognizes three primary URI prefixes that apply to pulling, pushing, or building container images from remote registries and storage services:

• docker:// – Used to pull standard Docker/OCI container images, e.g., from Docker Hub or custom OCI registries. Apptainer converts these images into its own Singularity Image Format (SIF) upon pulling.
• oras:// – Used for ORAS (OCI Registry as Storage) artifact registries that support storing and retrieving SIF files directly. This allows both pulling and pushing of SIF images (but not Docker/OCI images).
• library:// – Used to interact with the library at Singularity Container Services (as well as custom or self-hosted library registries), in order to pull and manage collections.

Let's now look at a few of the different registries that are available, and the types of URIs you would be given for pulling images from them with Apptainer.

URIs for Docker/OCI images

Docker Hub is a very popular registry for obtaining Docker images that you can use with Apptainer. The docker:// prefix appears in the URI of any registry that is compatible with Docker Hub. Such registries may also host images in the OCI (Open Container Initiative) format, which is an open-source standard that was derived from Docker. When Apptainer pulls a Docker or OCI image from a docker:// registry, it converts the image into its native SIF format. Here is the full structure of a docker:// URI:

If the registry name is omitted, Apptainer fetches the image from Docker Hub (docker.io) by default. If the namespace component is omitted, library is assumed. There are other registries of Docker and OCI images, too; as a result, docker:// URIs may have diverse components. Here are some examples:

The initial part of a Docker URI names the registry where an image resides. When downloading an image from NVIDIA, for instance, the nvcr.io component of the URI indicates the registry where NVIDIA stores its images. The next component in the example, nvidia, is a namespace within that registry. Other namespaces may exist under nvcr.io as well. A similar pattern is seen in the URIs for BioContainers images. They begin with quay.io, a registry operated by Red Hat, and relevant images are found in the biocontainers namespace.

Optionally, at the end of any of these URIs is the possibility of specifying a tag. A tag is a way of saying which version of an image you would like to download. If you don't specify a tag, you will get the latest version of the image.

URIs for SIF images

The native format for Apptainer/Singularity containers is SIF. SIF images are just regular files, so in principle, any typical website can host them. SIF files can also be hosted by general-purpose OCI artifact registries (which use the ORAS protocol). In both cases, a full URL or URI beginning with beginning with http:// or https:// or oras:// must be provided to Apptainer to identify a particular image. But the majority of public container registries do not specialize in this file format. Fortunately, though, Apptainer recognizes two other, special URI prefixes for certain registries that are intended for SIF files: library:// and shub:// (deprecated).

The library:// prefix corresponds to both a protocol and a specific registry that is set through the apptainer remote command. At TACC, the system-wide default registry for any library:// URI is the registry hosted by Singularity Container Services, from Sylabs. Today, it stands as the main registry for obtaining SIF files and base images directly. (It hosts OCI images as well, but these cannot be pulled by Apptainer.) In general, a library:// URI should be completed by a full path like this:

A user can have one or more collections hosted in the library. The name of an image in a user's collection appears at the end of the URI, along with an optional tag. If the tag is not specified, then the latest version is selected. If a user-collection combination is not specified, Apptainer assumes library/default, a collection which is maintained by Sylabs itself. In fact, all collections of the "library" user are curated by Sylabs. Additional collections curated by Sylabs are those of the users sylabs and sylabs-jms.

Before Apptainer arrived on the scene, the original Singularity ecosystem had its own hub, Singularity Hub, where people could upload their images. There are still images archived there, and they still run, but the platform has been deprecated. One consequence of this is that shub:// is a very poor source of images for the ARM64 architecture. Still, you will occasionally see a Singularity Hub URI.