DevSpace: a client-only CLI for developing inside Kubernetes

The problem DevSpace targets: Kubernetes work that lives in people's heads

The README states the problem in its own words: building distributed microservices on Kubernetes is hard, and harder still for large teams. The repeated cost is not the cluster itself but the sequence of steps around it. Someone builds an image, tags it, pushes it, applies a manifest, waits for a rollout, finds the pod name, starts a port-forward, then starts streaming logs. Every developer repeats that sequence, and every one of them does it slightly differently.

DevSpace's answer is to move that sequence into a declarative file, devspace.yaml, which the README says should be committed via git. The stated benefit is that a Kubernetes expert on the team writes the workflow once, and everyone else runs devspace deploy to get a running instance of the project, including image building and deployment of related projects. The README also notes that the configuration is dynamic through config variables, so one base file can still allow per-developer differences such as different sub-domains for testing.

That framing tells you who this is for. It is for teams where Kubernetes knowledge is unevenly distributed and where the deployment steps are currently tribal knowledge. It is less obviously for a solo developer on a local cluster, where the same commands are short enough to type by hand.

A single binary that uses your kube-context instead of a cluster-side agent

The architecture section of the README is short and specific: DevSpace runs as a single binary CLI on your computer, is meant to be used from the terminal inside your IDE, and has no server-side component. It communicates directly with the Kubernetes cluster using your kube-context, the same way kubectl does. The repository layout matches that claim: main.go and cmd/ at the top level, with the bulk of the logic under pkg/, and a vendor/ directory, which is consistent with a Go project that ships a compiled binary rather than an in-cluster controller.

The part that does the visible work is file synchronization. The README describes a bi-directional file synchronization path that detects code changes and moves files between your local environment and the containers running in Kubernetes, so the container updates without rebuilding an image or restarting. That is the hot-reload loop: you edit with your IDE, and the running container picks the change up. The same command surface is used for streaming logs, connecting debuggers and opening a container terminal.

Builds are not fixed to one mechanism. The examples/ directory contains separate directories for buildkit, buildkit-in-cluster, kaniko, custom-builder, kustomize and inlineManifest, which indicates that the image-building backend is a configuration choice rather than a hardcoded path. That matters if your cluster forbids running a build daemon: kaniko and in-cluster buildkit exist as options, and a custom builder is available when neither fits.

One consequence of the client-only design is worth stating plainly. Because there is no server-side component, nothing runs when your laptop is closed. DevSpace is a development-time tool, not a deployment controller, and the README does not present it as one.

Installing DevSpace and getting a first deploy out of it

The README does not carry installation commands. The Quickstart section points at an external getting started guide at devspace.sh/docs/getting-started/installation, and that page is the authoritative source for the install step on your platform. The repository does show one container-based path: the Dockerfile installs kubectl and then downloads a release binary named devspace-linux-amd64 from the GitHub releases of loft-sh/devspace, using a RELEASE_VERSION build argument that defaults to latest.

FROM alpine:3 as alpine

ARG RELEASE_VERSION=latest

RUN apk add --update-cache curl tar docker git

RUN curl -L -o /bin/kubectl https://storage.googleapis.com/kubernetes-release/release/v1.17.3/bin/linux/amd64/kubectl \
 && chmod +x /bin/kubectl

RUN curl -s -L "https://github.com/loft-sh/devspace/releases/download/$RELEASE_VERSION/devspace-linux-amd64" -o /bin/devspace \
 && chmod +x /bin/devspace

Read that file carefully before reusing it. It pins kubectl to v1.17.3, an old release, and the image is built FROM alpine:3, which is not a pinned tag. It is a working recipe for a container that carries the binary, not a recommendation for your local machine.

Once the binary is on your PATH, the README's description of the daily loop is two commands. The first deploys the project, including image building and any dependencies the configuration declares:

devspace deploy

The second starts the development loop, which is where the hot reloading described in the README takes over:

devspace dev

The README does not spell out the flags for either command, so treat the getting started guide as the place to confirm the exact invocation for your project. What you should expect from devspace deploy is a running instance of the application, built and applied through the workflow in devspace.yaml rather than through commands you typed yourself.

If you want a starting point rather than a blank file, the repository ships examples/. The directory listing includes quickstart, quickstart-kubectl, microservices, dependencies, kaniko, kustomize, kind, spring-boot-mysql and php-mysql-example, along with two that name a trade-off directly: hot-reload-container-restart and redeploy-instead-of-hot-reload. Those last two are the clearest signal in the repository that hot reloading is a mode you choose, not a default that always applies.

