CMD vs
ENTRYPOINT
The One Docker Decision That Quietly Breaks Production
Docker looks simple.
Too simple.
You write a Dockerfile.
You build the image.
You run the container.
And then—without drama, without logs, without apology—the container exits.
No error.
Just silence.
Operational Contract
Somewhere between elegance and assumption lies a small decision most engineers rush through:
CMD or ENTRYPOINT?
This is not a syntax debate. This is an operational contract.
The illusion Docker sells us
At first glance, Docker feels forgiving.
Looks harmless. Reads well. Works locally.
But Docker is not a VM.
It does not babysit processes.
It does not keep things alive out of kindness.
Core Principle
Docker cares about one thing only: Is PID 1 still running?
Everything else is sentiment.
CMD: the default suggestion
CMD is Docker’s polite recommendation.
“If the user doesn’t tell me what to run, run this.”
CMD can be overridden easily.
It is optional.
It is flexible by design.
That flexibility is powerful—and dangerous in production.
ENTRYPOINT: the contract
ENTRYPOINT is not a suggestion. It’s a statement of identity.
“This image exists to run this.”
ENTRYPOINT defines what runs.
CMD defines how it runs.
This is the grown-up pattern.
This is how production images behave.
Process Management
PID 1
The real villain
Foreground is life.
Background is death.
Inside a container, the first process is PID 1. If PID 1 exits, the container stops.
Why CMD causes silent failures
Most Docker issues are process management misunderstandings.
CMD allows accidental overrides.
ENTRYPOINT prevents identity drift.
/
ENTRYPOINT is governance.
The adult pattern: CMD + ENTRYPOINT together
ENTRYPOINT defines the executable.
CMD defines default arguments.
Predictable.
Production-safe.
Decision framework
CMD
ENTRYPOINT
ENTRYPOINT
CMD