DevSpace fully automates the manual work of building, tagging and pushing Docker images.
Start Image Building
When you run one of the following commands, DevSpace will run the image building process:
devspace build(only image building without deployment)
devspace deploy(before deploying the application)
devspace dev(before deploying the application and starting the development mode)
The following flags are available for all commands that trigger image building:
-b / --force-buildrebuild all images (even if they could be skipped because context and Dockerfile have not changed)
--build-sequentialbuild images sequentially instead of in parallel
Image Building Process
DevSpace loads the
images configuration from
devspace.yaml and builds all images in parallel. The multi-threded, parallel build process of DevSpace speeds up image building drastically, especially when building many images and using remote build methods.
1. Load Dockerfile
DevSpace loads the contents of the Dockerfile specified in
dockerfile (defaults to
Dockerfile paths used in
dockerfileshould be relative to the
2. Apply Entrypoint Override (if configured)
DevSpace allows you to apply an in-memory override of a Dockerfile's
ENTRYPOINT by configuring the
entrypoint option for the image. Similar to the Dockerfile
entrypoint option should be defined as an array.
ENTRYPOINToverrides can be particularly useful when defining different config profiles in your
3. Load Build Context
DevSpace loads the the context to build this image as specified in
context (defaults to
./). The context path serves as root directory for Dockerfile statements like
Context paths used in
contextshould be relative to the
4. Skip Image (if possible)
DevSpace tries to speed up image building by skipping images when they have not changed since the last build process. To do this, DevSpace caches the following information after building an image:
- a hash of the
Dockerfileused to build the image (including ENTRYPOINT override)
- a hash over all files in the
contextused to build this image (excluding files in
Next time you trigger the image building process, DevSpace will generate these hashes again and compare them to the hashes of the last image building process. If all newly generated hashes are equal to the old ones stored during the last image building process, then nothing has changed and DevSpace will skip this image.
You can use the
-b / --force-buildflag to tell DevSpace to build all images even if nothing has changed.
5. Build Image
DevSpace uses one of the following build tools to create an image based on your Dockerfile and the provided context:
dockerfor building images using a Docker daemon (default, prefers Docker daemon of local Kubernetes clusters)
kanikofor building images directly inside Kubernetes (fallback for
customfor building images with a custom build command (e.g. for using Google Cloud Build)
6. Tag Image
DevSpace automatically tags all images after building them using a tagging schema that you can customize using the
tag option. By default, this option is configured to generate a random string consisting of 5 characters.
Before deploying your application, DevSpace will use the newly generated image tags and replace them in-memory in the values for your Helm charts and components, so they will be deployed using the most recently built images.
7. Push Image + Registry Authentication
DevSpace automatically pushes your images to the respective registry that should be specified as part of the
image option. Just as with regular Docker images, DevSpace uses Docker Hub if no registry hostname is provided within
You can skip this step when proving the
--skip-pushflag. Beware that deploying your application after using
--skip-pushwill only work when using a local Kubernetes cluster.
DevSpace uses the same credential store as Docker. So, if you already have Docker installed and you are logged in to a private registry before, DevSpace will be able to push to this registry. So, if you want to push to a registry using DevSpace, simply authenticate using this command:
docker login # for Docker Hub docker login [REGISTRY] # for any other registry (e.g. my-registry.tld)
If you do not have Docker installed, DevSpace initializes a Docker credential store for you and store your login information just like Docker would do it (currently only for Docker Hub or dscr.io).
Skip Image Push for Local Clusters (if possible)
If you are using a local Kubernetes cluster, DevSpace will try to build the image using the Docker deamon of this local cluster. If this process is successful, DevSpace will skip the step of pushing the image to a registry as it is not required for deploying your application.
8. Create Image Pull Secret
When deploying your application via DevSpace, Kubernetes needs to be able to pull your images from the registry that is used to store your images when pushing them. For this purpose, Kubernetes relies on so-called image pull secrets. DevSpace can automatically create these secrets for you, if you configure
createPullSecret: true for the respective image in your
You do not need to change anything in your Kubernetes manifests, helm charts or components to use the image pull secrets that DevSpace creates because DevSpace automatically adds the secrets to the service account used to deploy your project.
devspace deploy or
devspace dev, you should be able to see the auto-generated pull secrets created by DevSpace when you run the following command:
kubectl get serviceaccount default -o yaml
Take a look at the
imagePullSecrets section of the output showing the yaml definition of the service account
What does "context" mean in terms of image building?
The context is archived and sent to the Docker daemon before starting to process the Dockerfile. All references of local files within the Dockerfile are relative to the root directory of the context.
That means that a Dockerfile statement such as
COPY ./src /app would copy the folder
src/ within the context path into the path
/app within the container image. So, if the context would be
/my/project/database, for example, the folder that would be copied into
/app would have the absolute path
/my/project/database/src on your local computer.
Paths to Dockerfiles and image contexts are always relative to the root directory of your project (i.e. the folder where your
.devspace/folder is inside).