Here’s a quick tip on how to convert docker-compose.yml file to a Docker Swarm mode ready file.

the command

Imma be straight to the point and share few commands to help you with converting a Docker Compose stack config to a Docker Swarm mode one:

docker stack config --compose-file docker-compose.yml > swarm.yml

To deploy it, run:

docker stack deploy --compose-file swarm.yml my-service

Notes:

  • Replace my-service with your preferred stack name
  • Use -c for shorthand for --compose-file

why bother generating the file first

You could skip this step and deploy directly (more on that below), but generating the resolved config first is worth it. The output shows you exactly what Docker Swarm will see after resolving all variable substitutions, extension fields, and merge keys. If something blows up during deployment, you’ll know whether it’s a config problem or a runtime problem.

It’s also useful for diffing: git diff swarm.yml before deploying tells you exactly what’s changing.

what actually changes in the conversion

Docker Swarm doesn’t support everything that Compose does. The most common things that get dropped or changed silently:

  • build: — Swarm can’t build images, it can only pull them. If your Compose file has build: directives, they’re ignored. Make sure you’ve already built and pushed the images to a registry.
  • depends_on: — Ignored in Swarm. Swarm has no concept of startup ordering. If your services need to wait for each other, you’ll need a health check + restart policy, or an entrypoint script that retries.
  • container_name: — Not supported. Swarm manages container names itself.
  • deploy: — This is where you define replicas, resource limits, placement constraints, and restart policies in Swarm. If you haven’t added a deploy: block to your services yet, do it before converting.

.env file

When your setup relies on .env file, you’ll need to export the variables before deployment since Docker Swarm doesn’t automatically load .env files:

export $(cat .env) > /dev/null 2>&1; docker stack deploy my-service --compose-file=docker-compose.yml

One of the weakest points by Docker Swarm mode tho. If you want a cleaner approach for secrets, use Docker Secrets instead of .env files — they mount into containers as files under /run/secrets/ and don’t require exporting anything.

alternative direct deployment

For simple cases, you can skip the conversion step and deploy directly:

docker stack deploy my-service --compose-file docker-compose.yml

Docker will handle the conversion internally, though generating the swarm file first gives you more visibility into the final configuration.

updating a running stack

When you redeploy with the same stack name, Swarm updates only the services that changed. Pass --prune to also remove services that are in the running stack but no longer in your compose file:

docker stack deploy --prune --compose-file swarm.yml my-service

Without --prune, removed services stay running until you manually remove them with docker service rm.

bottom line

The docker stack config command is underused. Run it, inspect the output, then deploy. Saves you from surprises.

Shameless plug: Check out justanotheruptime.com in case you are looking for a SaaS monitoring solution :)