DevSpace allows you to store all your workflows in one declarative config file: devspace.yaml

• Codify workflow knowledge about building images, deploying your project and its dependencies etc.
• Version your workflows together with your code (i.e. you can get any old version up and running with just a single command)
• Share your workflows with your team mates

DevSpace helps your team to standardize deployment and development workflows without requiring everyone on your team to become a Kubernetes expert.

• The DevOps and Kubernetes expert on your team can configure DevSpace using devspace.yaml and simply commits it via git
• If other developers on your team check out the project, they only need to run devspace deploy to deploy the project (including image building and deployment of other related project etc.) and they have a running instance of the project
• The configuration of DevSpace is highly dynamic, so you can configure everything using config variables that make it much easier to have one base configuration but still allow differences among developers (e.g. different sub-domains for testing)

Giving everyone on your team on-demand access to a Kubernetes cluster is a challenging problem for system administrators and infrastructure managers. If you want to efficiently share dev clusters for your engineering team, take a look at www.loft.sh.

Instead of rebuilding images and redeploying containers, DevSpace allows you to hot reload running containers while you are coding:

• Simply edit your files with your IDE and see how your application reloads within the running container.
• The high performance, bi-directional file synchronization detects code changes immediately and synchronizes files immediately between your local dev environment and the containers running in Kubernetes
• Stream logs, connect debuggers or open a container terminal directly from your IDE with just a single command.

Deploying and debugging services with Kubernetes requires a lot of knowledge and forces you to repeatedly run commands like kubectl get pod and copy pod ids back and forth. Stop wasting time and let DevSpace automate the tedious parts of working with Kubernetes:

• DevSpace lets you build multiple images in parallel, tag them automatically and and deploy your entire application (including its dependencies) with just a single command
• Let DevSpace automatically start port-fowarding and log streaming, so you don't have to constantly copy and paste pod ids or run 10 commands to get everything started.

DevSpace is battle tested with many Kubernetes distributions including:

• local Kubernetes clusters like minikube, k3s, MikroK8s, kind
• managed Kubernetes clusters in GKE (Google Cloud), EKS (Amazon Web Service), AKS (Microsoft Azure), Digital Ocean
• self-managed Kubernetes clusters created with Rancher

DevSpace also lets you switch seamlessly between clusters and namespaces. You can work with a local cluster as long as that is sufficient. If things get more advanced, you need cloud power like GPUs or you simply want to share a complex system such as Kafka with your team, simply tell DevSpace to use a remote cluster by switching your kube-context and continue working.

• Customizable Build Process supporting Docker, kaniko or even custom scripts
• Parallel Image Building to save time when multiple Dockerfiles have to be built
• Automatic Image Tagging according to custom tag schema (e.g. using timestamp, commit hash or random strings)
• Automatic Push to any public or private Docker registry (authorization via docker login my-registry.tld)
• Automatic Configuration of Pull Secrets within the Kubernetes cluster
• Smart Caching that skips images which do not need to be rebuilt

• Automatig Image Building for images required in the deployment process
• Customizable Deployment Process supporting kubectl, helm, kustomize and more
• Multi-Step Deployments to deploy multiple application components (e.g. 1. webserver, 2. database, 3. cache)
• Efficient Microservice Deployments by defining dependencies between projects (even across git repositories)
• Smart Caching that skips deployments which do not need to be redeployed
• Easy Integration into CI/CD Tools with non-interactive mode

• Hot Reloading that updates your running containers without restarting them (whenever you change a line of code)
• Fast + Reliable File Synchronization to keep all files in sync between your local workspace and your containers
• Port Forwarding that lets you access services and pods on localhost and allows you to attach debuggers with ease
• Multi-Container Log Streaming that lets you stream the logs of multiple containers at once (+ color-coded prefix)
• Terminal Proxy that opens automatically and lets you run commands in your pods directly from your IDE terminal

• Graphical UI for streaming logs, opening interactive terminals, starting port-forwarding and more
• Runs 100% on localhost: uses current kube-context, no server-side installation required

