I have experience running production stacks on Swarm, Kubernetes and ECS. I think the best way to talk about running Swarm stacks in production is to compare it to other orchestration runtimes.<p>Swarm has a really low learning curve. You can simply write a docker-compose.yml that defines your stack and then run it. The syntax of a docker-compose yaml is likely familiar to many developers who have been using Docker, so that is a huge advantage when adopting. It's a version 3.3 YAML, not the standard docker-compose, but the changes are pretty minor.<p>Swarm stacks come with a built-in overlay (software-defined) network. Services can be identified using in-cluster DNS that round-robins to all containers running that service. This mostly works well, but it's been a challenge to depend on at scale. When a service is rescheduled due to failure, we've seen some instances where requests are dropped.<p>Swarm services are just less specialized than k8s ones, which is the tradeoff for a more approachable, easy-to-use runtime. There's no deployment, service, load balancer, etc. You just run services that depend on other services.<p>Swarm's "depends_on" syntax is simpler, but less robust than what Kubernetes offers.<p>Swarm's secrets are amazing, and really great, but you have to build for them. The idea is that a Swarm Secret doesn't just exist in an unencrypted environment variable, but it's a secured file on disk in the container. The team at Docker did a great job here.<p>While I'm a huge fan of Kubernetes and continuing to push Kubernetes adoption for some of our services, we also use a decent amount of Swarm and plan to continue.<p>Finally, I do worry a little about the Swarm scheduler's future. If anyone from Docker is around, it would be great to hear from them on this. Since they are pushing Kubernetes also, it does make me hesitate to recommend Swarm for a new service, with the risk that it will be end-of-lifed soon.