Container Lifecycle: From Create to Remove

WHY IT EXISTS To provide predictable control over application instances. Unlike a simple process, a container bundles its environment. Managing its lifecycle—from a clean start to a graceful shutdown and cleanup—is crucial for reliable, reproducible deployments, especially at scale.

THE MENTAL MODEL A container is like a disposable appliance with an on/off switch. You can create it (unbox it), run it (plug it in), stop it (unplug it), and remove it (throw it away). A stopped appliance still exists on your shelf, holding its state. A removed one is gone for good. Its internal data is lost unless you saved it to external storage (a volume).

HOW IT WORKS The lifecycle is a series of state transitions managed by commands. docker create prepares the container but doesn't start it. docker run is a shortcut that both creates and starts. docker start moves a stopped container to a running state. docker stop sends a graceful shutdown signal (SIGTERM), then waits before forcing a stop (SIGKILL). docker kill sends SIGKILL immediately. docker pause freezes all processes inside. Finally, docker rm deletes a stopped container and its non-volume data.

WHEN TO USE IT You manage the lifecycle constantly. Use docker run for new containers. Use docker stop and docker start to temporarily halt and resume services without losing their state, for example during maintenance. Use docker rm for cleanup to avoid accumulating stopped containers that consume disk space. Orchestrators like Kubernetes manage this lifecycle automatically to maintain a desired state.

WHEN NOT TO USE IT Don't rely on a container's internal, non-volume storage for any data you want to keep. The lifecycle is designed to be ephemeral. Once a container is removed (rm), any data written to its filesystem that isn't on a mounted volume is gone forever. This is a core feature, not a bug.

ONE CANONICAL EXAMPLE A web server in a container needs a configuration update. The lifecycle allows for a controlled process: first, docker stop my_web_server to gracefully stop it. Second, you make your changes. Third, docker start my_web_server brings the same container instance back online. If you had used docker rm, you would have lost any logs or state within that specific container instance and would need to create a new one.