Skip to content

🧰 DevSpace - Cloud-Native Developer Tool for Kubernetes πŸ’‘ Automate your deployment workflow with DevSpace and build applications directly inside Kubernetes.

License

Notifications You must be signed in to change notification settings

masterxavierfox/devspace

Β 
Β 

Quickstart β€’ Examples β€’ Documentation β€’ Slack Β Β Β Β Β Β Β Β Β Β Β Β Β Β 

DevSpace makes it easier and faster to build applications for Kubernetes

  • Build, test and debug applications directly inside Kubernetes
  • Automate repetitive tasks for image building and deployment
  • Unify deployment workflows among developers or across dev, staging and production

DevSpace Demo

Click here to watch the full-length video with explanations on YouTube [4min]

⭐️ Do you like DevSpace? Support the project with a star ⭐️


Contents


Features

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.

Automatic Image Building

  • 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

Automatic 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
  • Terminal Proxy that opens automatically and lets you run commands in your pods directly from your IDE terminal
  • Port Forwarding that lets you access services and pods on localhost and allows you to attach debuggers with ease

Faster Interaction with 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 enter to open a terminal session Fast, Real-Time Log Streaming for all containers you deploy
    • 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)

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 ENTRPOINTs (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, see Architecture)
  • 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)

Management UI for Teams & Dev Clusters (optional, using DevSpace Cloud)

  • Graphical UI for managing clusters, cluster users and user permissions (resource limits etc.)
  • On-Demand Namespace Creation & Isolation with automatic RBAC, network policies, pod security policies 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


Architecture

DevSpace Architecture

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 kubectl context.

You can, however, connect your Kubernetes cluster to DevSpace Cloud to manage cluster users, namespaces and permissions with a central management UI. DevSpace Cloud can either be used as-a-Service on devspace.cloud or installed as an on-premise version (see www.github.com/devspace-cloud/devspace-cloud for instructions).


Quickstart

1. Install

via NPM
npm install -g 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 mv devspace /usr/local/bin;
via Windows Powershell
md -Force "$Env:APPDATA\devspace"; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls,Tls11,Tls12';
wget -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:APPDATA\devspace\devspace.exe" "install"; $env:Path = (Get-ItemProperty -Path HKCU:\Environment -Name Path).Path

2. Choose a Project

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
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
Ruby git clone https://github.com/devspace-cloud/quickstart-ruby && cd quickstart-ruby
Want to use DevSpace with your own project?
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.


3. Deploy

Choose the cluster, you want to deploy your project to. If you are not sure, pick the first option. It is fairly easy to switch between the options listed here.

DevSpace Cloud (fully managed clusters, SaaS version)
Β Β Β  free for one project, includes 1 GB RAM

devspace init
devspace create space my-app
devspace deploy

DevSpace Cloud (connect your own cluster, SaaS version)
Β Β Β  for clusters with public IP address, e.g. Google Cloud, AWS, Azure

devspace connect cluster
devspace init
devspace create space my-app
devspace deploy

DevSpace Cloud (self-hosted version)
Β Β Β  for clusters without public IP address, e.g. bare metal clusters within a VPN

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.com

3. Connect a Kubernetes cluster to your self-hosted DevSpace Cloud

devspace connect cluster

4. Deploy your project

devspace init
devspace create space my-app
devspace deploy

Use current kubectl context (without DevSpace Cloud)
Β Β Β  for local clusters, e.g. minikube, kind, Docker Kubernetes

devspace init
devspace deploy

Having issues? Take a look at the Troubleshooting section and learn about common mistakes.


4. Develop

After successfully deploying your project one, you can start it in development mode and directly code within your Kubernetes cluster using terminal proxy, port forwarding and real-time code synchronization.

devspace dev

DevSpace will deploy your application, wait until your pods are ready and open the terminal of a pod that is specified in your config. You can now start your application manually using a command such as npm start or npm run develop and access your application via localhost:PORT in your browser. Edit your source code files and DevSpace will automatically synchronize them to the containers in your Kubernetes cluster.

