Introduction

This Docker conflict error means the new container is trying to claim a resource that another container already owns. In practice, the conflict is usually a container name, a published host port, or a network-related identifier, and the fix is to identify exactly which resource is colliding before changing or deleting anything.

Start by Reading the Specific Conflict

The wording matters. Docker may be complaining about:

• a container name already in use
• a host port already bound
• an endpoint or network alias already taken
• a Compose-managed resource that still exists from an earlier run

These are all "conflicts," but the remedy is different for each one.

Container Name Conflicts

A container name must be unique, even if the existing container is stopped.

docker run --name web -d nginx
docker run --name web -d nginx

The second command fails because web already exists.

To diagnose it, use:

docker ps -a --filter "name=web"

Then choose one of these paths:

• remove the old container if it is disposable
• rename the old container if you want to keep it
• choose a different name for the new container

Examples:

docker rm -f web

or:

docker rename web web-old

Port Conflicts Are a Different Problem

If the issue is host port binding, unique names will not help.

docker run -d -p 8080:80 --name web1 nginx
docker run -d -p 8080:80 --name web2 nginx

Here the name is different, but the host port 8080 is already taken.

Check current port mappings with:

docker ps --format 'table {{.Names}}\t{{.Ports}}'

Then either stop the container using that port or publish the new container on a different host port.

docker stop web1
docker run -d -p 8081:80 --name web2 nginx

Compose Can Leave Conflicting Resources Behind

Docker Compose often creates a project-specific set of containers, networks, and names. If an earlier stack was not fully torn down, a later up can collide with leftover resources.

A clean cycle is usually:

docker compose down
docker compose up -d

If the problem persists, inspect all containers and networks rather than assuming Compose is confused.

docker ps -a
docker network ls

Stale resources are far more common than daemon corruption.

Why docker ps Is Not Enough

A stopped container does not appear in plain docker ps, but it still reserves its container name. That is why name conflicts often seem mysterious until you remember to use docker ps -a.

This is one of the highest-value debugging habits for Docker conflicts.

Build a Better Local Workflow

Conflict errors usually come from repeated local iteration with inconsistent cleanup. Good habits reduce them:

• use predictable naming conventions
• tear down old test containers after use
• keep a documented host-port map for local services
• use Compose project isolation when running several stacks

Most of these errors are workflow problems, not Docker bugs.

Common Pitfalls

Assuming every conflict is a port collision is a common mistake. Many are simple name collisions.

Using docker ps instead of docker ps -a causes stopped containers to be overlooked.

Deleting containers before identifying the actual conflicting resource can also make debugging noisier than necessary.

Finally, if Compose is involved, do not forget that old project resources may remain until they are explicitly brought down.

Summary

• the conflict error means a resource the new container wants is already owned by another container
• the most common conflicts are container names and host ports
• use docker ps -a for name conflicts and inspect published ports separately for bind conflicts
• Compose stacks can leave stale resources behind if not torn down cleanly
• diagnose the exact resource first, then remove, rename, stop, or remap deliberately