---
description: Frequently asked questions for Docker Compose
keywords: documentation, docs, docker, compose, faq, docker compose vs docker-compose
title: Compose FAQs
linkTitle: FAQs
weight: 10
tags: [FAQ]
aliases:
- /compose/faq/
---
### What is the difference between `docker compose` and `docker-compose`
Version one of the Docker Compose command-line binary was first released in 2014. It was written in Python, and is invoked with `docker-compose`. Typically, Compose v1 projects include a top-level version element in the `compose.yaml` file, with values ranging from 2.0 to 3.8, which refer to the specific file formats.
Version two of the Docker Compose command-line binary was announced in 2020, is written in Go, and is invoked with `docker compose`. Compose v2 ignores the version top-level element in the compose.yaml file.
For further information, see [History and development of Compose](/manuals/compose/intro/history.md).
### What's the difference between `up`, `run`, and `start`?
Typically, you want `docker compose up`. Use `up` to start or restart all the
services defined in a `compose.yaml`. In the default "attached"
mode, you see all the logs from all the containers. In "detached" mode (`-d`),
Compose exits after starting the containers, but the containers continue to run
in the background.
The `docker compose run` command is for running "one-off" or "adhoc" tasks. It
requires the service name you want to run and only starts containers for services
that the running service depends on. Use `run` to run tests or perform
an administrative task such as removing or adding data to a data volume
container. The `run` command acts like `docker run -ti` in that it opens an
interactive terminal to the container and returns an exit status matching the
exit status of the process in the container.
The `docker compose start` command is useful only to restart containers
that were previously created but were stopped. It never creates new
containers.
### Why do my services take 10 seconds to recreate or stop?
The `docker compose stop` command attempts to stop a container by sending a `SIGTERM`. It then waits
for a [default timeout of 10 seconds](/reference/cli/docker/compose/stop.md). After the timeout,
a `SIGKILL` is sent to the container to forcefully kill it. If you
are waiting for this timeout, it means that your containers aren't shutting down
when they receive the `SIGTERM` signal.
There has already been a lot written about this problem of
[processes handling signals](https://medium.com/@gchudnov/trapping-signals-in-docker-containers-7a57fdda7d86)