Introduction

Ensuring a Docker container is running is a state-management problem, not just a docker run problem. The correct logic depends on whether the named container already exists and is stopped, or whether it has never been created at all.

Distinguish “Stopped” from “Missing”

docker run creates a new container. docker start starts an existing stopped container. If you do not separate those cases, automation often becomes brittle.

A useful shell pattern is:

1#!/usr/bin/env bash
2set -euo pipefail
3
4name="my-app"
5image="nginx:stable"
6
7if docker ps --format '{{.Names}}' | grep -Fxq "$name"; then
8  echo "Container is already running"
9elif docker ps -a --format '{{.Names}}' | grep -Fxq "$name"; then
10  echo "Starting existing container"
11  docker start "$name"
12else
13  echo "Creating and starting new container"
14  docker run -d --name "$name" -p 8080:80 "$image"
15fi

This covers the three important states:

• already running
• exists but stopped
• does not exist

That is usually the most practical automation answer.

Use docker inspect for Explicit State Checks

If you want a more explicit state query, docker inspect can report the running state directly.

docker inspect -f '{{.State.Running}}' my-app

That prints true or false for an existing container, but it fails if the container name does not exist. So automation still needs an existence check.

Example:

1if docker inspect my-app >/dev/null 2>&1; then
2  if [ "$(docker inspect -f '{{.State.Running}}' my-app)" = "true" ]; then
3    echo "running"
4  else
5    docker start my-app
6  fi
7else
8  docker run -d --name my-app nginx:stable
9fi

This approach is slightly more explicit than parsing docker ps, especially when you care about the precise runtime state.

Use Restart Policies When Automation Should Survive Reboots

If the real goal is “keep this service up,” a restart policy is often more appropriate than repeatedly running your own check script.

1docker run -d \
2  --name my-app \
3  --restart unless-stopped \
4  -p 8080:80 \
5  nginx:stable

Now Docker itself will attempt to bring the container back after daemon restarts or system reboots, depending on the policy. That is often cleaner than cron-based polling scripts.

Common restart policies:

• 'no'
• 'on-failure'
• 'always'
• 'unless-stopped'

Use the policy that matches the operational intent.

Idempotence Matters in Deployment Scripts

The reason people ask this question is usually idempotence. A deployment or bootstrap script should be safe to run repeatedly without creating duplicate containers or failing on already-created state.

That means the script should define:

• how the container is identified
• whether it may be recreated
• whether configuration drift requires docker rm plus a new docker run

If image tags, ports, volumes, or environment variables change, a stopped old container may no longer be the right thing to start. In that case, “start if stopped” is not enough; you may need replacement logic.

Common Pitfalls

• Using docker run every time creates duplicate or conflicting containers instead of reusing the existing one.
• Starting an old stopped container even though the configuration or image changed can leave you running the wrong workload.
• Treating restart policies and one-time startup scripts as interchangeable leads to unclear operational ownership.
• Matching container names loosely instead of exactly can start or inspect the wrong container.
• Ignoring the difference between container existence and container running state makes automation less predictable.

Summary

• Use docker start for an existing stopped container and docker run only when the container does not exist yet.
• Check both existence and running state in automation scripts.
• Use restart policies when the real requirement is service continuity, not one-off startup.
• Think about idempotence and configuration drift, not just process state.
• The right command depends on the container’s lifecycle state, not just on the image name.