Kubernetes Development Tools Comparison - Skaffold vs. DevSpace vs. Draft vs. CodeReady vs. Bridge
Harshit Mehndiratta
Harshit Mehndiratta
October 18, 2020
7 minutes read

Kubernetes Development Tools Comparison - Skaffold vs. DevSpace vs. Draft vs. CodeReady vs. Bridge

It is true that Kubernetes and containerization has solved many challenges that businesses face today when it comes to scaling and complexity of projects or reliability of the release of new versions. But, it has also posed additional challenges for developers by introducing operational complexity into their development workflow.

Developers developing apps in Kubernetes are required to work with Kubernetes components like containers, pods, and deployments, which decreases their performance, elegancy, and quality of code.

Developers want to focus more on the logic of application than the deployment of Kubernetes pods, which is why the market has seen a lot of new Kubernetes development tools.

Developers deploy Kubernetes development workflows so they can quickly deploy applications to a Kubernetes cluster. These tools ease the developer’s work by automating the deployment process, defining applications, handling new versions, roll-outs, and different clusters.

In this blog, let’s take a quick look at some of the most popular Kubernetes development tools and how they make application development in Kubernetes easy.


Skaffold is an open-source Kubernetes development tool released by Google to help developers accelerate their development workflow on Kubernetes. Skaffold provides code iteration features for deployment to either a local machine or remote cluster, facilitating a continuous development experience for Kubernetes applications.

In Skaffold, the CLI tool tracks changes in users’ local code directories and automatically builds and deploys application images to remote and local Kubernetes clusters. By automating this procedure of container development workflow, Skaffold promotes time savings, potentially increasing the application production quality.

Skaffold provides seamless CI integrations with different sets of build systems, deployment, and registry tools, which means users can configure additional settings to support various pipelines/workflows for each target environment.

Skaffold has a pluggable architecture, allowing users to support existing tooling and workflows to build and deploy different implementations of the stages and build profiles.

Skaffold workflows are configured declaratively in the YAML file by defining specific parameters for building and deploying stages. For example, Skaffold can be configured to use any basic image during the development phase while changing it to an efficient image for staging and production.

Skaffold supports different tagging strategies for container images, which are pushed into registry: users can use git commit hashes, date/time values, SHA256 hashes to easily trace back a container image in a specific point in time.

Also noteworthy is Skaffold’s ability to test containers using a container-structure-test framework that provides various automated validation methods for container images.

Skaffold is used in two different modes: deployment and development. Development mode monitors the code changes and generates appropriate docker images through artifacts. In contrast, in deployment mode, Skaffold runs a pipeline which exits if any error in the dependencies is detected. Deployment mode is also helpful when users have to check the pipeline’s soundness after the development of the application.

Artifacts generation in Skaffold automatically happens when the tool detects code changes. The artifact block handles real-time deployment automation and generates artifacts through Jib and Bazel.

Skaffold also supports the debugging of Python, Java, and node js code. The debug command implements a develop-and-deploy loop, enabling port forwarding to local machines. That makes the management of configuration changes dynamic and simple for developing native applications.


Draft is an open-source tool developed by Microsoft Azure to help developers quickly built and deploy Kubernetes applications. Draft was launched by Microsoft in 2017 following the acquisition of container platform Deis, a company known for building and managing applications for Kubernetes.

The goal behind the Draft is to help development teams code faster by providing single-command features for deployment and development. When a user runs the Draft tool, the Draft CLI automatically discovers the user’s code and generates the appropriate configuration files. In addition to configuration files that help developers create their applications, Draft also deploys a server into the Kubernetes cluster for automatically syncing your workstation code.

After the automatic detection of the coding language used, Draft makes use of an appropriate pack, which contains a combination of Dockerfile and Helm chart for defining the environment for a particular application.

Packs in Draft can be defined and distributed in repos. Initially, Draft comes with packs that identify docker files and manifests for a wide range of programming languages such as Python, Node, .NET, GO, and Ruby.

Draft also supports extensible pack architecture, allowing developers to code their own packs and repos based on the application’s needs. Once the custom or defined packs identify the coding language, packages are used automatically to generate a Helm chart through a draft create command.

Once the directory is setup using draft create command, Draft can build the resulting docker image and push it to a registry and roll it out via Helm chart.