• Quick Pod Selection eliminates the need to copy & paste pod names, namespaces etc. » Shows a "dropdown selector" for pods directly in the CLI when running one of these commands:
  • devspace enter to open a Interactive Terminal Session
  • devspace logs / devspace logs -f for Fast, Real-Time Logs (optionally streaming new logs)
  • devspace sync for quickly starting a Bi-Directional, Real-Time File Synchronization on demand
• Automatic Issue Analysis via devspace analyze reporting crashed containers, missing endpoints, scheduling errors, ...
• Fast Deletion of Deployments using devspace purge (deletes all helm charts, manifests etc. defined in the config)
• Context Management via:
  • devspace use context shows a list of contexts (select to set current kube-context)
  • devspace use namespace shows a list of namespaces (select to set defaut namespace for current context)
  • devspace remove context shows a list of contexts (select to remove a kube-context)

• Declarative Configuration File that can be versioned and shared just like the source code of your project (e.g. via git)
• Config Variables which allow you to parameterize the config and share a unified config file with your team
• Config Overrides for overriding Dockerfiles or ENTRYPOINTs (e.g. to separate development, staging and production)
• Hooks for executing custom commands before or after each build and deployment step
• Multiple Configs for advanced deployment scenarios

• Client-Only Binary (optional plugin for loft.sh for cluster sharing + multi-tenancy)
• Standalone Executable for all platforms with no external dependencies and fully written in Golang
• Automatic Config Generation from existing Dockerfiles, Helm chart or Kubernetes manifests (optional)
• Automatic Dockerfile Generation (optional)

DevSpace provides a plugin for loft.sh which allows users to run command such as devspace create space or devspace create vcluster for creating namespaces and virtual Kubernetes clusters in shared dev clusters.

Loft is a server-side solution for Kubernetes multi-tenancy and efficient cluster sharing which provides:

• On-Demand Namespace Creation & Isolation with automatic RBAC, network policies, pod security policies etc.
• Graphical UI for managing clusters, cluster users and user permissions (resource limits etc.)
• Advanced Permission System that automatically enforces user limits via resource quotas, adminission controllers etc.
• Fully Automatic Context Configuration on the machines of all cluster users with secure access token handling
• 100% Pure Kubernetes and nothing else! Works with any Kubernetes cluster.

For more infos and install intructions for loft, see: www.github.com/loft-sh/loft

npm install -g devspace

yarn global add devspace

curl -s -L "https://github.com/devspace-cloud/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-darwin-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace;
sudo mv devspace /usr/local/bin;

curl -s -L "https://github.com/devspace-cloud/devspace/releases/latest" | sed -nE 's!.*"([^"]*devspace-linux-amd64)".*!https://github.com\1!p' | xargs -n 1 curl -L -o devspace && chmod +x devspace;
sudo install devspace /usr/local/bin

