---
title: "Sitecore image reference"
slug: "sitecore-image-reference"
abstract: "Additional information about the Docker images Sitecore makes available."
---
# Sitecore image reference
This topic provides additional information about the images that you find on the Sitecore Container Registry (SCR), *scr.sitecore.com*, and how you use them in your custom solutions.
Browsing the Sitecore Container Registry
You can find a list of available image repositories and tags on the [Sitecore Docker Images repository on GitHub](https://github.com/Sitecore/docker-images/tree/master/tags).
Repository namespaces
Sitecore image repositories are organized in the [Sitecore Container Registry](https://github.com/Sitecore/docker-images/blob/master/tags/sitecore-tags.md) with namespaces.
Naming strategy
Sitecore makes use of several naming conventions to differentiate images:
- Asset images
Certain images, such as modules, are intended only as a source during your custom Sitecore image build and you never use them at runtime. These *asset images* are named accordingly with a `-assets` suffix. The following are example images:
- *spe-assets*
- *sitecore-management-services-xm1-assets*
- *sxa-xp1-assets*
- *sitecore-docker-tools-assets*
- Topology
Certain images are specific to a topology. In this case, the topology (`-xp0`, `-xp1`, or `-xm1`) will be included in the name. If an image does not have a topology in the name, then it is topology-independent. The following are example images:
- *sitecore-xp0-cm*
- *sitecore-xp1-cortexreporting*
- `jss-xm1-assets`
Tagging strategy
All Sitecore images use a tagging system consisting of a *full tag*, a *three-digit tag*, and a *two-digit tag*. In general, the first part of the tag represents the Sitecore or module version, and the rest provides details about the base Microsoft image it is built upon.
Sitecore does not use *latest* tags because these are too ambiguous and generally not followed by Microsoft or any other OS-based images.
### Platform images
Platform images include base images for the Sitecore Experience Platform (*scr.sitecore.com/sxp*). The Sitecore platform version makes up the first part of the tag.
**Full tag:**
`..-.-`
The following is an example tag followed by the breakdown:
```text
10.4.0.004346.337-10.4.17763.1339-ltsc2022
```
```xml
..-.-
\________________/ \_________________/ \______________/ \_______________/ \________________/ \_______/
| | | | | |
10.4.0 004346 337 10.4.17763 1339 ltsc2019
```
**Three-digit tag:**
`-`
The following is an example tag:
```text
10.4.0-ltsc2022
```
**Two-digit tag:**
`-`
The following is an example tag:
```text
10.4-ltsc2022
```
### Modules and tools
These include images such as modules for Sitecore Experience Platform (`scr.sitecore.com/sxp/modules`) and general tools (`scr.sitecore.com/tools`).
Modules and tools might not have versions that align with the platform. If a module or tool does *not* align with the platform version, it provides a compatibility matrix [in the Sitecore Knowledgebase](https://kb.sitecore.net/articles/541788).
**Full tag:**
`..-.-`
The following is an example tag followed by the breakdown:
```text
14.4.0.00368.71-10.4.17763.1339-1809
```
```xml
..-.-
\______________/ \_______________/ \____________/ \_______________/ \________________/ \_______/
| | | | | |
14.4.0 00368 71 10.4.17763 1339 1809
```
**Three-digit tag:**
`-`
The following is an example tag:
```text
14.4.0-1809
```
**Two-digit tag:**
`-`
```text
14.4-1809
```
Choosing a tag
### OS version
When you choose between different OS tags (for example `10.0.0-ltsc2019` versus `10.0.0-1909`), follow the same rules used when you choose Microsoft images. Windows requires the host OS version to match the container OS version. If you want to run a container based on a newer Windows build, make sure you have an equivalent host build. Otherwise, you can use Hyper-V isolation to run older containers on new host builds.
For more information about Windows container version compatibility, see the [Microsoft documentation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/deploy-containers/version-compatibility).
This is not a problem for asset images because these images are never run. They typically have only one OS tag available.
### Full tag versus shorter tags
The full tag locks you to an exact image version.
The three-digit and two-digit tags allow you to be more dynamic, and pull in the latest image version. You lock only the main version (for example, ``) while allowing the remainder (for example, ``, ``, ``) to use the latest.
The choice between using the full tag or one of the shorter tags depends on your build and release process, and how much control over the image version you require. For example, you might use a short tag for development purposes and then transition to the full tag for deployment. If you always want to have the latest image, use a short tag throughout.
Due to the nature of how Sitecore maintains containers and their immutable images, it is best practise to utilize the two-digit tag when creating container images. This ensures the most up-to-date Sitecore container, and that you also automatically get the latest update.
Note that if you use a two-digit tag, such as `10.X-ltsc2019`, your image automatically resolves to the latest full release revision (for example, `10.X.Y`) the next time you pull or build.
Pre-release delta images from the `/sxp-pre/` namespace are designed to be applied on top of the previous full release. For example, the 10.X.Y PRE delta is intended for use on top of 10.X.0 RELEASE. When Sitecore later publishes the corresponding full release (10.X.Y RELEASE), the 2-digit tag automatically resolves to it. If you have not removed the PRE delta from your Dockerfile, your container will have the new release's `Sitecore.config`, which references new processor types. However, it also references the older `Sitecore.Kernel.dll` from the PRE delta, which does not contain those types. This results in a startup failure:
```text
System.InvalidOperationException: Could not find type 'Sitecore.Pipelines.FilterItem.ResolveModeFromContext, Sitecore.Kernel'
```
The full release already includes all fixes from the PRE delta, so the delta is no longer needed when the full release is available.
To resolve this, choose one of the following options:
- *Upgrade to the full release* — remove the `DELTA_ASSET_IMAGE_VERSION` entry from your `.env` file and any corresponding Dockerfile instructions for the PRE delta image. Then, rebuild using `docker-compose build --no-cache` to ensure no cached assemblies are carried over. Verify the correct `Sitecore.Kernel.dll` version for your target release in the table below.
- *Stay on the previous release* — pin to the previous full release using its 3-digit tag, such as `10.X.0-ltsc2019`. The PRE delta remains compatible with this version and does not need to be removed.
If you are upgrading to 10.X.Y, also download the updated `SitecoreContainerDeployment.10.X.Y.*` files from the Sitecore Experience Platform [downloads page](https://developers.sitecore.com/downloads/Sitecore_Experience_Platform). Using outdated deployment files will result in image-not-found errors (for example, `sitecore-idX:10.X.Y-ltsc2019 not found`).
Pulling the latest images
When you use Sitecore image short tags, Docker caches the image digest (an immutable SHA256-based identifier) at the time it is pulled and continues to use it until you either remove the image or explicitly pull the image. You must make sure that you pull the latest image when you need it (for example, for local development and CI environments).
With the [recommended setup for Docker Compose](https://doc.sitecore.com/xp/en/developers/102/developer-tools/build-sitecore-solutions.html "Build Sitecore solutions"), you are able to do most of this with the `docker-compose pull` command, excluding the overrides:
```text
docker-compose -f docker-compose.yml pull
```
This command pulls the latest base Sitecore and Traefik images for you. However, any images you use for build purposes (such as asset images for modules and tools) are not pulled. Unfortunately, a `docker-compose build --pull` is not currently possible due to an [issue/limitation in Docker Compose](https://github.com/docker/compose/issues/6668), so you must pull such images individually (with `docker pull`) or use a full tag for these.
Because it is easy to forget to pull the latest images, you typically automate these commands. You can do this by adding them to your CI build script or a custom *up* script for local development.