Website • Quickstart • Examples • Documentation • Blog • Slack • Twitter
- Build, test and debug applications directly inside Kubernetes
- Develop with hot reloading: updates your running containers without rebuilding images or restarting containers
- Unify deployment workflows within your team and across dev, staging and production
- Automate repetitive tasks for image building and deployment
⭐️ Do you like DevSpace? Support the project with a star ⭐️
- Why DevSpace?
- Features
- Architecture & Workflow
- Quickstart Guide
- Config Examples
- Troubleshooting
- Contributing
- FAQ
Building modern, distributed and highly scalable microservices with Kubernetes is hard - and it is even harder for large teams of developers. DevSpace is the next-generation tool for fast cloud-native software development.
Standardize & Version Your Workflows
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
Let Everyone on Your Team Deploy to Kubernetes
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.yamland simply commits it via git - If other developers on your team check out the project, they only need to run
devspace deployto 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. DevSpace Cloud, an optional add-on for DevSpace, makes sharing dev clusters much easier and safer. Learn more about DevSpace Cloud.
Speed Up Cloud-Native Development
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.
Automate Repetitive Tasks
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.
Works with Any Kubernetes Clusters
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. Thanks a ton!
DevSpace runs as a single binary CLI tool directly on your computer and ideally, you use it straight from the terminal within your IDE. DevSpace does not require a server-side component as it communicates directly to your Kubernetes cluster using your kube-context, just like kubectl.
Stop wasting time for running the same build and deploy commands over and over again. Let DevSpace automate your workflow and build cloud-native applications directly inside Kubernetes.
Automated Image Building with devspace build
- 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
Automated Deployment with devspace deploy
- 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
Efficient In-Cluster Development with devspace dev
- 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
Feature-Rich Localhost UI with devspace ui
- 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
Convenience Commands for Kubernetes
- 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 enterto open a Interactive Terminal Sessiondevspace logs/devspace logs -ffor Fast, Real-Time Logs (optionally streaming new logs)devspace syncfor quickly starting a Bi-Directional, Real-Time File Synchronization on demand
- Automatic Issue Analysis via
devspace analyzereporting 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 contextshows a list of contexts (select to set current kube-context)devspace use namespaceshows a list of namespaces (select to set defaut namespace for current context)devspace remove contextshows a list of contexts (select to remove a kube-context)
Powerful Configuration
- 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
Lightweight & Easy to Setup
- Client-Only Binary (server-side DevSpace Cloud is optional for visual UI and team management)
- 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 Cloud: Server-Side Add-On (optional)
- 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.
More info and install intructions for DevSpace Cloud on: www.github.com/devspace-cloud/devspace-cloud
via NPM
npm install -g devspace
via Yarn
yarn global add devspace
via Mac Terminal
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;
via Linux Bash
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
via Windows Powershell
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
PATHvariable will be applied.
| Project | Command |
|---|---|
| Node.js | git clone https://github.com/devspace-cloud/quickstart-nodejs && cd quickstart-nodejs |
| Python | git clone https://github.com/devspace-cloud/quickstart-python && cd quickstart-python |
| Java | git clone https://github.com/devspace-cloud/quickstart-java && cd quickstart-java |
| Ruby | git clone https://github.com/devspace-cloud/quickstart-ruby && cd quickstart-ruby |
| Golang | git clone https://github.com/devspace-cloud/quickstart-golang && cd quickstart-golang |
| PHP | git clone https://github.com/devspace-cloud/quickstart-php && cd quickstart-php |
| ASP.NET | git clone https://github.com/devspace-cloud/quickstart-asp-dotnet && cd quickstart-asp-dotnet |
Want to use DevSpace with your own project?
cd /path/to/my/project/rootIf you are using DevSpace for the first time, we recommend to get started with one of the demo projects listed above.
Initializing a project will create the configuration file devspace.yaml which tells DevSpace how to deploy your project.
devspace initTake a look at the Configuration Examples to learn more about
devspace.yaml
Choose the cluster, you want to deploy your project to. If you are not sure, pick the first option. It is very easy to switch between the options later on.
Hosted Spaces sponsored by DevSpace (managed Kubernetes namespaces)
FREE for one project, includes 1 GB RAM
devspace create space my-app # requires login via GitHub or emailDevSpace automatically sets up a kube-context for this space, so you can also access your isolated namespace using
kubectl,helmor any other Kubernetes tool.
Your own local cluster
works with any local Kubernetes cluster (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:
# Tell DevSpace which namespace to use (will be created automatically during deployment)
devspace use namespace my-namespaceYour own remote cluster
works with any remote Kubernetes cluster (GKE, EKS, AKS, bare metal etc.)
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-namespaceTo share a cluster, connect it to DevSpace Cloud and then create an isolated Kubernetes namespace.
# Connect your cluster to DevSpace Cloud
devspace connect cluster # requires login via GitHub or email
# Create an isolated Kubernetes namespace in your cluster via DevSpace Cloud
devspace create space my-namespaceDevSpace automatically sets up a kube-context for every space you create, so you can also access your isolated namespace using
kubectl,helmor any other Kubernetes tool.
What is DevSpace Cloud?
DevSpace Cloud is the optional server-side component for DevSpace that allows you to connect any Kubernetes cluster and then share it with your team for development. DevSpace Cloud lets developers create isolated Kubernetes namespaces on-demand and makes sure that developers cannot break out of their namespaces by configuring RBAC, network & pod security policies etc.
You can either
- use the fully managed SaaS edition of DevSpace Cloud
- or run it on your clusters using the on-premise edition available on GitHub.
How are Spaces isolated? Why is it safe to share a cluster?
DevSpace Cloud makes sure that developers cannot break out of their namespaces by configuring RBAC, network policies, pod security policies etc. By default, these restrictions are very strict and do not even allow pods from different namespaces to communicate with eather other. You can configure every security setting that DevSpace Cloud enforces using the UI of DevSpace Cloud and even set custom limits for different members of your team.
How can I add my team mates, so we can share this cluster?
- Connect your cluster to DevSpace Cloud using
devspace connect cluster - Go to Clusters in the UI of DevSpace Cloud: https://app.devspace.cloud/clusters
- Click on your cluster
- Go to the Invites tab
- Click on the Add Invite button
- Click on the invite link in the table and send the link to a team mate
- After clicking on the link and defining an encryption key, your team mate will be able to create isolated namespaces.
It it safe to connect my cluster to DevSpace Cloud?
Yes. When connecting a cluster to DevSpace Cloud, the CLI tool asks you to define an encryption key. The cluster access token that the CLI creates will be encrypted with a hashed version of this key before sending it to DevSpace Cloud. That makes sure that no one can access your cluster except you. This key is hashed and stored on your local computer. That means that:
- If you use DevSpace from a different computer, you will have to enter the encryption key again or re-connect the cluster which generates a new access token and encrypts it with a new key.
- If you add a team member, you will have to send them a secure invite link which makes sure that they also get cluster access. This procedure is very safe and your key is never sent to our platform. After clicking on the invite link, your colleagues will define a separate encryption key for secure access to their namespaces.
If you are still hesitant, you can run DevSpace Cloud in your own Kubernetes cluster using the on-premise edition: https://github.com/devspace-cloud/devspace-cloud
Can I run DevSpace Cloud on-premise in my own cluster?
Yes. Follow these intructions to run DevSpace Cloud yourself:
1. Install DevSpace Cloud
See www.github.com/devspace-cloud/devspace-cloud for instructions.
2. Tell DevSpace to use your self-hosted DevSpace Cloud
devspace use provider devspace.my-domain.com3. Connect a Kubernetes cluster to your self-hosted DevSpace Cloud
devspace connect cluster4. Create an isolated namespace
devspace create space my-app
The most important command in DevSpace starts the development mode and lets you directly code within your Kubernetes cluster using terminal proxy, port forwarding and real-time code synchronization.
devspace devYou can now:
- Access your application via
http://localhost:PORTin your browser - Edit your source code files and DevSpace will automatically synchronize them to the containers running in Kubernetes
- Use a hot reloading tool like
nodemonand your application will automatically reload when you edit source code files
Run
devspace dev -ito use interactive mode: overrides your DockerfileENTRYPOINTwith[sleep, 999999]and opens the terminal proxy, so you can manually run the start command for your application, e.g.npm start. Interactive mode is great for debugging containers that keep crashing or starting an application in hot reloading mode when the Dockerfile ENTRYPOINT generally starts a rather production-like version of the application.
When running devspace dev, DevSpace starts a client-only UI for Kubernetes. You can see that in the output of devspace dev which should contain a log line similar to this one:
#########################################################
[info] DevSpace UI available at: http://localhost:8090
#########################################################By default, DevSpace starts the development UI on port 8090 but if the port is already in use, it will use a different port.
You can access the development UI once you:
- open the link from your
devspace devlogs in the browser, e.g. http://localhost:8090 - run the command
devspace ui(e.g. in a separate terminal parallel todevspace dev)
Once the UI is open in your browser, it will look similar to this screenshot:
Initializing a project will create the configuration file devspace.yaml which tells DevSpace how to deploy your project.
devspace deploy -p productionThe -p / --profile flag tells DevSpace to apply a certain profile defined in your devspace.yaml. A profile changes the base configuration by, for example, applying config patches. This allows you to have one base configuration and adapt it for different deployment targets and environment (e.g. dev as base config and a profile for production).
Having issues? Take a look at the Troubleshooting Guides and learn how to fix common issues.
You can now open your application in the browser using the following command:
devspace openWhen DevSpace asks you how to open your application, choose the first option "via localhost" because it will work no matter what cluster you are using.
If you want to connect a domain, check out our guide on how to connect a domain by creating an ingress with DevSpace.
Congratulations! You just deployed your first project to Kubernetes using DevSpace.
Follow these links to more about how to use DevSpace:
- DevSpace Tutorials (for different languages and frameworks)
- Onboarding Guide
- How to use the Localhost UI of DevSpace
- How to connect a domain by creating an ingress
- How to integrate DevSpace in your CI/CD pipeline
- How to troubleshoot common issues
| Command | Important Flags / Notes |
|---|---|
devspace devStarts the development mode |
-b • Rebuild images (force) -d • Redeploy everything (force) -i • Interactive mode (overrides ENTRYPOINT with [sleep, 999999] and starts interactive terminal session) |
devspace uiOpens the localhost development UI |
|
devspace openOpens your application after starting port-forwarding or generating an ingress |
|
devspace enterOpens a terminal session for a container |
|
devspace enter -- [command]Runs a command inside a container |
|
devspace logs Prints the logs of a container |
-f • Stream logs (follow/attach) |
devspace analyze Analyzes your namespace for issues |
|
devspace build Build, tag and push images (no deploy) |
-t [TAG] • Use specified [TAG] to tag all images |
devspace cleanup images Deletes old images (locally, built by DevSpace) |
This is very useful after you built a lot of images and your local Docker daemon runs out of space (error: no space left on device) |
devspace attach Attaches to a running container |
Requires stdin and tty to be true |
devspace use space [NAME] Switch into a different (existing) Space |
If you do not provide a [NAME], DevSpace will show a selector with a list of all your Spaces. |
devspace use namespace [NAME] Switch to a different namespace |
If you do not provide a [NAME], DevSpace will show a selector with a list of available namespaces. |
devspace use context [NAME] Switch to a different kube-context |
If you do not provide a [NAME], DevSpace will show a selector with a list of available kube-contexts. |
You can configure DevSpace with the devspace.yaml configuration file that should be placed within the root directory of your project. The general structure of a devspace.yaml looks like this:
# File: ./devspace.yaml
version: {config-version}
images: # DevSpace will build these images in parallel and push them to the respective registries
{image-a}: ... # tells DevSpace how to build image-a
{image-b}: ... # tells DevSpace how to build image-b
...
deployments: # DevSpace will deploy these [Helm charts | manifests | ... ] one after another
- {deployment-1} # could be a Helm chart
- {deployment-2} # could be a folder with kubectl manifests
...
dev: # Special config options for `devspace dev`
ports: ... # Configure port-forwarding
open: ... # Configure auto-open for opening URLs after starting development mode
sync: ... # Configure file synchronization
logs: ... # Configure multi-container log streaming
autoReload: ... # Tells DevSpace when to redeploy (e.g. when a manifest file has been edited)
interactive: ... # Customize Interactive Mode (devspace dev -i)
dependencies: # Tells DevSpace which related projects should be deployed before deploying this project
- {dependency-1} # Could be another git repository
- {dependency-2} # Could point to a path on the local filesystem
...
vars: # Make your config dynamic and easier to share (ask a question if env var is not defined)
- name: DOMAIN_NAME # Will be used as ${DOMAIN_NAME} in config
question: Which hostname should we use for the ingress?
profiles: # Configure different profiles (e.g. dev, staging, prod, debug-backend)
- name: debug-backend
patches: # Change the config with patches when this profile is active
- op: replace
path: images.default.entrypoint
value: [npm, run, debug]
commands: # Custom commands: define reusable commands and run them via: devspace run [command-name]
- name: debug-backend # The best way to share your workflows with other team mates
command: devspace dev -i --profile=debug-backend
hooks: # Customize all workflows using hooks
- command: echo
args:
- "before image building"
when:
before:
images: allSee an example of a devspace.yaml config file
# 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-serverThe following sections show code snippets with example sections of a devspace.yaml for certain use cases.
Build images 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
createPullSecret: true # Create a Kubernetes pull secret for this image before deploying anything
webserver:
image: dscr.io/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.
Build images with kaniko (inside a Kubernetes pod)
# 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: dscr.io/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=./webserverTake a look at the documentation for more information about building images with kaniko.
Build images with custom commands and scripts
# 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: dscr.io/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=./webserverTake a look at the documentation for more information about using custom build scripts.
Deploy components
# 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:
Deploy Helm charts
# File: ./devspace.yaml
deployments:
- name: default
helm:
chart:
name: redis
version: "6.1.4"
repo: https://kubernetes-charts.storage.googleapis.comLearn more about:
Deploy manifests with kubectl
# File: ./devspace.yaml
deployments:
- name: my-nodejs-app
kubectl:
manifests:
- manifest-folder/
- some-other-manifest.yamlLearn more about:
Deploy manifests with kustomize
# File: ./devspace.yaml
deployments:
- name: my-deployment
kubectl:
manifests:
- my-manifests/
- more-manifests/
kustomize: trueTake a look at the documentation for more information about deploying manifests with kustomize.
Define multiple deployments in one project
# 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.comDevSpace 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.
Define dependencies between projects (e.g. to deploy microservices)
# 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: productionBefore 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.
Configure code synchronization
# 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
./srcwill be synchronized to the container's working directory.(specified in the Dockerfile) ./src/node_moduleswould not be uploaded to the container
Take a look at the documentation to learn more about configuring file synchronization during development.
Redeploy instead of synchronizing code
# 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.
Use config variables
# File: ./devspace.yaml
images:
default:
image: ${DEVSPACE_USERNAME}/image-name
tags:
- ${DEVSPACE_GIT_COMMIT}-${DEVSPACE_TIMESTAMP}
- latestDevSpace 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.
Define config profiles and patches
# 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/cacheDevSpace 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.
Define hooks
# File: ./devspace.yaml
hooks:
- command: echo
args:
- "before image building"
when:
before:
images: allThe 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.
My application is not working
This problem can be caused by many different things.
There is no single solution for this but here are some steps to troubleshoot this problem:
Run this command within your project:
devspace analyze
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 -iWith 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.
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
DevSpace hangs at [wait] Logging into cloud provider...
DevSpace tries to open a browser window, so you can login to DevSpace Cloud (either our SaaS platform or the self-hosted version that you installed in your cluster). If you are using a terminal inside a Docker container or VM, DevSpace is not able to open a browser window. You have two options to work around this:
Run DevSpace on your local machine where you have a browser installed.
Generate an access key and login with the non-interactive login method. Follow these steps:
- Open this page: https://app.devspace.cloud/settings/access-keys (for on-premise version: https://[my-devspace-cloud-url]/settings/access-keys)
- Click on the button "Create Key".
- Enter a name (e.g. my-access-key).
- Click on "Create Access Key".
- Copy the access key displayed within the input field.
- Login via
devspace login --key=[YOUR_ACCESS_KEY] - Try the command again that you originally wanted to execute.
Cloud Authentication: get token: Received invalid token from provider
This might happen when you are using an on-premise install of DevSpace Cloud and the VM of your Kubernetes cluster (e.g. Docker VM for Kubernetes in Docker Desktop) has the wrong date/time.
Make sure the VM of your local Kubernetes cluster has the correct date/time. For local clusters created with 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"Docker: Error response from daemon: Get https://[registry]/v2/: x509: certificate has expired or is not yet valid
This might happen when you the VM of your Docker daemon has the wrong date/time.
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"Help us make DevSpace the best tool for developing, deploying and debugging Kubernetes apps.
If you find a bug while working with the DevSpace, please open an issue on GitHub and let us know what went wrong. We will try to fix it as quickly as we can.
You are more than welcome to open issues in this project to:
This project is mainly written in Golang. If you want to contribute code:
- Ensure you are running golang version 1.11.4 or greater for go module support
- Set the following environment variables:
GO111MODULE=on GOFLAGS=-mod=vendor - Check-out the project:
git clone https://github.com/devspace-cloud/devspace && cd devspace - Make changes to the code
- Build the project, e.g. via
go build -o devspace[.exe] - Evaluate and test your changes
./devspace [SOME_COMMAND]
See Contributing Guideslines for more information.
What is DevSpace?
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.
Is DevSpace free?
YES. DevSpace is open-source and you can use it for free for any private projects and even for commercial projects.
What is DevSpace Cloud?
DevSpace Cloud extends DevSpace with a server-side component. It is entirely optional and meant for cluster admins that want to enable their developers to create isolated Kubernetes namespaces on-demand within a development cluster. DevSpace Cloud lets you easily manage cluster users, enforce resource limits and make sure developers can share a dev cluster without getting in the way of each other.
Even when using DevSpace Cloud, DevSpace directly interacts with the Kubernetes cluster, so you code or commands will never go through DevSpace Cloud.
Is DevSpace Cloud free?
YES. DevSpace Cloud has a free tier depending on how you use it:
- You can use the SaaS edition and create 1 Hosted Space for free.
- You can use the SaaS edition and connect 1 Kubernetes cluster and add up to 3 developers to this cluster for free.
- You can install the on-premise edition and use it with up to 10 developers for free.
What is a Space?
Spaces are isolated Kubernetes namespaces which are managed by DevSpace Cloud and which provide the following features:
- Automatic provisioning via
devspace create space [SPACE_NAME] - Automatic allocation of a subdomain for each Space, e.g.
my-app.devspace.host - Automatic RBAC configuration for better isolation of users
- Automatic resource limit configuration and enforcement
- Dynamic resource auto-scaling within the configured limits
Do I need a Kubernetes cluster to use DevSpace?
No. You can simply use the fully managed Hosted Spaces provided by the SaaS version of DevSpace Cloud. You can create 1 Hosted Space for free.
Can I use DevSpace with my existing Kubernetes clusters?
Yes. You have multiple options:
- Use DevSpace with your current kube-context (not using DevSpace Cloud at all).
- Using the SaaS version of DevSpace Cloud and connect your existing Kubernetes clusters to DevSpace Cloud as external clusters (available soon). DevSpace Cloud will then be able to automatically manage cluster users and permissions. This lets you created isolated namespaces (Spaces) within your Kubernetes clusters.
- Run DevSpace Cloud on-premise and connect your Kubernetes cluster to it in the same way you would use the SaaS version of DevSpace Cloud.
What is a Helm chart?
Helm is the package manager for Kubernetes. Packages in Helm are called Helm charts. Learn more about Helm charts.
You can use the DevSpace for any private or commercial projects because it is licensed under the Apache 2.0 open source license.