<p>There are a few features of <code>docker-compose</code> that are not implemented in <code>docker stack deploy</code> and vice versa.</p>

<p>With <code>docker-compose</code>, you can run privileged containers and change capabilities which is not supported with swarm services yet. You can also run a container that is designed to exit, e.g. a batch job, more intuitively in docker-compose than in swarm mode. If your containers are designed for sysadmin tasks, this may make more sense.</p>

<p>With <code>docker stack deploy</code>, you get access to secrets and configs, along with replication settings, configuration of rolling updates, ingress networking with the routing mesh, and various other swarm mode features. If your containers are designed for highly available microservices, this makes more sense.</p>

<p>Both of these use the same docker-compose.yml definition file (with version 3 required for swarm mode). That makes moving between the two fairly easy. There are also projects like <a href="https://github.com/docker/compose-on-kubernetes" rel="noreferrer">compose-on-kubernetes</a> and <a href="https://github.com/kubernetes/kompose" rel="noreferrer">kompose</a> that make the transition to kubernetes with the same stack definitions easy.</p>

CC BY-SA 4.0
2019-02-01T21:51:36.130Z
Thanks, @BMitch. Since I asked my question, I experimented a little bit more with `docker stack`. It is very seducing, but it requires some understanding of the basic swarm concepts and has a more complicated setup (esp. since it doesn't build image and needs images to be stored in a repository). Given my actual requirements are to provide a gentle introduction to Docker, I will certainly stick with `docker-compose` with my students. Especially since I didn't find any source corroborating a potential deprecation of that tool in short- to mid-term.
Sylvain Leroux
CC BY-SA 4.0
2019-02-01T20:57:10.730Z
2019-02-01T20:57:10.730Z
BMitch
<p>According to <a href="https://vsupalov.com/difference-docker-compose-and-docker-stack/" rel="nofollow noreferrer">the August 2017 article</a> the core functionalities of <code>docker-compose</code> were integrated into the new <code>docker stack</code> command. At the end of the article, the author also assumes <code>docker-compose</code> will soon to be deprecated. The <a href="https://docs.docker.com/engine/reference/commandline/stack_deploy/" rel="nofollow noreferrer"><code>docker stack deploy</code></a> documentation is currently pretty sparse. </p>

<p>The article is six months old now. So, is <code>docker stack</code> the way to go, or is there still some advantage in using <code>docker-compose</code> today? Especially, I will soon introduce Docker to students. Is it worth spending time studying with them details of <code>docker-compose</code> or should I just jump to <code>docker stack</code>?  </p>

<docker><docker-compose>
Has `docker-compose` to be phased out in favor of `docker stack`?
Sylvain Leroux
# Has `docker-compose` to be phased out in favor of `docker stack`?

(Asked by: username_0 on 2019-02-01)

According to [the August 2017 article](https://vsupalov.com/difference-docker-compose-and-docker-stack/) the core functionalities of `docker-compose` were integrated into the new `docker stack` command. At the end of the article, the author also assumes `docker-compose` will soon to be deprecated. The [`docker stack deploy`](https://docs.docker.com/engine/reference/commandline/stack_deploy/) documentation is currently pretty sparse.

The article is six months old now. So, is `docker stack` the way to go, or is there still some advantage in using `docker-compose` today? Especially, I will soon introduce Docker to students. Is it worth spending time studying with them details of `docker-compose` or should I just jump to `docker stack`?

**Tags:** docker, docker-compose


---

## 1 answers

### Answer by username_1 on 2019-02-01. Score: 5

There are a few features of `docker-compose` that are not implemented in `docker stack deploy` and vice versa.

With `docker-compose`, you can run privileged containers and change capabilities which is not supported with swarm services yet. You can also run a container that is designed to exit, e.g. a batch job, more intuitively in docker-compose than in swarm mode. If your containers are designed for sysadmin tasks, this may make more sense.

With `docker stack deploy`, you get access to secrets and configs, along with replication settings, configuration of rolling updates, ingress networking with the routing mesh, and various other swarm mode features. If your containers are designed for highly available microservices, this makes more sense.

Both of these use the same docker-compose.yml definition file (with version 3 required for swarm mode). That makes moving between the two fairly easy. There are also projects like [compose-on-kubernetes](https://github.com/docker/compose-on-kubernetes) and [kompose](https://github.com/kubernetes/kompose) that make the transition to kubernetes with the same stack definitions easy.

> **Comments:**
> **username_0**: Thanks, @username_1. Since I asked my question, I experimented a little bit more with `docker stack`. It is very seducing, but it requires some understanding of the basic swarm concepts and has a more complicated setup (esp. since it doesn't build image and needs images to be stored in a repository). Given my actual requirements are to provide a gentle introduction to Docker, I will certainly stick with `docker-compose` with my students. Especially since I didn't find any source corroborating a potential deprecation of that tool in short- to mid-term.  

---

