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.

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.

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.