Resuming Existing Containers
The docker start command is specifically designed to reactivate containers that have been previously created but are currently in a stopped state. When this command is executed, it locates the referenced container by its ID or name and initializes the main process without reconstructing the container's filesystem or metadata. This operation is lightweight compared to a fresh creation.
# Reactivate a stopped container named 'legacy_db_instance'
docker start legacy_db_instance
# Verify the status has changed to 'up'
docker ps -a --filter "name=legacy_db_instance"
Creating and Initializing New Containers
Conversely, the docker run command combines the functionality of creating a new container from an image and starting it immediately. It initiates the container lifecycle by allocating a writable filesystem layer, setting up networking configurations based on the provided flags, and then executing the defined command. If the specified image is not present locally, the daemon will pull it from a registry first.
# Create a new container from 'nginx:alpine' and run it in detached mode
docker run -d --name web_frontend -p 8080:80 nginx:alpine
# Run an interactive container that removes itself upon exit
docker run --rm -it ubuntu:latest /bin/bash
Key Differences at a Glance
The following table outlines the technical distinctions between the two commands to clarify their specific use cases.
| Aspect | docker start |
docker run |
|---|---|---|
| Operational Scope | Resumes execution of an existing, stopped container. | Generates a new container instance from an image. |
| Object State | Target container must already exist on the host. | Creates a new object ID for every execution. |
| Resource Overhead | Minimal, as the environment is pre-configured. | Higher, involves image pull (if needed) and setup. |
| Configuration Persistence | Uses original configuration from creation time. | Allows applying new configuration flags via CLI. |