Container Name Is Already in Use: Resolving the Conflict Error

Symptom: the name is taken

docker: Error response from daemon: Conflict. The container name "/my-app" is
already in use by container "a1b2c3d4e5f6...". You have to remove (or rename)
that container to be able to reuse that name.

One-line diagnosis: a container named my-app already exists — container names are globally unique. Note that "exists" ≠ "running" — a stopped container still holds its name, which is the most common blind spot around this error. The full container ID is right there in the message, so the fix is direct.

The quick fix (covers 80% of cases)

# Delete by the ID from the error (-f stops a running one first)
docker rm -f a1b2c3d4e5f6

# Or by name
docker rm -f my-app

# Confirm
docker ps -a | grep my-app

docker rm -f on a running container is stop + remove; volumes are unaffected — removing a container deletes its writable layer, while data in volumes survives. But if you wrote data into the writable layer without a volume, removing the container removes the data: run docker diff <name> first to check for files worth rescuing.

Four frequent scenarios

1. The previous docker run container is still there (most common)

Repeatedly running docker run --name my-app ... while debugging — the first container stopped but was never removed. What you want is "restart", not "create another":

docker start my-app      # already exists → start, not run
docker logs -f my-app    # see why it exited before

2. Compose project leftovers

Containers from docker compose up are named project + service (like app-my-app-1). You changed the config and want a rebuild, but the old container holds the name:

docker compose down      # stop + remove all project containers (volumes kept unless --volumes)
docker compose up -d

docker compose stop only stops — containers remain, names held. When in doubt among down/stop/rm: choose down.

3. The restart policy resurrected it

Containers with --restart unless-stopped or always come back automatically after a host reboot. You think it's dead and try to create a new one while it's alive:

docker ps --filter "name=my-app" --format "{{.Names}}: {{.Status}}"

4. One-shot containers missing --rm

Debugging containers should vanish when done — add --rm and stop accumulating name squatters:

docker run --rm --name temp-test myapp/api:v1 ...

Don't want to delete? Rename the old one

Something in the old container worth keeping? Rename it out of the way:

docker rename my-app my-app-old
docker run --name my-app ...   # the name is free now

Prevention

1. Let compose manage long-lived services instead of manual docker run --name — compose handles rebuilds itself
2. One-shot debug containers always get --rm
3. CI/CD scripts start with docker rm -f <name> 2>/dev/null || true for idempotent deploys
4. Audit docker ps -a regularly; clean containers stopped for over a week

Telling the neighboring errors apart

| Error | What's occupied | Guide | |---|---|---| | container name already in use | the container name | this post | | port is already allocated | a host port | port conflict | | Conflict. The network ... already exists | a compose network | docker network rm / compose down |

Checklist

1. docker ps -a --filter name=<name> — who holds it? What state?
2. Want the old one back → docker start; done with it → docker rm -f
3. Compose scenario → docker compose down before up
4. Data to rescue in the old container? docker diff / back up first
5. Future debug containers get --rm; long-lived services go to compose

Provided by ToolVault. Related tools: Dockerfile Generator, Linux Cheatsheet. Related reading: Docker port is already allocated, Docker disk cleanup. See the homepage for more developer tools.