md -Force "$Env:APPDATA\devspace"; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls,Tls11,Tls12';
Invoke-WebRequest -UseBasicParsing ((Invoke-WebRequest -URI "https://github.com/devspace-cloud/devspace/releases/latest" -UseBasicParsing).Content -replace "(?ms).*`"([^`"]*devspace-windows-amd64.exe)`".*","https://github.com/`$1") -o $Env:APPDATA\devspace\devspace.exe;
$env:Path += ";" + $Env:APPDATA + "\devspace";
[Environment]::SetEnvironmentVariable("Path", $env:Path, [System.EnvironmentVariableTarget]::User);

If you get the error that Windows cannot find DevSpace after installing it, you will need to restart your computer, so that the changes to the PATH variable will be applied.

cd /path/to/my/project/root

If you are using DevSpace for the first time, we recommend to get started with one of the demo projects listed above.

devspace create space my-app # requires login via GitHub or email

DevSpace automatically sets up a kube-context for this space, so you can also access your isolated namespace using kubectl, helm or any other Kubernetes tool.

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:

# Tell DevSpace which namespace to use (will be created automatically during deployment)
devspace use namespace my-namespace

Option A: You alone want to use this cluster

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

# Tell DevSpace which namespace to use (will be created automatically during deployment)
devspace use namespace my-namespace

Option B: You want to share this cluster with your team

To share a cluster with everyone on your team, install loft, then connect your cluster to your loft instance and then create an isolated Kubernetes namespace via the loft plugin for DevSpace.

# Install the loft plugin for DevSpace
devspace add plugin https://github.com/loft-sh/loft-devspace-plugin

# Login to your loft instance via the CLI
devspace login https://your-loft-instance.tld

# Create an isolated Kubernetes namespace via loft
devspace create space my-namespace

The loft plugin for DevSpace will automatically set up a kube-context for every space you create, so you can also access your isolated namespace using kubectl, helm or any other Kubernetes tool.

# File: ./devspace.yaml
version: v1beta9

images:
  backend:                              # Key 'backend' = Name of this image
    image: my-registry.tld/image1       # Registry and image name for pushing the image
    createPullSecret: true              # Let DevSpace automatically create pull secrets in your Kubernetes namespace

deployments:
- name: quickstart-nodejs               # Name of this deployment
  helm:                                 # Deploy using Helm
    chart:                              # Helm chart to be deployed
      name: component-chart             # DevSpace component chart is a general-purpose Helm chart
      version: 0.1.3
      repo: https://charts.devspace.sh
    values:                             # Override Values for chart (van also be set using valuesFiles option)
      containers:                       # Deploy these containers with this general-purpose Helm chart
      - image: my-registry.tld/image1   # Image of this container
        resources:
          limits:
            cpu: "400m"                 # CPU limit for this container
            memory: "500Mi"             # Memory/RAM limit for this container
      service:                          # Expose this component with a Kubernetes service
        ports:                          # Array of container ports to expose through the service
        - port: 3000                    # Exposes container port 3000 on service port 3000
- name: database                        # A second deployment for a postgresql database
  helm:
    chart:
      name: stable/postgresql
    values:
      postgresqlDatabase: "db_website"
      postgresqlUsername: "db_user"
      postgresqlPassword: ${DB_PASSWORD}
      resources:
        requests:
          memory: 0
          cpu: 0

dev:
  ports:
    forward:
    - port: 3000
    - port: 8080
      remotePort: 80
    image: backend
  open:
  - url: http://localhost:3000/login
  sync:
  - localSubPath: ./src
    containerPath: .
    image: backend
  autoReload:
    paths:
    - ./manifests/**

dependencies:
- source:
    git: https://github.com/my-api-server
- source:
    path: ../my-auth-server

# File: ./devspace.yaml
images:
  auth-server:
    image: dockerhub-username/my-auth-server    # Push to Docker Hub (no registry hostname required) => uses ./Dockerfile by default
    createPullSecret: true                      # Create a Kubernetes pull secret for this image before deploying anything
  webserver:
    image: myregistry.tld/username/my-webserver # Push to private registry
    createPullSecret: true
    dockerfile: ./webserver/Dockerfile          # Build with --dockerfile=./webserver/Dockerfile
    context: ./webserver                        # Build with --context=./webserver
  database:
    image: another-registry.tld/my-image        # Push to another private registry
    createPullSecret: true
    dockerfile: ./db/Dockerfile                 # Build with --dockerfile=./db/Dockerfile
    context: ./db                               # Build with --context=./db
    # The following lines define custom tag schemata for this image (default tag schema is: ${DEVSPACE_RANDOM})
    tags:
    - ${DEVSPACE_USERNAME}-devspace-${DEVSPACE_GIT_COMMIT}-${DEVSPACE_RANDOM}

Take a look at the documentation for more information about configuring builds with Docker.

# File: ./devspace.yaml
images:
  auth-server:
    image: dockerhub-username/my-auth-server    # Push to Docker Hub (no registry hostname required) => uses ./Dockerfile by default
    build:
      kaniko:                                   # Build this image with kaniko
        cache: true                             # Enable caching
        insecure: false                         # Allow kaniko to push to an insecure registry (e.g. self-signed SSL certificate)
  webserver:
    image: myregistry.tld/username/my-webserver # This image will be built using Docker with kaniko as fallback if Docker is not running
    createPullSecret: true
    dockerfile: ./webserver/Dockerfile          # Build with --dockerfile=./webserver/Dockerfile
    context: ./webserver                        # Build with --context=./webserver

Take a look at the documentation for more information about building images with kaniko.

# File: ./devspace.yaml
images:
  auth-server:
    image: dockerhub-username/my-auth-server    # Push to Docker Hub (no registry hostname required) => uses ./Dockerfile by default
    build:
      custom:
        command: "./scripts/builder"
        args: ["--some-flag", "flag-value"]
        imageFlag: "image"
        onChange: ["./Dockerfile"]
  webserver:
    image: myregistry.tld/username/my-webserver # This image will be built using Docker with kaniko as fallback if Docker is not running
    createPullSecret: true
    dockerfile: ./webserver/Dockerfile          # Build with --dockerfile=./webserver/Dockerfile
    context: ./webserver                        # Build with --context=./webserver

Take a look at the documentation for more information about using custom build scripts.

# File: ./devspace.yaml
deployments:
- name: quickstart-nodejs
  helm:
    componentChart: true
    values:
      containers:
      - image: my-registry.tld/image1
        resources:
          limits:
            cpu: "400m"
            memory: "500Mi"

Learn more about:

• What are components?
• Configuring Components

# File: ./devspace.yaml
deployments:
- name: default
  helm:
    chart:
      name: redis
      version: "6.1.4"
      repo: https://kubernetes-charts.storage.googleapis.com

Learn more about:

• What are Helm charts?
• Configure Helm chart deployments

# File: ./devspace.yaml
deployments:
- name: my-nodejs-app
  kubectl:
    manifests:
    - manifest-folder/
    - some-other-manifest.yaml

Learn more about:

• What are Kubernetes manifests?
• Configure manifest deployments

# File: ./devspace.yaml
deployments:
- name: my-deployment
  kubectl:
    manifests:
    - my-manifests/
    - more-manifests/
    kustomize: true

Take a look at the documentation for more information about deploying manifests with kustomize.

# File: ./devspace.yaml
deployments:
- name: my-deployment
  kubectl:
    manifests:
    - manifest-folder/
    - some-other-manifest.yaml
- name: my-cache
  helm:
    chart:
      name: redis
      version: "6.1.4"
      repo: https://kubernetes-charts.storage.googleapis.com

DevSpace processes all deployments of a project according to their order in the devspace.yaml. You can combine deployments of different types (e.g. Helm charts and manifests).

Take a look at the documentation to learn more about how DevSpace deploys projects to Kubernetes.

# File: ./devspace.yaml
dependencies:
- source:
    git: https://github.com/my-api-server
- source:
    git: https:/my-private-git.tld/my-auth-server
- source:
    path: ../my-auth-server
  profile: production

Before deploying a project, DevSpace resolves all dependencies and builds a dependency tree which will then be deployed in a buttom-up fashion, i.e. the project which you call devspace deploy in will be deployed last.

Take a look at the documentation to learn more about how DevSpace deploys dependencies of projects.

# File: ./devspace.yaml
dev:
  sync:
  - localSubPath: ./src # relative to the devspace.yaml
    # Start syncing to the containers current working directory (You can also use absolute paths)
    containerPath: .
    # This tells devspace to select pods that have the following labels
    labelSelector:
      app.kubernetes.io/component: default
      app.kubernetes.io/name: devspace-app
    # Only download changes to these paths, but do not upload any changes (.gitignore syntax)
    uploadExcludePaths:
    - node_modules/
    # Only upload changes to these paths, but do not download any changes (.gitignore syntax)
    downloadExcludePaths:
    - /app/tmp
    # Ignore these paths completely during synchronization (.gitignore syntax)
    excludePaths:
    - Dockerfile
    - logs/

The above example would configure the sync, so that:

• local path ./src will be synchronized to the container's working directory . (specified in the Dockerfile)
• ./src/node_modules would not be uploaded to the container

Take a look at the documentation to learn more about configuring file synchronization during development.

# File: ./devspace.yaml
dev:
  autoReload:
    paths:
    - ./Dockerfile
    - ./manifests/**

This configuration would tell DevSpace to redeploy your project when the Dockerfile changes or any file within ./manifests.

Take a look at the documentation to learn more about configuring auto-reloading for development.

# File: ./devspace.yaml
images:
  default:
    image: ${DEVSPACE_USERNAME}/image-name
    tags:
    - ${DEVSPACE_GIT_COMMIT}-${DEVSPACE_TIMESTAMP}
    - latest

DevSpace allows you to use certain pre-defined variables to make the configuration more flexible and easier to share with others. Additionally, you can add your own custom variables.

Take a look at the documentation to learn more about using variables for dynamic configuration.

# File: ./devspace-configs.yaml
images:
  backend:
    image: john/devbackend
  backend-debugger:
    image: john/debugger
deployments:
- name: app-backend
  helm:
    componentChart: true
    values:
      containers:
      - image: john/devbackend
      - image: john/debugger
profiles:
- name: production
  patches:
  - op: replace
    path: images.backend.image
    value: john/prodbackend
  - op: remove
    path: deployments[0].component.containers[1]
  - op: add
    path: deployments[0].component.containers
    value:
      image: john/cache

DevSpace allows you to define different profiles for different use cases (e.g. working on different services in the same project, starting certain debugging enviroment) or for different deployment targets (e.g. dev, staging production).

You can tell DevSpace to switch permenantly to another profile using this command: devspace use profile [config-name]

Alternatively, you can temporarily use a different profile for running a single command using the -p / --profile [NAME] flag.

Take a look at the documentation to learn more about using config profiles and patches.

# File: ./devspace.yaml
hooks:
  - command: echo
    args:
      - "before image building"
    when:
      before:
        images: all

The command defined in this hook would be executed before building the images defined in the config.

Take a look at the documentation to learn more about using hooks.

Problem

This problem can be caused by many different things.

Solution

There is no single solution for this but here are some steps to troubleshoot this problem:

1. Let DevSpace analyze your deployment

Run this command within your project:

devspace analyze

2. Check your Dockerfile

Make sure your Dockerfile works correctly. Use Google to find the best solutions for creating a Dockerfile for your application (often depends on the framework you are using).

If your pods are crashing, you might have the wrong ENTRYPOINT or something is missing within your containers. A great way to debug this is to start the interactive development mode using:

devspace dev -i

With the interactive mode, DevSpace will override the ENTRYPOINT in our Dockerfile with [sleep, 999999] and open a terminal proxy. That means your containers will definitively start but only in sleep mode. After the terminal opens you can run the start command for your application yourself, e.g. npm start.

3. Debug your application with kubectl

Run the following commands to find issues:

# Failing Pods
kubectl get po                  # Look for terminated, crashed or pending pods (restart > 1 is usually not good)
kubectl describe po [POD_NAME]  # Look at the crash reports Kubernetes provides

# Network issues
kubectl get svc                 # See if there is a service for your app
kubectl get ep                  # Make sure every service has endpoints (if not: make sure you are using the right ports in your devspace.yaml and make sure your pods are running)
kubectl get ing                 # Make sure there is an ingress for your app

Problem

This might happen when the VM of your Docker daemon has the wrong date/time.

Solution

Make sure the VM of your Docker daemon has the correct date/time. For Docker Desktop, you can run the following script to fix the issue:

HOST_TIME=$(date -u +"%Y.%m.%d-%H:%M:%S");
docker run --net=host --ipc=host --uts=host --pid=host -it --security-opt=seccomp=unconfined --privileged --rm -v /:/docker-vm alpine /bin/sh -c "date -s $HOST_TIME"

DevSpace is an open-source command-line tool that provides everything you need to develop, deploy and debug applications with Docker and Kubernetes. It lets you streamline deployment workflows and share them with your colleagues through a declarative configuration file devspace.yaml.

YES. DevSpace is open-source and you can use it for free for any private projects and even for commercial projects.

loft is a multi-tenancy manager for Kubernetes which allows you to connect clusters that you want to make available for your engineering teams. After connecting a cluster, engineers will be able to create isolated namespaces and even virtual Kubernetes clusters within the cluster whenever they need access to Kubernetes.

loft is maintained by the same people who are developing DevSpace.

Yes. You can either use a local cluster such as Docker Desktop Kubernetes, minikube, or Kind, but you can also use a remote cluster such as GKE, EKS, AKS, RKE (Rancher), or DOKS.

Yes. DevSpace is using your regular kube-context. As long as you can run kubectl commands with a cluster, you can use this cluster with DevSpace as well.

Helm is the package manager for Kubernetes. Packages in Helm are called Helm charts. Learn more about Helm charts.