What is the difference between ENTRYPOINT and CMD?

Question

Accepted Answer

**ENTRYPOINT** and **CMD** both define what runs when a container starts, but they serve different roles and interact in specific ways. Understanding the difference (and the two forms — exec vs shell) is important for writing Dockerfiles that behave correctly.

## CMD — the default command (overridable)

```dockerfile
CMD ["node", "server.js"]
# → the DEFAULT command when the container starts
# → but it's REPLACED if you pass a command at run time:
#   docker run myapp echo hello   → runs "echo hello" INSTEAD of node server.js
```

`CMD` provides the **default command**, which is **fully overridden** by any command given on `docker run`.

## ENTRYPOINT — the fixed executable

```dockerfile
ENTRYPOINT ["node", "server.js"]
# → ALWAYS runs; run-time arguments are APPENDED (not replacing it):
#   docker run myapp --port 8080   → runs "node server.js --port 8080"
# → makes the container behave like a specific executable
```

`ENTRYPOINT` sets a **fixed executable** that always runs; run-time arguments are **appended** as its arguments rather than replacing it.

## Using them together (the common pattern)

```dockerfile
ENTRYPOINT ["node", "server.js"]   # the fixed command
CMD ["--port", "3000"]              # DEFAULT arguments (overridable)
# docker run myapp                  → node server.js --port 3000 (defaults)
# docker run myapp --port 8080      → node server.js --port 8080 (CMD overridden)
→ ENTRYPOINT = the command; CMD = default arguments you can override. A clean pattern.
```

## Exec form vs shell form

```text
EXEC form  → CMD ["node", "server.js"]  (JSON array) — PREFERRED:
  runs the executable DIRECTLY (PID 1) → receives signals (SIGTERM) → graceful shutdown
SHELL form → CMD node server.js  → runs via /bin/sh -c → the shell is PID 1,
  the app may NOT receive signals properly (shutdown issues) → avoid for the main process
```

## Why it matters

Understanding the difference between ENTRYPOINT and CMD is important for **writing Dockerfiles that behave correctly**, so it's valuable practical knowledge and a commonly-confused topic.

The distinction in behavior matters: **CMD** provides a default command that is **fully overridden** by any command passed to `docker run`, while **ENTRYPOINT** sets a fixed executable that always runs with run-time arguments **appended** to it — different behaviors that affect how the container responds to run-time arguments.

Understanding the **common pattern of using them together** (`ENTRYPOINT` as the command and `CMD` as overridable default arguments) is a clean, idiomatic approach that makes containers behave like configurable executables — a widely-used technique worth knowing.

Critically, understanding the **exec form vs shell form** is important for correctness: the **exec form** (JSON array, e.g. `CMD ["node", "server.js"]`) is preferred because it runs the executable **directly as PID 1**, so it **receives signals like SIGTERM** properly, enabling **graceful shutdown** — whereas the **shell form** (`CMD node server.js`) runs via a shell that becomes PID 1, often causing the application to **not receive shutdown signals correctly** (leading to ungraceful termination, lost in-flight work, or slow stops).

This signal-handling/graceful-shutdown issue is a real, subtle problem that the exec form avoids.

Since defining what runs when a container starts is fundamental to every Dockerfile, and since the ENTRYPOINT/CMD distinction (and the exec-vs-shell-form signal-handling concern) directly affects container behavior and correctness (argument handling, graceful shutdown), understanding ENTRYPOINT vs CMD — their roles, how they combine, and the important exec-form-for-signals practice — is valuable, practically-relevant Docker knowledge, a commonly-misunderstood topic where understanding the differences prevents real behavioral and shutdown bugs.