Agreed. That's a great point when it is a simple use case, and how I started. Now that I build for Docker Compose out of the gate, it allows me to deploy a comp

Agreed. That's a great point when it is a simple use case, and how I started. Now that I build for Docker Compose out of the gate, it allows me to deploy a composition across a multi-host Docker Swarm (usually just changing the network driver to overlay + utilize labels) with 1 command, and more importantly I do not have to rebuild my container on production. Back in docker 1.9, I found myself running too many variations to get the same behavior that Compose natively handles with the new labels + overlay functionality (reference http://blog.levvel.io/blog-post/running-distributed-docker-swarm-on-aws/ http://blog.levvel.io/blog-post/running-distributed-docker-s...). I was using `docker run` to deploy across specific hosts using manually-assigned env vars invoked with a docker run: # docker run -itd --name=AppDeployedToNode1 --env="constraint:node==swarm1.internallevvel.com" busybox # docker run -itd --name=AppDeployedToNode2 --env="constraint:node==swarm2.internallevvel.com" busybox # docker run -itd --name=AppDeployedToNode3 --env="constraint:node==swarm3.internallevvel.com" busybox RabbitMQ Example - https://gist.github.com/jay-johnson/2673ce4df42317667908#file-manually-deploying-a-rabbitmq-cluster-with-docker-swarm-L50 https://gist.github.com/jay-johnson/2673ce4df42317667908#fil... Looking back I feel like it was a lot of effort to deploy 3 busybox instances or that initial RabbitMQ cluster…and that effort to handle the “production deployment case” as early as possible is what set me on the path to the new Docker Compose-centric approach discussed in the link above.