Introduction

Docker --tag and --name look similar because both let you attach human-readable identifiers to Docker objects, but they identify different things. A tag belongs to an image reference. A name belongs to a running or stopped container instance.

--tag Identifies an Image Version

You use --tag, or -t, when building or retagging an image.

docker build -t myapp:1.2.0 .

Here, myapp:1.2.0 is an image name plus a tag. The tag usually communicates version, environment, build identity, or release channel.

Examples:

• myapp:latest
• myapp:1.2.0
• registry.example.com/team/myapp:staging

A single image can have multiple tags pointing to the same image ID.

--name Identifies a Container Instance

You use --name when creating a container from an image.

docker run --name web-1 -p 8080:80 myapp:1.2.0

In this command:

• myapp:1.2.0 selects the image to run,
• web-1 is the container name for that particular instance.

You can run multiple containers from the same tagged image, each with a different container name.

Image Identity Versus Runtime Identity

This is the cleanest distinction:

• tag: which image build or version am I referring to?
• name: which concrete container instance am I talking about right now?

That is why commands around images tend to use tags, while commands around lifecycle and networking often refer to container names.

For example:

docker logs web-1
docker stop web-1
docker rm web-1

Those commands target the container instance, not the image tag.

Why Both Matter in Real Workflows

In CI/CD, tags are how you promote and publish images across environments. In local development and operations, container names make it easier to inspect, stop, and connect to the right running container.

A typical pattern looks like this:

docker build -t myapp:2026-03-11 .
docker run --name myapp-dev myapp:2026-03-11

The image tag says which build you are using. The container name says which instance is currently running.

Where You See Tags and Names in Commands

Image-oriented commands usually speak in tags:

docker pull myapp:1.2.0
docker push myapp:1.2.0
docker images

Container-oriented commands usually speak in names or IDs:

docker ps
docker logs web-1
docker exec -it web-1 sh

That split is a practical way to remember the difference. If the command is about distribution or build identity, think tag. If the command is about a live process, think container name.

One Image, Many Containers

A single tagged image can produce several containers at once:

docker run --name web-a myapp:1.2.0
docker run --name web-b myapp:1.2.0

Both containers come from the same image tag, but each has its own lifecycle, logs, network identity, and writable layer. This is the clearest proof that tag and name are not interchangeable concepts.

Why Tags Deserve a Versioning Strategy

Container names are usually temporary operational labels, but image tags often become part of deployment traceability. Teams that rely only on latest make rollback and debugging harder because the tag stops telling you which build is running. A meaningful tag scheme such as commit SHA, semantic version, or release date is usually more valuable than the container name itself for long-term auditability.

Common Pitfalls

• Thinking --name changes the image name or version.
• Thinking a tag identifies a running container instance.
• Using latest as the only tag and losing track of which build is deployed.
• Forgetting that multiple containers can run from the same image tag.
• Assuming container names must match image names, which Docker does not require.

Summary

• --tag applies to images and usually represents version or release identity.
• --name applies to containers and identifies one runtime instance.
• One image tag can be used to create many differently named containers.
• Container lifecycle commands usually target the container name, not the image tag.
• Tags answer "which build?" while names answer "which running instance?".