Skip to main content
Version: 5.x

Deployment with DevSpace

Once you are done with developing your application or you just want to test if it works even outside of development mode with your actual container image, you can start a clean deployment.

DevSpace CLI - Deployment

Kube-Context & Namespace

For this clean deployment, you may want to switch to a different namespace or even to a different cluster to test your application in a cloud-powered cluster, for example.

Local Clusters

Local clusters run on your local dev machine and include: minikube, kind, k3s, mikrok8s etc.

If you want to deploy to a local Kubernetes cluster, make sure your current kube-context points to this cluster and tell DevSpace which namespace to use:

devspace use context                  # to select the right k8s cluster
devspace use namespace my-namespace # will be automatically created during deployment
Kube-Context Namespace

Running the command above will change the default namespace of your kube-context, i.e. instead of using the default namespace, kubectl and other tools will now use a different namespace when working with this kube-context. That also means, you will not always need to use the --namespace / -n flag.

Deploy Project

Run the local deployment pipeline using this command:

devspace deploy -p production
Deployment Workflow
DevSpace CLI - Deployment Workflow

Running devspace deploy -p production will do the following:

  1. Build the Dockerfile(s) specified in the images section of the devspace.yaml
  2. Tag the resulting image(s) with an auto-generated tag according to a customizable tag schema
  3. Push the resulting Docker images to the specified registries
  4. Create image pull secrets in your Kubernetes namespace (optional, enabled by default)
  5. Deploy everything that is defined within the deployments section in the devspace.yaml
Image Building Only

If you only want to build, tag and push all images but not deploy anything, run:

devspace build

Understand Profiles

As shown earlier, DevSpace is by default configured to skip image building, for example. However, to fully test your containerized application you may want to create a fresh image and push this image to a registry.

Profiles allow you to apply modifications to your devspace.yaml configuration for certain use cases or for different deployment targets (e.g. dev vs testing vs production).

By default, devspace init adds a small example profile called production which only removes the disabled: true statement from our images section which in turn enables image building:

profiles:
- name: production
patches:
- op: remove
path: images.app.build.disabled

You can print the config after a profile has been applied to see what the profile actually changes:

devspace print -p production

The flag -p / --profile is global, so we can also use them for other commands and define profiles that apply to different workflows for commands such as devspace dev:

devspace dev -p start-debugger