Fixing 'No container found for _1' in docker compose exec

What this error means

The message "No container found for <service>_1" appears when docker compose exec cannot locate a running container for the service you named. Common causes:

• The service is not running (stopped or never started).
• You started containers under a different project name, directory, or compose file set.
• Profiles or scaling changed which containers exist.
• You mixed docker compose (v2) and docker-compose (v1) or different flags.

exec only works against running containers created by the same Compose project context.

Minimal working example

Compose file:

# docker-compose.yml
services:
  app:
    image: alpine:3.19
    command: ["sleep", "infinity"]

Start and exec:

# Start in detached mode
docker compose up -d

# Should work: opens a shell in the running container
docker compose exec app sh

# Reproduce the error: stop the service
docker compose stop app

# Now exec fails
docker compose exec app sh
# -> Error: No container found for app_1

Fix: start the service again:

docker compose up -d app
docker compose exec app sh

Quickstart: fix in 30 seconds

• Ensure the service is running: docker compose ps then docker compose up -d <service>.
• Run from the same directory and files used to start: cd <project-dir> and pass the same -f files and -p if used.
• If scaled: docker compose exec --index 1 <service> sh.
• If profiles were used: add --profile <name> or set COMPOSE_PROFILES.
• If the container exits immediately, use docker compose run --rm <service> sh or adjust the service command to stay running.

Step-by-step fixes

1. Verify the service is running

docker compose ps
# or restrict to running
docker compose ps --status running

• If your service is not listed as running, start it:

docker compose up -d <service>

1. Make sure you are in the correct project context

• Default project name is the directory name. If you started in a different directory, exec won’t find the containers.
• Use the same compose files and project name you used with up:

# If you used multiple files previously, pass the same set and order
docker compose -f docker-compose.yml -f docker-compose.override.yml exec <service> sh

# If you used a custom project name earlier
docker compose -p myproj exec <service> sh

• Not sure which project your containers belong to? Inspect labels:

docker ps --filter label=com.docker.compose.service=<service> \
          --format '{{.Names}} {{.Label "com.docker.compose.project"}}'

1. Align Compose CLI versions

• If you started with docker-compose up (v1), prefer using the same CLI for exec. Conversely, if you used docker compose (v2), keep using it.
• Check your version:

docker compose version
# and/or
docker-compose version

1. Handle profiles and conditional services

• If your service is gated by a profile, it won’t exist unless the profile is enabled:

# Enable profile when starting or exec-ing
COMPOSE_PROFILES=dev docker compose up -d
COMPOSE_PROFILES=dev docker compose exec <service> sh

# or
docker compose --profile dev up -d
docker compose --profile dev exec <service> sh

1. Address scaling and replicas

• If you scaled a service, there may be multiple containers. Pick one by index:

docker compose up -d --scale web=3
# Exec into the first replica
docker compose exec --index 1 web sh
# Or the third replica
docker compose exec --index 3 web sh

1. When the container exits immediately

• exec requires a running container. If the service command finishes quickly, either:
  • Keep it running (e.g., use sleep infinity, a long-running process, or your app server), or
  • Use a one-off container:

# Run an ad-hoc shell without needing the service to be running
docker compose run --rm --no-deps <service> sh

1. Match the exact compose files used previously

• Starting with different -f files creates a different project definition; exec won’t target the earlier containers.
• Always pass the same files, in the same order, for up, ps, and exec.

1. Clean up orphans and stale state

# Remove stopped containers and dangling project state
docker compose rm -f

# Recreate containers to ensure labels and names are consistent
docker compose up -d --force-recreate

Common pitfalls

• Running exec before up -d creates any containers.
• Changing directories between up and exec (thus changing the default project name).
• Forgetting -p <name> on exec when it was used on up.
• Using a different set or order of -f compose files between runs.
• Expecting exec to work with services that exit immediately.
• Scaling a service but forgetting to target a specific replica with --index.
• Defining container_name: and then attempting to scale the service (scaling is incompatible with a fixed container_name).

Performance notes

• docker compose exec attaches to an existing running container; it’s fast and does not create new containers.
• docker compose run starts a new one-off container; it’s slower and consumes extra resources until it exits.
• Keeping a lightweight long-running process (e.g., your app server or sleep infinity in dev) avoids repeated container startups.
• Frequent exec is fine; the overhead is mostly an interactive TTY attach.

Tiny FAQ

• Why does Compose mention <service>_1?

  • Compose indexes replicas. The first instance is index 1. Names differ between versions, but the concept is the same.

• How do I exec into a specific replica?

  • Use docker compose exec --index N <service> <cmd>.

• Can I exec into a stopped container?

  • No. Start it with docker compose up -d <service> or use docker compose run for a one-off container.

• I used a different directory or project name. How do I recover?

  • Use the same directory or add -p <project> to ps/up/exec to match the original project.

• Does container_name: affect this?

  • It prevents scaling and fixes the container name, but exec still targets the service via labels. Mismatched scaling or differing project context can still cause the error.