What is Entrypoint vs Cmd
ENTRYPOINT and CMD are Dockerfile instructions that define what a container runs when it starts. They serve different roles:
- ENTRYPOINT — the executable that always runs. It cannot be overridden by command-line arguments (unless you use
--entrypoint). - CMD — default arguments passed to the entrypoint. They are overridden when you provide arguments to
docker run.
How it works
When both are set, the container runs ENTRYPOINT + CMD as a combined command:
ENTRYPOINT ["nginx"]
CMD ["-g", "daemon off;"]
# Runs: nginx -g "daemon off;"
Running docker run myimage -c /custom.conf overrides CMD but keeps ENTRYPOINT, resulting in: nginx -c /custom.conf.
When only CMD is set (no ENTRYPOINT), CMD is the full command. Running docker run myimage /bin/sh replaces CMD entirely.
Exec form (["nginx", "-g", "daemon off;"]) runs the process directly as PID 1. Shell form (nginx -g "daemon off;") wraps the command in /bin/sh -c, which means the shell is PID 1 and the application is a child process. Exec form is preferred because PID 1 receives signals directly — docker stop sends SIGTERM to PID 1, and if that is a shell, the application may not receive it.
Why it matters
Misunderstanding ENTRYPOINT vs CMD causes containers that ignore signals (shell form PID 1 problem), containers that cannot be parameterized (everything hardcoded in ENTRYPOINT), or containers where docker run image args does not behave as expected. The exec form + ENTRYPOINT/CMD split is the standard pattern for production containers.
See How Container Images Work for Dockerfile best practices.