If you are using DevSpace Cloud, you can now devspace ui to open the graphical user interface in your browser, stream logs, add new users to your cluster and configure permissions for everyone on your team.


5. Learn more

Show useful commands for development
CommandΒ Β Β Β Β Β Β Β Β Β  Important flags
devspace dev
Starts the development mode
-b β€’ Rebuild images (force)
-d β€’ Redeploy everything (force)
devspace enter
Opens a terminal session for a container
-p β€’ Pick a container instead of using the default one
devspace enter [command]
Runs a command inside a container
devspace logs
Prints the logs of a container
-p β€’ Pick a container instead of using the default one
-f β€’ Stream new logs (follow/attach)
devspace analyze
Analyzes your deployments for issues
Show how to use multiple Spaces and switch between them

Whenever you run devspace create space [space-name] within a project, DevSpace will set this newly created Space as active Space which is used for devspace deploy and devspace dev.

If you have multiple Spaces (e.g. to test different versions of your app or separate staging from production), you can use the following commands to list Spaces and switch between them:

devspace list spaces
devspace use space [space-name]


Configuration Examples

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 chart | manifest | ... ] 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`
  overrideImages: ...   # Apply overrides to image building (e.g. different Dockerfile or different ENTRYPOINT)
  terminal: ...         # Config options for opening a terminal or streaming logs
  ports: ...            # Config options for port-forwarding
  sync: ...             # Config options for file synchronization
  autoReload: ...       # Tells DevSpace when to redeploy (e.g. when a manifest file has been edited)

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
  ...
Show me an example of a devspace.yaml config file
# File: ./devspace.yaml
version: v1beta2

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

deployments:
- name: quickstart-nodejs               # Name of this deployment
  component:                            # Deploy a component (alternatives: helm, kubectl)
    containers:                         # Defines an array of containers that run in the same pods started by this component
    - 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

dev:
  overrideImages:
  - name: default
    entrypoint:
    - sleep
    - 9999999
  ports:
    forward:
    - port: 8080
      remotePort: 80
    - port: 3000
    labelSelector:
      app.kubernetes.io/component: default
      app.kubernetes.io/name: devspace-app
  sync:
  - localSubPath: ./src
    containerPath: .
    labelSelector:
      app.kubernetes.io/component: default
      app.kubernetes.io/name: devspace-app
  autoReload:
    paths:
    - ./manifests/**

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

The following sections show code snippets with example sections of a devspace.yaml for certain use cases.

Configure Image Building

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 line defines a custom tag schema for this image (default tag schema is: ${DEVSPACE_RANDOM})
    tag: ${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=./webserver

Take 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=./webserver

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

Configure Deployments

Deploy components
# File: ./devspace.yaml
deployments:
- name: quickstart-nodejs
  component:
    containers:
    - image: my-registry.tld/image1
      resources:
        limits:
          cpu: "400m"
          memory: "500Mi"

DevSpace allows you to add predefined components using the devspace add component [component-name] command.

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.com

Learn more about:

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

Learn more about:

Deploy manifests with kustomize
# 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.

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.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.

Define dependencies between projects (e.g. to deploy microservices)
# File: ./devspace.yaml
dependencies:
- source:
    git: https://github.com/my-api-server
- source:
    git: https://myuser:mypass@my-private-git.com/my-auth-server 
- source:
    path: ../my-auth-server
  config: default

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.

Configure Development Mode

Override Dockerfile entrypoint
# File: ./devspace.yaml
images:
  default:
    image: dscr.io/my-username/my-image
dev:
  overrideImages:
  - name: default
    entrypoint:
    - sleep
    - 9999999

When running devspace dev instead of devspace deploy, DevSpace would override the ENTRYPOINT og the Dockerfile with [sleep, 9999999] when building this image.

Take a look at the documentation to learn more about how DevSpace applies dev overrides.

Use different Dockerfile for development
# File: ./devspace.yaml
images:
  default:
    image: dscr.io/my-username/my-image
dev:
  overrideImages:
  - name: default
    dockerfile: ./development/Dockerfile.development
    # Optional: use different context
    # context: ./development

When running devspace dev instead of devspace deploy, DevSpace would use the dev Dockerfile as configured in the example above.

Take a look at the documentation to learn more about how DevSpace applies dev overrides.

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 ./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.

Stream logs instead of opening the container terminal
# File: ./devspace.yaml
dev:
  terminal:
    disabled: true
    labelSelector:
      app.kubernetes.io/component: default
      app.kubernetes.io/name: devspace-app

Streams the logs of the selected container instead of opening an interactive terminal session.

Take a look at the documentation to learn more about configuring the terminal proxy for 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.

Advanced Configuration

Use config variables
# File: ./devspace.yaml
images:
  default:
    image: ${DEVSPACE_USERNAME}/image-name
    tag: ${DEVSPACE_GIT_COMMIT}-${DEVSPACE_TIMESTAMP}

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.

Define multiple configs
# File: ./devspace-configs.yaml
config1:
  config:
    path: ../devspace.yaml
config2:
  config:
    path: ../devspace.yaml
  overrides:
  - data:
      images:
        database:
          image: dscr.io/my-username/alternative-db-image
config3:
  config:
    path: ../devspace-prod.yaml

If you have complex deployment scenarios which are not easily addressable by dev overrides, you can create a file named devspace-configs.yaml and configure multiple different configurations for DevSpace. They can all use the same underlying base configuration and simply apply certain overrides to sections of the configuration (e.g. config1 and config2) OR they can be entirely different configuration files (e.g. config1 and config3).

You can tell DevSpace to use a specific config file using thit command: devspace use config [config-name]

Take a look at the documentation to learn more about using multiple config files.

Define hooks
# 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.



Troubleshooting

DevSpace hangs at [wait] Logging into cloud provider...

Problem

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:

Solution A

Run DevSpace on your local machine where you have a browser installed.

Solution B

Generate an access key and login with the non-interactive login method. Follow these steps:

  1. Open this page: https://app.devspace.cloud/settings/access-keys (for on-premise version: https://[my-devspace-cloud-url]/settings/access-keys)
  2. Click on the button "Create Key".
  3. Enter a name (e.g. my-access-key).
  4. Click on "Create Access Key".
  5. Copy the access key displayed within the input field.
  6. Login via devspace login --key=[YOUR_ACCESS_KEY]
  7. Try the command again that you originally wanted to execute.


Contributing

Help us make DevSpace the best tool for developing, deploying and debugging Kubernetes apps.

Reporting Issues

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.

Feedback & Feature Requests

You are more than welcome to open issues in this project to:

Contributing Code

This project is mainly written in Golang. If you want to contribute code:

  1. Ensure you are running golang version 1.11.4 or greater for go module support
  2. Set the following environment variables:
    GO111MODULE=on
    GOFLAGS=-mod=vendor
    
  3. Check-out the project: git clone https://github.com/devspace-cloud/devspace && cd devspace
  4. Run go clean -modcache
  5. Run go mod vendor
  6. Make changes to the code
  7. Build the project, e.g. via go build -o devspace.exe
  8. Evaluate and test your changes ./devspace [SOME_COMMAND]

See Contributing Guideslines for more information.


FAQ

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.

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.

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 Spaces provided by the SaaS version of DevSpace Cloud.

Can I use DevSpace with my existing Kubernetes clusters?

Yes. You have multiple options:

  1. Use DevSpace with your current kubectl context (not using DevSpace Cloud at all).
  2. 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.
  3. 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.

About

🧰 DevSpace - Cloud-Native Developer Tool for Kubernetes πŸ’‘ Automate your deployment workflow with DevSpace and build applications directly inside Kubernetes.

Resources

License

Code of conduct

Contributing

Stars

Watchers

Forks

Packages

No packages published

Languages

  • Go 99.2%
  • Other 0.8%