Execute a command in a running Docker container

docker exec starts an additional process in an existing running container. It does not replace the main process, but the command can still modify files, application state or a database, so choose its effects deliberately.

docker exec myapp ls -l /app/logs
docker exec -it myapp sh
docker exec -u root -it myapp sh
docker exec -e DEBUG=true myapp python manage.py check

The requested executable must exist in the image. Some images have Bash, some only sh, and distroless images may have neither. -u root selects the container user; it does not bypass a read-only filesystem, dropped capabilities, user-namespace restrictions or other security controls.

Working directories and shell syntax

Use -w when the command needs a specific directory:

docker exec -w /app myapp python manage.py check

For an operation that genuinely needs shell syntax, explicitly run a shell:

docker exec myapp sh -c 'cd /app && python manage.py check'

The single quotes keep this shell expression for the container's shell instead of allowing the host shell to expand it first. Passing a whole expression as the executable name does not make Docker interpret && or pipes. Database migrations use the same mechanism, but they change persistent state and should follow the application's deployment procedure.

Useful diagnostic commands

docker exec myapp ss -ltn
docker exec myapp curl --fail --silent --show-error http://localhost:8080/health
docker exec -it web python manage.py shell
docker exec myapp cat /etc/nginx/nginx.conf

Each example assumes the named application and tool exist. In this context, localhost is the container's own network namespace, unless the container deliberately shares another namespace. If a tool is missing, use a supported debug workflow or a suitable diagnostic image rather than assuming production images contain an operating-system toolbox.

Scripted execution

Omit -t in CI and cron unless a terminal is actually needed. Keep -i only when streaming standard input. A completed exec process reports its exit status, while Docker/transport failures can fail before the program starts; handle both cases.

-e overrides the environment for this new process and its children. It does not edit the main process or persist a new container configuration. Exec starts from the environment configured when the container was created, not from arbitrary changes later made by PID 1.

Use repeatable operations where retries are possible. The exec process lives with the container: it is not automatically relaunched when the container restarts.

FAQ

How is this different from docker run? run creates a new container. exec adds a process to a running one. A one-off run --rm task can provide a clean environment, provided its mounts and other settings are intentional.

What if the container is stopped or paused? Exec requires a running, unpaused container. Inspect its state and logs first. Starting it may launch the real application, which is not always appropriate during diagnosis.

Can I inspect a stopped container without starting it? Copy files with docker cp. A commit followed by a separate run can help in selected investigations, but it excludes mounted volume contents and is not a full running-process checkpoint.

See Docker exec reference, Copying container files, Container commit limitations.