Two commands, one shared idea: the container itself is never thrown away.

A Docker container, once created, continues to exist as an object on your machine even after the program running inside it finishes or is told to halt. Stopping a container means telling the main process running inside it to shut down, while the container itself — its filesystem, its settings, its identity — remains intact, just inactive. Starting a container again means telling that same, still-existing container to boot its main process back up, picking up exactly where its own internal filesystem left off.

This distinction matters enormously in practice. A container that’s been stopped can be started again with all of its own internal changes — any files it wrote to its own filesystem, any settings it changed — still present, because none of that was deleted. This is fundamentally different from removing a container, which does erase that container’s own filesystem for good, or from creating a brand-new container from an image, which always starts from a clean, unmodified state.

Stopping isn’t an instant, brutal shutdown by default — it’s a polite request first.

When a stop is requested, Docker doesn’t immediately kill the process running inside the container. Instead, it sends a polite shutdown signal to that main process, giving it a chance to finish what it’s doing gracefully — closing open files properly, finishing an in-progress database write, letting active requests complete, and generally cleaning up before exiting on its own terms.

sequenceDiagram
    participant User as You
    participant Docker as Docker Engine
    participant Process as Main Process in Container

    User->>Docker: Request to stop the container
    Docker->>Process: Send graceful shutdown signal
    Note over Process: Process finishes current work, cleans up
    Process-->>Docker: Process exits on its own
    Docker->>Docker: Container marked as "stopped"
        

Only if the process doesn’t exit on its own within a set waiting period does Docker escalate to a much more forceful shutdown, which simply terminates the process immediately, without giving it any further chance to finish or clean up. That forceful escalation and its timing are covered in detail in the next chapter, since understanding it is essential to avoiding data problems.

Docker won’t wait forever for a process to shut itself down politely.

The polite shutdown signal described in Chapter 2 comes with a countdown attached, commonly ten seconds by default. If the main process inside the container hasn’t exited on its own by the time that countdown reaches zero, Docker gives up waiting and sends a second, much blunter signal — one the process cannot ignore, intercept, or delay in any way. This second signal terminates the process immediately, mid-task if necessary, with no further opportunity to finish cleaning up.

The forceful shutdown option also exists as its own, separate, deliberate action for situations where you genuinely want a container halted immediately without any grace period at all — useful for a container that’s clearly stuck or unresponsive and isn’t going to shut down cleanly no matter how long you wait.

Starting a stopped container is a much simpler operation than creating a new one from scratch.

Starting an already-existing, stopped container skips nearly all the setup work involved in creating a brand-new one. There’s no pulling an image, no building a fresh filesystem layer, and no reapplying the original configuration choices — all of that already happened once, back when the container was first created, and none of it needs to happen again. Docker simply reactivates the container’s existing filesystem and launches its main process once more.

flowchart TD
    A["Container exists, currently stopped"] --> B["Start requested"]
    B --> C["Docker reactivates the container's existing filesystem"]
    C --> D["Main process launched again"]
    D --> E["Container is now running, with its prior internal data intact"]
    style A fill:#fafafa,stroke:#171717
    style E fill:#fef2f2,stroke:#dc2626
        

This is precisely why starting a previously stopped container is typically much faster than creating and running a brand-new one — the heavy lifting of image pulling and filesystem preparation was already completed the first time the container was created, and starting simply resumes from that existing state.

This is one of the most common points of confusion for people new to Docker.

Stopping a container does not erase anything written to that container’s own internal filesystem. If a process inside the container wrote a file to its own disk space before being stopped, that file is still there once the container is started again, because stopping never touches the filesystem itself — it only halts the running process.

What is lost, however, is anything that only ever existed in the process’s active memory and was never written to disk — an in-progress calculation, an open network connection, data cached purely in memory. Since the process itself is genuinely terminated during a stop, anything that existed only inside that live, running process disappears along with it, exactly as it would if you shut down any ordinary running program on your computer.

Docker offers several related but distinctly different actions, and mixing them up leads to confusion.

The distinction between “stop” and “pause” is especially worth remembering. Stopping genuinely terminates the process, meaning anything held only in that process’s active memory is lost, as explained in Chapter 5. Pausing, on the other hand, leaves the process entirely intact in memory — frozen rather than terminated — so resuming a paused container picks up truly instantly, with absolutely nothing lost, because nothing was ever actually shut down in the first place.

A container is always in exactly one state at a time, and stop and start move it between them.

Every Docker container has a status describing what it’s currently doing. Understanding these states makes it much easier to predict exactly what stop and start will do in any given situation.

A container can cycle between the running and stopped states indefinitely, any number of times, without ever needing to be removed and recreated. Each cycle simply toggles whether the main process is active, while the container’s own identity and filesystem persist across every transition.

Stopping and starting containers is a routine, everyday action across almost every kind of Docker workflow.

Just as important as knowing what these actions do is knowing what they deliberately don’t do.

A short checklist for handling stops and starts without losing data or wasting time.

Stopping and starting containers is a routine operational action across nearly every kind of team and industry.

No. As explained in Chapter 1, stopping only halts the running process; the container and its own filesystem remain fully intact and can be started again at any time.

No. As covered in Chapter 4, starting an existing container reuses everything that was already set up when it was first created — no image pulling or rebuilding is involved.

Anything that existed only in the running process’s active memory, rather than written to disk, is lost when the process is terminated, as discussed in Chapter 5 — this is true of any program, not just containers.

As explained in Chapter 6, stopping genuinely terminates the process, while pausing freezes it in place without shutting it down at all, allowing an instant, lossless resume.

No. As covered in Chapters 9 and 10, starting a stopped container always reuses its original configuration; applying new settings requires creating a new container.

It’s best avoided as routine practice. As the anti-pattern in Chapter 10 explains, a forceful kill skips the graceful shutdown a database needs to safely finish writing data to disk.

Stopping and starting a container is Docker’s version of pausing and resuming, not deleting and rebuilding. A stop politely asks the container’s main process to shut down, escalating to a forceful termination only if it doesn’t exit within a set grace period, while the container’s own filesystem and identity remain fully intact throughout. Starting reactivates that same existing container, skipping the heavier setup work involved in creating a brand-new one. Understanding this distinction — and how it differs from killing, pausing, restarting, and removing — is one of the most practical, everyday pieces of Docker knowledge there is.