diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 5572134fbb9a2d7f4bcb661752ab029dca3bdb53..ac674b47a19647cfdd77b78afaffe15402e75296 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -1,35 +1,47 @@
-# In order to add container scanning for known vulnerabilities on your built Docker images, please refer to https://gitlab.cern.ch/gitlabci-examples/container_scanning
+# Using privileged runners
+# ------------------------
 
-# Using Kaniko
-# ------------
+# If you want to use DinD for your Docker-build jobs, you can use our privileged shared
+# GitLab-runners. This allows to directly build the image yourself as per https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#use-docker-in-docker-workflow-with-docker-executor
+build docker image with dind:
+  stage: build
+  tags: 
+  - docker-privileged
+  # Use specific version of the official docker client image (as well as the docker-in-docker image) as recommended by
+  # https://about.gitlab.com/2019/07/31/docker-in-docker-with-docker-19-dot-03/
+  image: docker:19.03.1
+  services:
+  # To obtain a Docker daemon, request a Docker-in-Docker service
+  - docker:19.03.1-dind
+  # Note about internal IPs Clash
+  # If the internal private network assigned to the dind service clashes with any service/host used on the job,
+  # you can specify a different IP subnet to avoid the clash. Useful command to inspect the assigned IP range
+  # is `docker network inspect bridge`. 
+  # To effectively assign a different IP subnet, replace the previous service definition with the following:
+  #  services:
+  #  # To obtain a Docker daemon, request a Docker-in-Docker service
+  #  - name: docker:19.03.1-dind
+  #    # Add to the dockerd command a specific bridge Ip, in this case the range 10.200.0.1/24 (to be adapted)
+  #    command: ["--bip=10.200.0.1/24"]
+  variables:
+      # As of GitLab 12.5, privileged runners at CERN mount a /certs/client docker volume that enables use of TLS to
+      # communicate with the docker daemon. This avoids a warning about the docker service possibly not starting
+      # successfully.
+      # See https://docs.gitlab.com/ee/ci/docker/using_docker_build.html#tls-enabled
+      DOCKER_TLS_CERTDIR: "/certs"
+      # Note that we do not need to set DOCKER_HOST when using the official docker client image: it automatically
+      # defaults to tcp://docker:2376 upon seeing the TLS certificate directory.
+      #DOCKER_HOST: tcp://docker:2376/
+  script:
+    - docker info
+    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
+    - docker build --pull -t "$CI_REGISTRY_IMAGE" .
+    - docker push "$CI_REGISTRY_IMAGE"
 
-# Kaniko is the recommended method for running Docker-builds as of May 2019. 
-# See https://docs.gitlab.com/ee/ci/docker/using_kaniko.html for GitLab's documentation.
-build_kaniko_command:
-    stage: build
-    variables:
-      # To push to a specific docker tag other than latest(the default), amend the --destination parameter, e.g. --destination $CI_REGISTRY_IMAGE:$CI_BUILD_REF_NAME
-      # See https://docs.gitlab.com/ee/ci/variables/predefined_variables.html#variables-reference for available variables
-      IMAGE_DESTINATION: ${CI_REGISTRY_IMAGE}:latest
-    image: 
-        # We recommend using the CERN version of the Kaniko image: gitlab-registry.cern.ch/ci-tools/docker-image-builder
-        name: gitlab-registry.cern.ch/ci-tools/docker-image-builder
-        entrypoint: [""]
-    script:
-        # Prepare Kaniko configuration file
-        - echo "{\"auths\":{\"$CI_REGISTRY\":{\"username\":\"$CI_REGISTRY_USER\",\"password\":\"$CI_REGISTRY_PASSWORD\"}}}" > /kaniko/.docker/config.json
-        # Build and push the image from the Dockerfile at the root of the project.
-        - /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/Dockerfile --destination $IMAGE_DESTINATION
-        # Print the full registry path of the pushed image
-        - echo "Image pushed successfully to ${IMAGE_DESTINATION}"
-
-# Features:
-# * Multi-stage builds: https://docs.docker.com/develop/develop-images/multistage-build/
-# * CVMFS is available if specifying the `cvmfs` tag
-# * Customise your build script
+# Features
+# * Allows your job to have access to the host, as it runs in privileged mode
+# * Allows to use docker-build directly
 
 # Limitations
-# * If your base image does not have a PATH value, your Dockerfile will require to specify one. Ref. https://github.com/GoogleContainerTools/kaniko/issues/650
-# * Kaniko depends on the Docker image repositories supporting schema2 (https://docs.docker.com/registry/spec/manifest-v2-2/), both for pulling and pushing, so it will not work otherwise. As of July 2019, this is the case with quay.io. Ref https://github.com/moby/buildkit/issues/409
-
-
+# * Privileged runners take around 1-2 minutes to spawn a VM for your job and do not cache Docker-images
+# * These runners will not be available during Openstack Nova API downtime