logo

Docker up, start, stop, and down are not interchangeable

Two of them flip a switch, two of them create and destroy

Joel Clermont
Joel Clermont
2026-06-11

When working with Docker Compose, have you ever wondered about the difference between docker compose up, start, stop, and down?

As plain English words, "up" and "start" or "stop" and "down" almost seem interchangeable with each other, but they have some important differences as Docker Compose commands.

Here's how I like to think of it: start and stop are a power switch. They turn an existing container on and off, and that's all. The container, its network, and its data all stay exactly where they were.

The key point to remember is that these two commands only work with existing containers.

On the other hand, up and down also include the concept of container existence. up creates your containers from the compose file, along with the network and volumes they need. down tears all of that back down.

It's true that up will also start the container right after creating it, which is part of why these feel so similar. There is some overlap.

The one way I try to keep this straight in my own mind: I just remember "down" means "destroy".

Other than a mounted volume, everything else is removed: the container's internal filesystem and its network.

So unless I want to wipe all that out, I default to docker compose stop.

These two sets of commands also affect how changes to the Docker Compose configuration are applied (or ignored).

start only powers on the container that already exists. It doesn't re-read your docker-compose.yml, and it certainly won't rebuild anything from your Dockerfile. So if you edited either one and ran start, you're still looking at the old container, unchanged.

To apply a change from your docker-compose.yml, you need to run docker compose up. And if you changed the Dockerfile, passing --build to the up command will also rebuild that image.

So what do I actually use in my day-to-day development? I keep things simple and just run docker compose up -d every time, even when the containers already exist. Since up will start an existing container anyway, I don't bother reaching for start separately. And I use stop when I'm done for the day.

As a final side point, Aaron leaves his containers running all the time and thinks I'm weird for stopping them, so your mileage may vary!

The main point, though, is that you probably will use docker compose down very sparingly.

Here to help,

Joel

P.S. Little confusions like this one come up constantly when you're deep in a project. We help each other untangle them every day inside our community.

Toss a coin in the jar if you found this helpful.
Want a tip like this in your inbox every weekday? Sign up below 👇🏼
email
No spam. Only real-world advice.