Introduction

You can start a Docker container without typing a command at docker run time if the image already defines what should execute. Docker gets that startup behavior from the image’s CMD, ENTRYPOINT, or a combination of both.

How Docker decides what to run

When you run:

docker run nginx:alpine

Docker checks the image metadata. If the image defines a default process, Docker starts it automatically.

In practice, the rules are:

• if the image has ENTRYPOINT, Docker keeps it unless you override it
• if the image has CMD, Docker uses it when you do not supply another command
• if both exist, CMD usually provides default arguments to ENTRYPOINT

That is why many official images start successfully with no extra command from you.

Seeing the defaults before you run

It helps to inspect the image rather than guessing:

docker image inspect nginx:alpine \
  --format '{{json .Config.Entrypoint}} {{json .Config.Cmd}}'

This tells you exactly what Docker will use when no command is supplied.

Example with an image-defined CMD

A simple custom image might look like this:

1FROM python:3.12-slim
2WORKDIR /app
3COPY app.py .
4CMD ["python", "app.py"]

Build and run it:

docker build -t hello-app .
docker run --rm hello-app

Even though docker run contains no command, the container still starts because the image already defined one.

Overriding the default when needed

Image defaults are convenient, not mandatory. If you provide a command at runtime, Docker usually replaces CMD:

docker run --rm hello-app python -c "print('override')"

If the image also defines ENTRYPOINT, that entrypoint may still stay in place unless you explicitly replace it:

docker run --rm --entrypoint /bin/sh hello-app -c "echo debug shell"

This is useful when the default startup process fails and you need to inspect the container manually.

What happens when no default exists

If an image has neither CMD nor ENTRYPOINT, Docker has nothing to execute and the run will fail or exit immediately depending on the situation.

That is why good image design matters. A runnable image should usually make the no-command case sensible.

docker create and docker start

You can also separate creation from execution:

docker create --name myapp hello-app
docker start -a myapp

Again, no explicit command is necessary because the container inherits the image defaults that were recorded at creation time.

Common Pitfalls

One common mistake is expecting a container to stay alive when its default command is a short-lived process. Containers stay up only while the main process keeps running.

Another issue is confusing CMD and ENTRYPOINT. Runtime arguments replace CMD more easily, but ENTRYPOINT is designed to remain the main executable unless you override it deliberately.

People also assume all images are meant to be run directly. Some are base images intended to be extended, and their defaults may be minimal or absent.

Finally, inspect the image before debugging blindly. Seeing the configured Cmd and Entrypoint usually explains startup behavior faster than repeated trial and error.

It also helps you distinguish between a container problem and an image-design problem, which are not always the same thing.

Summary

• You can run a Docker image without an explicit command when the image defines a default process.
• Docker uses CMD, ENTRYPOINT, or both to determine startup behavior.
• 'docker image inspect shows the actual configured defaults.'
• Runtime commands usually replace CMD, while ENTRYPOINT stays unless overridden.
• A container only stays running while its main process stays alive.