Port forwarding is also made available through the Draft, which can forward connections to your local system and stream container logs. It can also integrate well with Nginx-ingress, which provides domain names to deployed applications.


DevSpace is another open-source Kubernetes developer tool that provides tons of built-in features for speeding up application development in Kubernetes. Unlike Draft and Skaffold, DevSpace allows automation of the build and deployment of container images and helps increase in-cluster development efficiency.

Development in DevSpace can be initialized by connecting a remote Kubernetes cluster and local dev environment, allowing the creation of container build, pushing images to the repository, and building deployment to the cluster setting up port forwarding and workspace synchronization.

After initialization, deployment commands will deploy the desired infrastructure and application to the container through a YAML configuration file, which can be edited later to add predefined components such as Helm Charts PostgreSQL DBMS.

Adding components into DevSpace makes use of flags, which are very easy to add to a YAML file for the deployment of database management systems. There is no need to define or manage dependency components on a per-application basis as Devspace centralizes all the deployments into their own repositories so they can be managed in a single place.

Every repository has its own devspace.yaml file for deploying a specific infrastructure before deploying any micro-services. When any code changes have to be made, the developer simply navigates into this repo and commits code changes. All the major container configuration will be deployed automatically for your application without creating any Helm charts and managing any database configuration files.

With DevSpace, developers can also make a check on dependencies before they are deployed. If any dependencies don’t exist, DevSpace will exhibit a failed response.

RedHat CodeReady

CodeReady is another Kubernetes dev tool introduced by RedHat to accelerate application development. A key feature of CodeReady Workspace is the ability to work as a browser-based Kubernetes native IDE for rapid cloud-based application development.

CodeReady seamlessly integrates with the OpenShift container platform, making it the only IDE to run inside Kubernetes while managing the dependencies and code of OpenShift pods and containers.

Like many other Kubernetes dev tools, CodeReady is based on a free open-source tool, Eclipse Che, but wrapped as a RedHat offering providing great support and stability to synchronize application code between the local development environment and containers running on remote Kubernetes clusters.

CodeReady allows for faster application development and debugging by providing a Kubernetes native environment/runtime to develop applications.

Unlike other Developer IDE’s in which developers are used first to build containers and then deploy to Kubernetes. In CodeReady, developers are coding by default inside a Kubernetes pod container. They have no choice but to be inside a Kubernetes native environment.

Out of the box, CodeReady supports various languages, such as Java for Red Hat Linux, C/C++, Python, PHP, and Node.js. It also offers better security by storing everything inside a developer’s chosen IDE via SSH, allowing encryption of data so attackers cannot access your code.

The integration of new developers into the CodeReady workflow is also straightforward since the developer’s environment is cloned inside the pod instead of the local machine, which uses a factory template containing the generic details and a list of tools project needs.

Microsoft Bridge

Earlier known as Local Process with Kubernetes, Bridge to Kubernetes is another Kubernetes dev tool made by Microsoft, which helps developers accelerate application development by writing and testing code in Visual Studio workstation while inheriting dependencies from the Kubernetes environment.

Bridge to Kubernetes is offered in Visual Studio to simplify microservice development by eliminating the need to manually source, configure code on your development workstation from the Kubernetes cluster. All the volumes, variables are inherited automatically from the cluster and are accessible to your microservice code locally.

Bridge to Kubernetes promotes app development by decreasing the need to deploy containers and Kubernetes configuration. All the operational complexities required to test code in the Kubernetes cluster are not needed while utilizing Bridge to Kubernetes. Developers can easily run code locally on a laptop while testing in the context of a larger containerized application.

Bridge to Kubernetes supports an isolated work environment by choosing the isolated mode during configuration. This isolated mode will set up a particular subdomain URL to ensure that traffic-utilizing that URL is only diverted to your workstation, enabling developers to work all the more successfully while isolating from the remainder of the group.


If you’re starting off with your Kubernetes app development journey, Draft and Microsoft Bridge for Kubernetes maybe your best option, but if you’re looking forward to developing a complex/micro services-oriented application, you may do better with DevSpace or Skaffold or CodeReady, In our opinion, they are great tools. Still, they are not well suited to be directly used by a developer.