Where DevSpace stops being the right tool

The client-only design has a boundary, and the README draws it without dressing it up. If you want the deployment to keep reconciling after you close your laptop, DevSpace is not that. There is no server-side component to keep watching the cluster, and nothing in the README claims otherwise.

The second limitation is documentation shape. The README is a landing page: it explains why the tool exists, shows a workflow diagram, and links out. It does not contain the installation steps, it does not list command flags, and it does not document rollback. If your evaluation process depends on reading a single repository file end to end, you will not complete it here. You will be reading devspace.sh.

The third is the build path. DevSpace will build images as part of a deploy, which means the machine running it needs a working build route: a local daemon, in-cluster buildkit, kaniko, or a custom builder. In clusters with tight pod security policies or no permission to run build workloads, that route may not exist, and the fix is configuration work rather than a flag.

Finally, hot reloading itself is conditional. The presence of a redeploy-instead-of-hot-reload example in the repository is the honest version of this: for some languages and some file types, restarting or redeploying is the practical answer, and the configuration has to say so.

How DevSpace differs from Tilt, Skaffold and Telepresence

The comparison that matters is not feature counts but where the configuration lives and what runs where.

Skaffold is also a client-side CLI driven by a YAML file, and it also builds and deploys. The difference in emphasis is that Skaffold's configuration centers on the build-and-deploy pipeline stages, while DevSpace's devspace.yaml is presented in the README as a place to codify broader workflow knowledge, including dependencies and per-developer variables, with the dev loop as a first-class command alongside deploy. If your need is a pipeline definition, Skaffold's shape is closer to it; if your need is a shared developer workflow, DevSpace's is.

Tilt and DevSpace both target the inner loop, and both aim to remove the rebuild-redeploy cycle. Tilt's model is a long-running local process that watches your files and serves a UI for the state of each service. DevSpace's README describes commands you run in the terminal inside your IDE, with file synchronization into the running container. The practical difference is whether you want a dashboard process supervising the loop or a command you invoke.

Telepresence solves a different problem. It intercepts traffic so a locally running process can stand in for a workload in the cluster, which is useful when you need the real cluster's dependencies but want the code running on your machine. DevSpace does the opposite: it pushes your code into the cluster and runs it there. If your constraint is a service that cannot run locally because of its dependencies, Telepresence addresses that; DevSpace does not.

Okteto occupies similar ground with a different deployment model, and the README itself points readers at loft.sh for teams that want a shared development cluster. That is a candid admission that the hard part, giving every developer on-demand cluster access, is outside DevSpace's scope.

Licence, maintenance and what an upgrade costs you

DevSpace is licensed under Apache-2.0, and the README carries an OpenSSF Best Practices badge. Apache-2.0 is a permissive licence with an explicit patent grant, and it permits commercial use, modification and redistribution provided the licence and notices are preserved. It does not impose copyleft obligations on your own code. This is a description of the licence text, not legal advice; if you are redistributing a modified DevSpace, have your own counsel read the terms.

The repository is not archived, and the last push was on 2026-09-06, which is recent. Recent releases are v6.3.19 on 2026-04-23 and two release candidates, v6.4.0-rc.0 and v6.4.0-rc.1, on 2026-04-28 and 2026-04-30. The presence of release candidates indicates an active release process, but it also tells you something about upgrade timing: the v6.4.0 line was still at rc when those were published, so a team that tracks stable releases would sit on v6.3.19 rather than take the candidate.

The upgrade cost is not in reinstalling a binary. It is in devspace.yaml. Because the file encodes your build, deploy and dev-loop configuration, a version bump that changes a config key is a change to a file your whole team depends on. The repository ships devspace-schema.json at the top level, which is what an editor uses to validate that file, so schema drift between your installed binary and your editor is a concrete thing to check when you upgrade. The CHANGELOG.md at the repository root is the file to read before moving a team across versions.

Editorial conclusion

Adopt DevSpace if your team already runs Kubernetes and you want the build, deploy and hot-reload steps written into a devspace.yaml that is committed next to the code, so a new developer runs one command instead of ten. Skip it if you need a tool whose installation and rollback paths are documented in the repository README itself, or if your workflow has no Kubernetes cluster to target. Before committing, verify three things: that the installation page linked from the README matches your platform, that your cluster allows the image builds DevSpace will run, and that devspace.yaml is reviewed like application code, because it is the only place your deployment workflow is written down.

Frequently asked questions

Official sources

1. devspace-sh/devspace on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases