DevSpace is an open-source tool that helps developers quickly deploy cloud-native applications to Kubernetes clusters. It abstracts away much of the traditional Kubernetes complexity so you can get back to writing code.
DevSpace is platform-agnostic and works with clusters ranging from your local machine to popular managed public services. The tool is a CLI that automates operations using Kubernetes APIs. You don’t need to install anything inside your cluster to use DevSpace.
Modern Development Practices for Kubernetes
DevSpace brings many aspects of the modern app programming experience to Kubernetes-based deployments. It lets you run your development environment on your cluster with support for automatic hot reloading. When a local file changes, DevSpace automatically updates your containers with the new content.
Built-in port forwarding means you can use localhost to access your deployment. You don’t need to open ports or setup HTTP Ingresses on development clusters, offering an improved developer experience and greater security.
DevSpace aids debugging too. It supports setting breakpoints using a Remote Debugger tool, offering live inspection of containerized applications in the cloud. It’s also easy to view a container’s logs or start a terminal session without running unwieldy Kubectl commands.
A web interface running on localhost lets you monitor and interact with your running application. You can escape your terminal altogether if you prefer a more visual experience.
Installing DevSpace
DevSpace is distributed as a self-contained binary that works on Windows, Mac, and Linux systems. Several installation options are available. Here’s the recommended command to download DevSpace for Linux and add the CLI to your path:
dev sudo install devspace /usr/local/bin
Alternatively you can use npm, the Node package manager, to install and update DevSpace:
npm install -g devspace
This command will give you a functioning devspace in your path, provided you’ve already got npm installed.
DevSpace uses your active “KUBE_CONTEXT” in the same way as other ecosystem tools like Kubectl and Helm. Set KUBECONFIG to a Kubectl-compatible config file defining your cluster connection:
export KUBECONFIG=/path/to/kubeconfig.yaml # Uses $KUBECONFIG devspace deploy
Creating a Project
The first step in building with DevSpace is to initialize your project directory. This will create a devspace.yaml file that holds the DevSpace config for your repository.
devspace init
You’ll be prompted to select the deployment routine you plan to use. DevSpace can work with Kubectl, Helm, or Kustomize when launching your app into your cluster.
The suggested QUICKSTART option is a special chart that lets you define components of your application, such as your frontend web server, backend API server, and database, instead of supplying manually created Helm charts or Kubectl manifests. Use this if you’re building a system with a conventional structure and don’t want to spent time creating your own Kubernetes resources.
Follow the prompts to supply DevSpace with the path to your Dockerfile. You’ll need to supply registry authentication and some basic information about your image, such as the port it listens on. DevSpace will automatically produce a ready to use config that lets you run devspace deploy to get your app live on Kubernetes.
If you don’t use the quickstart option, you’ll need to supply the path to your Helm charts or Kubernetes manifests. Follow the prompts to build an initial configuration. Once you get out of the setup wizard, you can continue adding extra images and deployments by manually editing your devspace.yaml file.
Adding an Image
DevSpace projects are built from one or more container images. To register an image in your project, add it under the images key in your devspace.yamlfile:
images: app: image: example.com/example/image:latest dockerfile: ./Dockerfile build: disabled: true
The image field defines the image tag name. The dockerfile field is optional; when set, it should reference the path to the image’s Dockerfile in your project. Images with Dockerfiles will be built automatically by the devspace build and devspace deploy commands, unless build.disabled is true in the image’s config.
Images are built in parallel to accelerate performance. The --build-sequential flag forces images to be built singly in the order they’re specified instead. DevSpace will automatically push each image to its respective registry after a build completes.
Images aren’t rebuilt automatically unless DevSpace detects a change either in their Dockerfile or the files in their build context. You can force a rebuild of all configured images with the --force-build flag.
Adding a Deployment
The second piece of a devspace.yaml is your deployments. These define the resources that will be created inside your cluster.
deployments: - name: "helm chart" helm: chart: name: example/example-app values: VARIABLE_OVERRIDE: "new-value" - name: "kubectl manifests" kubectl: manifests: - .kube/manifests
This file defines two separate deployments, one using Helm and the other Kubectl. When you run devspace deploy, both the Helm chart and your Kubectl manifests will be installed in your cluster.
Repeating the deploy command will update your deployments. DevSpace only redeploys the components that changed unless the --force-deploy flag is used.
As DevSpace works across clusters, promoting your deployment from development to production is a case of changing your KUBECONFIG environment variable and re-running devspace deploy. This gives you a single consistent mechanism for managing multiple independent deployments of your system.
Using Profiles
DevSpace supports profiles that let you modify devspace.yaml sections for each of your environments. Each named profile can replace, merge, and modify fields within your config file.
Profiles themselves are also defined in your devspace.yaml:
images: api-server: image: example.com/api-server:latest web-server: image: example.com/web-server:latest debug: image: example.com/debug-tool:latest # ... omitted profiles: - name: production patches: - op: remove path: images.debug
Profiles are activated by passing the -p or --profile flag to DevSpace commands. Here’s how to start a deployment using the production profile defined above. The deployment won’t include the debug image as it’s removed by one of the profile’s patches.
devspace deploy --profile production
Using Hot Reload
The hot reload functionality is enabled by setting up file synchronization:
dev: sync: - imageSelector: example.com/api-server:latest localSubPath: ./api/ containerPath: /var/www/html excludePaths: - vendor/
Add the dev key as a top-level field in your devspace.yaml, then use sync to configure hot reload on a per-image basis. The imageSelector matches image tags to apply the hot reload rule to. Files from localSubPath in your working directory will be synchronized to containerPath in deployed container instances.
Start a hot reload session by running devspace dev or devspace sync. The former command starts all DevSpace’s developer environment features, including port forwarding and live log streaming.
Hot reload defaults to replacing files in existing containers. It’s similar to using Docker volumes and bind mounts when working with local container instances. In some scenarios, you might want to start a new DevSpace deployment when your filesystem changes. This is achieved via the separate autoReload option:
images: api: image: example.com/api-server:latest deployments: - name: api-deployment # ... omitted dev: autoReload: paths: - ./kernel/* images: - example.com/api-server:latest deployments: - api-deployment
This example will redeploy api-deployment whenever files in your local kernel directory change. This is ideal when you modify files that need to be run through a build process to make them useful to your containers.
Port Forwarding
Port forwarding is configured via the dev.ports field in your devspace.yaml. Reverse forwarding is also supported, letting localhost addresses in your containers map to ports on your local machine.
dev: ports: - imageSelector: example.com/api-server:latest forward: - port: 8080 remotePort: 80 reverseForward: - port: 9000 remote: 9000
This example sets up a forward from localhost:8080 on your machine to port 80 in containers running the example.com/api-server image. There’s also a reverse forward which directs in-container traffic to localhost:9000 back to port 9000 on your machine.
Other Features
Besides the capabilities covered here, DevSpace also offers support for several other feature groups that let you monitor deployments, interact with containers, and configure advanced development workflows:
- Automatic terminal launches let you start a remote shell session each time you run
devspace dev. - Automatic URL opening starts websites and web apps in your browser when you enter development mode.
- Configurable logging defines which containers should appear in the dev mode log stream.
- Custom commands act as shortcuts to common actions, helping new team members interact with your deployments without needing to learn lengthy processes in Kubectl.
- Hooks run commands during the deployment process, letting you manually configure containers or record new deployments to a centralized monitoring service.
- The user interface runs automatically in development mode with
devspace devand can be opened in your browser usingdevspace ui.
DevSpace also offers plugins that can add even more functionality to the system. The plugin API supports installation from remote URLs or local scripts and facilitates new commands, hooks, and variables. Developing your own plugin provides a way to standardize your use of DevSpace across multiple independent projects.
Deployments In CI/CD Pipelines
DevSpace can handle production deployments as part of your CI/CD pipeline. It provides an official Docker image and supports non-interactive use if you include explicit selectors such as -l for label in your commands.
A deployment inside a CI pipeline could look like this:
echo $KUBECONFIG_CI_VARIABLE > /path/to/kubeconfig export KUBECONFIG=/path/to/kubeconfig devspace deploy --profile production --timeout 60 --wait --skip-build
This will deploy your application using the production DevSpace profile. The --skip-build flag instructs DevSpace not to build your images. Builds should usually be handled as a separate stage earlier in your pipeline.
The --wait flag forces DevSpace to wait for availability of the Pod count specified in your devspace.yaml, instead of terminating immediately after you run the command. This is more appropriate for a CI environment where you want confirmation that your workload is live. Allowing DevSpace to exit without waiting could mean your pipeline gets marked as successful even if there’s a deployment issue.
Conclusion
DevSpace is gaining traction as a developer-oriented Kubernetes deployment tool that provides useful abstractions for key operations. It reduces the amount of YAML needed to launch containers into a cluster, replacing it with simple config keys and terminal commands that define, build, and start images.
As a platform- and environment-agnostic tool, DevSpace permits developers to worry less about the unique characteristics of individual clusters. Irrespective of deployment target, the overall experience is similar to building a traditional system on your local machine. This helps soften the Kubernetes learning curve by mapping the concepts back to more universally understood development practices.
