So yes, you got it! They use the word "tag" in two totally different ways which is confusing. When you create a gitlab-ci runner you can "tag" the runner. Basi

So yes, you got it! They use the word "tag" in two totally different ways which is confusing. When you create a gitlab-ci runner you can "tag" the runner. Basically, this is like a named server. For instance, I have a general gitlab-ci runner which I use to run most of my builds. However, I found that I need a special runner just for building docker images. So most of my jobs in my gitlab-ci are marked with: tags: - general Where as my docker build job is marked with: tags: - docker-builder This basically pushes the job to a specific runner and has nothing to do at all with the git ref (which could be a branch name or a tag or whatnot). Now when do I build docker containers? I actually don't use "git ref tags" (i.e. git tag v.1.16.001 or something). I have a development branch, a staging branch, and a production branch which tie to my environments (dev, staging, and production). So my job runner looks something like this: stages: - test - build - deploy docker_build: stage: build script: - do some stuff - docker tag container-name:$CI_BUILD_REF_NAME $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME - docker push $AWS_ACCOUNT_ID.$AWS_ACCOUNT_REGION.amazonaws.com/container-name:$CI_BUILD_REF_NAME tags: - docker-builder only: - development - staging - master So basically once the tests pass, and IF the branch is development, staging, or master, it will build the docker container, using the CI_BUILD_REF_NAME as the tag and then push that to my private aws container storage system. The AWS_ACCOUNT_ID and REGION are both environment variables I have injected previously. If that succeeds it moves to the deploy stage.