docker compose stopとdownの違いを図解——どちらを使うべきか

docker compose stop と docker compose down は、どちらもコンテナを止めるコマンドですが、止め方が異なります。よく迷うのでまとめます。

注: Docker Compose V1 では docker-compose（ハイフンあり）と書いていましたが、現在の標準は V2 の docker compose（スペース区切り）です。V1 は2023年7月にサポート終了しています。

違いを一言で

一番の違いは「コンテナを残すか、消すか」です。stop は止めるだけ、down は止めて片付けるところまでやります。

docker compose stop

docker compose stop

コンテナを停止しますが、削除はしません。停止したコンテナは docker compose start で再起動できます。データはコンテナ内に保持されます。

いつ使う: 一時的に止めて、後でまた起動したいとき。

docker compose down

docker compose down

コンテナを停止し、コンテナとネットワークを削除します。ボリュームはデフォルトで残ります。

いつ使う: 環境をクリーンにリセットしたいとき、または docker compose up で作った環境を完全に片付けたいとき。

-v でボリュームも消す（データ消失に注意）

down はデフォルトではボリュームを残します。データベースのデータなどはボリュームに保存されているので、通常の down ではデータは消えません。

ボリュームも含めて完全に削除するには -v（--volumes）オプションを使います。

docker compose down -v  # ボリュームも削除

ここで消えるのは Compose ファイルで定義した名前付きボリュームと匿名ボリュームです。docker compose 削除 でデータごとまっさらにしたいときはこれを使いますが、PostgreSQL や MySQL のデータも一緒に消えるので、消したくないデータがないかを確認してから実行してください。

ネットワークはどうなる

docker compose up を実行すると、プロジェクト用のネットワークが自動で作られます。

• docker compose stop … ネットワークは残る
• docker compose down … プロジェクト用のネットワークも削除される

stop を繰り返してもネットワークは残り続けるので、ネットワーク定義を変更したのに反映されない、というときは一度 down してから up し直すと作り直されます。

stop / down / up / restart / kill / rm 一覧

stop と down の周辺にある、よく使うコマンドの位置づけも合わせて整理しておきます。

restart は止めてすぐ起動し直すだけなのでコンテナは残ります。kill は stop がうまく効かないときに強制的に止める用で、こちらもコンテナ自体は残ります。コンテナを消すのは down と rm だけ、と覚えておくと迷いません。

よくある間違い・FAQ

Q. down を打つとデータベースのデータも消えますか？ A. 通常の docker compose down では消えません。データはボリュームに残ります。消えるのは -v を付けたときだけです。

Q. 開発中はどちらを使えばいいですか？ A. 普段の停止は stop（または restart）で十分です。down は環境を作り直したいときだけで構いません。

Q. down -v を打ったら DB が初期化されてしまいました。 A. -v は名前付きボリュームごと削除します。データを残したいときは -v を付けず、ただの down を使ってください。

まとめ

• 再起動前提の一時停止 → docker compose stop
• 環境ごとリセット → docker compose down
• データも含めて完全リセット → docker compose down -v（データ消失に注意）

開発中は stop を使い回し、CI/CDや環境の作り直しには down を使うのが基本的な使い分けです。