No Restart Policy

The "no" restart policy, Docker's default, means a stopped container is never automatically restarted, regardless of whether it exited cleanly, crashed, or was deliberately stopped — appropriate for one-off tasks and containers whose stopped state should never be automatically reversed.

The Default Behavior Without an Explicit Policy

Unless a restart policy is explicitly specified, a container uses no, meaning it simply remains stopped once its main process exits, for any reason.

docker run -d myapp:1.0

This is equivalent to explicitly specifying --restart=no, since it is the implicit default.

Why This Default Is Appropriate for Many Containers

For one-off tasks, test runs, and many development scenarios, automatically restarting a stopped container would be unexpected and potentially confusing — the no policy's hands-off default behavior matches the expectation that a container, once stopped, simply stays stopped.

docker run --rm myapp:1.0 run-tests.sh

A test container exiting (whether the tests passed or failed) should not be automatically restarted — this default behavior is exactly what's wanted here.

Why a Service Container Usually Needs an Explicit Policy Instead

A long-running service container, in contrast, typically should not use the default no policy, since an unexpected crash would then leave it stopped indefinitely without any automatic recovery.

docker run -d --restart=unless-stopped myapp:1.0

Explicitly choosing a more resilient policy is necessary for this kind of container, since relying on the default would leave it vulnerable to remaining stopped after any unexpected crash.

Confirming a Container Is Using the Default Policy

A container's restart policy can always be confirmed directly, clarifying whether it is genuinely using the default no behavior or some other explicitly configured policy.

docker inspect myapp --format '{{.HostConfig.RestartPolicy.Name}}'

Why Understanding the no Policy Matters

Recognizing that no is the default, and deliberately choosing whether this hands-off behavior is actually appropriate for a given container, prevents the common mistake of unintentionally leaving a service container without any automatic recovery from unexpected crashes.