Images, Tags and Registries

Introduction

In the basics you built an image. Now you will understand how it is made, how to name it, and how to share it. These details decide how fast your builds are and how safely you deploy.

Layers and the cache

An image is a stack of read-only layers. Most Dockerfile instructions, such as RUN, COPY and ADD, create a layer. Docker caches each layer. If an instruction and everything before it are unchanged, Docker reuses the cached layer, which is why a second build can take seconds.

The order of instructions matters. Put things that change rarely first, and things that change often last:

FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

Dependencies are reinstalled only when package.json changes, not every time you edit code. Inspect layers with:

docker history my-app
docker image ls

Names and tags

A full image name looks like this:

registry.example.com/team/my-app:1.4.2

• The registry is where it is stored. Docker Hub is the default if you leave it out.
• team/my-app is the repository.
• 1.4.2 is the tag, a label for a version. If you leave it out, Docker uses latest.

latest is just a default tag, not a promise that it is the newest. Avoid it in production, because you cannot tell what you are running. Use clear tags such as version numbers or a Git commit hash. Tag an image:

docker build -t my-app:1.4.2 .
docker tag my-app:1.4.2 myuser/my-app:1.4.2

A tag can be moved to a new image. A digest (image@sha256:...) identifies exact content and never changes, so use digests when you need certainty.

Registries

A registry stores and serves images. Examples include Docker Hub, GitHub Container Registry and cloud registries.

docker login
docker push myuser/my-app:1.4.2
docker pull myuser/my-app:1.4.2

Public images are visible to everyone, so never put secrets in an image. Use private repositories for private code, and read the registry's pricing and limits before you depend on it.

Official and trusted base images

Pick base images carefully. They become part of your app.

• Prefer official images and verified publishers.
• Use specific version tags, and update them regularly for security fixes.
• Smaller bases such as -slim or alpine have fewer packages and a smaller attack surface, though they can behave differently.

Clean up

docker image prune        # remove unused (dangling) images
docker system df          # see how much space Docker uses

Try it yourself

Build an image twice and watch the second build use the cache. Then change one source file and see which steps run again. Tag it with a version number and run docker image ls.

Summary

• Images are cached layers, so order instructions from least to most frequently changed.
• Tag images with meaningful versions, and avoid relying on latest.
• Registries store images, so keep secrets out and use trusted base images.