Docker: Conflict. The container name "/X" is already in use

Why it happens, in short: Docker container names are unique per daemon and stay claimed for the container's entire lifetime, not just while it's running — so a container that exited days ago still owns the name until you remove it. The full explanation is further down the page.

The exact error string

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

Docker Desktop and Podman phrase the same conflict slightly differently — Podman's CLI says Error: creating container storage: the container name "myapp" is already in use by ... — but the cause and every fix below are identical. One difference worth knowing: Podman's docker run supports a --replace flag that atomically removes any existing container with the same name before creating the new one; the Docker CLI has no equivalent, which is why docker rm -f first is the standard two-step pattern here.

Fastest fix

docker rm -f myapp        # remove the existing container (stops it first if running)
docker run --name myapp myimage   # now the name is free

That resolves it in the large majority of cases. But read the 30-second triage below before running it — docker rm is destructive, and occasionally the container in your way is one you actually want.

30-second triage: is that container disposable?

The leading / in "/myapp" is just Docker's internal naming prefix, not part of a path — ignore it. What matters is what that container is:

docker ps -a --filter "name=myapp"
# CONTAINER ID   IMAGE     STATUS                     NAMES
# a1b2c3d4e5f6   myimage   Exited (0) 2 days ago      myapp

Fix 1: remove the old container

$ docker rm myapp       # works if the container is stopped
myapp
$ docker rm -f myapp    # force: stops it first, then removes it
myapp

Both commands echo back the container name on success — that's the confirmation, not an error, so don't be thrown by the terse output. If the container is stopped, plain docker rm is enough. If it's running, docker rm refuses and you need -f, which sends a kill signal to stop it first and then removes it in the same step. Because -f handles both cases, it's the one to reach for when you already know the container is disposable.

If you're cleaning up a whole pile of these rather than one, docker container prune removes every stopped container at once (after a confirmation prompt) — faster than naming them individually, but broader: run docker ps -a first to see what it's about to take.

Note what removal deletes: the container and its writable layer. It does not delete the image, and it does not delete named volumes attached to it — so a database using a proper named volume keeps its data across a docker rm. That's exactly why volumes exist, and it's also why pruning with --volumes is the dangerous operation while removing a container is usually not.

Fix 2: reuse the existing container instead

If the conflict is telling you "this thing already exists," sometimes the right answer is to use it rather than replace it:

docker start myapp            # start it in the background
docker start -ai myapp        # start it attached, with an interactive terminal
docker logs myapp             # see what it did on its previous run

This preserves the container's filesystem and any state written inside it. It's the correct move when the container is your environment — a long-lived dev database, a configured sandbox — rather than a fresh instance you were about to recreate anyway.

Fix 3: rename, so both can coexist

# give the NEW container a different name
docker run --name myapp-v2 myimage

# or rename the OLD one and free up the original name
docker rename myapp myapp-old
docker run --name myapp myimage

docker rename works on stopped and running containers alike and is completely non-destructive — useful when you want to keep the old container around for comparison or debugging while a new one takes over the canonical name.

Fix 4: stop it recurring — --rm

docker run --rm --name myapp myimage

With --rm, Docker deletes the container the instant it exits, so the name is always free for the next run. This is the right default for anything short-lived: test runs, one-off scripts, CI jobs, docker run commands you type by hand while iterating.

The trade-off is real, though: once the container exits, it's gone — you can't docker logs it, you can't docker inspect it, and you can't copy files out of it. If you're debugging why a container exits (for example chasing an exit code 137 / OOMKilled), drop --rm temporarily so the corpse sticks around for the post-mortem.

Fix 5: the idempotent pattern for CI and scripts

In automation the conflict usually appears after a cancelled or crashed previous run left a container behind. Make cleanup unconditional so a retry can never fail on it:

# safe whether or not the container exists — `|| true` swallows the "No such container" error
docker rm -f myapp || true
docker run --name myapp myimage

# or, in one step, if the container is disposable:
docker run --rm --name myapp myimage

Without the || true, docker rm exits non-zero when the container doesn't exist, which fails the pipeline step on the first (clean) run — the opposite of what you want.

Fix 6: Docker Compose

Compose hits this in two distinct situations, and they have different fixes:

# the stack was stopped, not removed — containers still exist and hold their names
docker compose down          # removes containers (and networks); `stop` does not
docker compose up

The second situation is an explicit container_name: in your compose file. That opts out of Compose's automatic per-project naming, which is precisely what makes the name collide across projects or branches:

services:
  api:
    image: myimage
    container_name: myapp   # forces a fixed global name; collides easily

Unless you have a specific reason to pin the name (a hardcoded reference from outside the stack), leave container_name out entirely. Without it, Compose derives the name from the project folder, the service name, and an instance number instead — a project named billing with a service named api gets billing-api-1, unique per project. That's also what lets you run the same stack for two branches simultaneously by varying the project name with -p.

Why it happens: names are unique and outlive the process

Docker keeps a single flat namespace of container names per daemon, and a name is claimed for the container's entire lifetime — from creation until removal, not until it stops. A container that exited months ago is still a real object in the daemon's state, still has its writable layer on disk, and still owns its name.

That's the whole reason the error is so surprising: docker ps shows nothing, so the name looks free. But docker ps deliberately lists only running containers. The stopped one holding your name is only visible with -a:

docker ps            # running only — the conflicting container is invisible here
docker ps -a         # ALL containers, including exited ones — the name shows up

Internally the name maps to a container ID (the long hash in the error message), which is why the daemon can tell you exactly which container is in the way. You can always act on that ID directly if the name is awkward to type: docker rm -f a1b2c3d4e5f6.

Common mistakes

• Assuming docker stop frees the name. It doesn't — stopping just changes the container's status; the name stays claimed until the container is actually removed.
• Trusting docker ps shows "nothing's using this name." It only lists running containers. The one holding your name is almost always sitting stopped, invisible until you add -a.
• Running docker compose stop, then up, and hitting the same conflict again. stop leaves the containers in place; only docker compose down removes them.
• Manually stopping a container before removing it, out of habit, when docker rm -f already does both in one step.
• Reaching for a broad prune (docker system prune) to solve a single-container conflict, when the specific container is one targeted docker rm -f <name> away.

Verify the fix

docker ps -a --filter "name=myapp"
# no rows → the name is free; docker run will succeed

Debugging checklist

• ✓ docker ps -a --filter "name=<name>" — find the container actually holding the name
• ✓ Decide first: is it disposable, or does it hold state you need?
• ✓ Disposable → docker rm -f <name>; wanted → docker start <name>
• ✓ Want both? docker rename <old> <new> — non-destructive
• ✓ Short-lived container? Add --rm so the name frees itself
• ✓ CI/script? docker rm -f <name> || true before the run
• ✓ Compose? docker compose down (not stop), and reconsider container_name:
• ✓ Remember: docker ps hides stopped containers — always check with -a