I usually suggest passing `--env-file` to the actual compose binary. Gives you the "multiple deployment versions" without faffing about with external templating

I usually suggest passing `--env-file` to the actual compose binary. Gives you the "multiple deployment versions" without faffing about with external templating tools. docker compose --env-file ${INSTANCE}.env -f docker-compose.yml up In the `*.env` file: CONF_A_VALUE="some_value_a" CONF_B_VALUE="some_value_b" CONF_C_VALUE="some_value_c" ... In the compose file: services: service-1: # you need to be more explicit here environment: SOME_NAME_FOR_A: "${CONF_A_VALUE:?err}" SOME_NAME_FOR_B: "${CONF_B_VALUE:?err}" # but it gives you simple templating in other places labels: com.company.name.label.a: ${CONF_D_VALUE:?err} com.company.name.label.b: ${CONF_E_VALUE:?err} com.company.name.label.c: ${CONF_F_VALUE:?err} ports: - "${CONF_G_VALUE:?err}:8020" service-2: # also gives services more freedom to diverge from one another (if required) environment: MAYBE_ANOTHER_NAME_FOR_A_BECAUSE_COWBOY_TEAM_REASONS: "${CONF_A_VALUE:?err}" SOME_NAME_FOR_C: "${CONF_C_VALUE:?err}" Where `?err` forces the variable to be set and non-empty: https://docs.docker.com/compose/environment-variables/#substitute-environment-variables-in-compose-files https://docs.docker.com/compose/environment-variables/#subst... It's just a shame that `docker stack` doesn't have an `--env-file` argument yet for swarm deploys.