Fix: Error response from daemon: Conflict. The container name is already in use

Updated 2026-03-06

The Error

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.

You’ll also see this in Docker Compose as:

Creating my-app ... error
ERROR: for my-app  Cannot create container for service app: 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.

The Fix

  1. Remove the existing container and re-run. This is the fastest fix.
docker rm my-app
docker run --name my-app -d my-image:latest

If the container is still running, stop it first:

docker stop my-app && docker rm my-app
docker run --name my-app -d my-image:latest

Or combine stop + remove in one command with the force flag:

docker rm -f my-app
docker run --name my-app -d my-image:latest
  1. Use --rm to auto-clean containers when they exit. This prevents the conflict from ever happening again for short-lived containers:
docker run --rm --name my-app my-image:latest

The --rm flag tells Docker to automatically remove the container (and its writable layer) when the process exits. Ideal for dev servers, test runs, and one-off scripts.

  1. For Docker Compose projects, use docker compose up with the --force-recreate flag:
docker compose up -d --force-recreate

This tears down existing containers for services defined in your compose file and creates fresh ones. If you want to also rebuild images:

docker compose up -d --force-recreate --build
  1. Clean up all stopped containers system-wide if you’ve accumulated many stale ones:
docker container prune

This removes every stopped container. Docker will prompt for confirmation. To skip the prompt:

docker container prune -f
  1. For CI/CD pipelines, always force-remove before creating. This makes your pipeline idempotent:
#!/bin/bash
# deploy.sh — idempotent container deployment
CONTAINER_NAME="my-app"

docker rm -f "$CONTAINER_NAME" 2>/dev/null || true
docker run -d \
  --name "$CONTAINER_NAME" \
  --restart unless-stopped \
  -p 8080:8080 \
  my-image:latest

The 2>/dev/null || true suppresses the “no such container” error if it doesn’t exist yet.

Why This Happens

Docker container names are unique per host. When you run docker run --name my-app, Docker registers that name. If the container stops — whether it crashed, you Ctrl+C’d it, or the process exited — the stopped container still exists. It’s not running, but its filesystem layer, logs, and metadata remain. Docker keeps it around so you can inspect logs, restart it, or copy files out.

The next time you run docker run --name my-app, Docker refuses because the name is taken. It doesn’t matter that the old container is stopped. The name reservation persists until the container is explicitly removed with docker rm.

This catches most people during development. You run a container, it crashes or you stop it, you tweak something and try again — boom, name conflict. It’s especially common with Docker Compose, where service names automatically map to container names. If a previous docker compose up didn’t shut down cleanly (power loss, force-quit terminal, system sleep), the old containers linger.

The design is intentional. Docker prioritizes data safety over convenience. A stopped container might hold important logs or data in its writable layer. Auto-removing it could mean losing the only record of why a process crashed. That said, for most development and CI workflows, you want the opposite behavior — auto-cleanup — which is what --rm provides.

Edge Cases

Container exists but docker ps doesn’t show it. By default, docker ps only shows running containers. Stopped containers are hidden. Use the -a flag:

docker ps -a --filter name=my-app

This shows all containers (running and stopped) matching the name. The STATUS column tells you if it’s Exited, Created, or Up.

Ghost containers after Docker daemon crash. If Docker itself crashed or the machine lost power, you might end up with containers in a Created or Dead state that can’t be stopped normally:

docker rm -f my-app

If that fails too:

docker system prune -f

In extreme cases, restarting the Docker daemon resolves orphaned state:

sudo systemctl restart docker

Docker Compose orphan containers. If you rename a service in your docker-compose.yml, the old container keeps the old name. Docker Compose won’t clean it up automatically. Remove orphans explicitly:

docker compose up -d --remove-orphans

Name conflicts in Docker Compose with container_name. If you explicitly set container_name in your compose file:

services:
  app:
    image: my-image:latest
    container_name: my-app

And another compose project also uses container_name: my-app, they’ll conflict. Docker Compose’s default naming (projectname-service-1) avoids this. Only use explicit container_name when you have a specific reason.

Competing deploy scripts. In CI/CD, if two pipeline runs overlap, both try to create the same container name simultaneously. One succeeds, the other hits the conflict. Fix this by using the force-remove pattern from Fix #5, or use unique names with build IDs:

docker run --name "my-app-${BUILD_ID}" -d my-image:latest

Then clean up old containers by label or age:

# Remove containers older than 24 hours
docker container prune --filter "until=24h" -f

Docker Desktop on Mac/Windows. Docker Desktop runs containers inside a Linux VM. If you uninstall and reinstall Docker Desktop without removing the VM data, old container state persists. Reset Docker Desktop to factory defaults from the troubleshooting menu to start clean.

Named containers vs anonymous containers. If you skip the --name flag entirely, Docker assigns a random name (like sleepy_darwin). You’ll never hit name conflicts, but you lose the ability to reference containers predictably in scripts. The trade-off is worth it for throwaway dev containers but not for anything you need to manage programmatically.

See Also