DevSpace CLI
A Kubernetes development workflow combines image builds, deployment and source synchronization in a shared team configuration.
- 5,227 ★ on the repository
- Last commit
- Apache-2.0
Extended access
Why this level
- The CLI modifies Kubernetes applications with the current connection’s permissions and synchronizes container files.
- Port forwarding and container terminals add ways to access the application.
Install
In your terminal, with SkillFoxx CLI
npx skillfoxx add cli/devspace-sh-devspaceDetects the agents on your machine, shows the access level and pins the version.
Other ways to install
Access and checks
How we reviewExtended accessThe tool runs code or makes network calls and only reads external data.
- The CLI modifies Kubernetes applications with the current connection’s permissions and synchronizes container files.
- Port forwarding and container terminals add ways to access the application.
This is third-party code. Review the repository files before installing.
What it does
An engineer defines image builds and application deployment in `devspace.yaml`. The team stores this file beside the code, so a developer can run the prepared workflow through the CLI after checking out the repository. DevSpace contacts the selected Kubernetes cluster from the local machine. During development, the client synchronizes changes between local files and the container in both directions. Developers edit code locally and test it in the application environment. As configured, DevSpace also starts port forwarding, log streaming and a container terminal.
Who it is for. Kubernetes development teams sharing a code-editing and testing loop inside cluster containers.
Good fit when
- A service depends on Kubernetes components and must be tested in the cluster.
- Every source change triggers a long container image rebuild.
- Developers repeat the same build and deployment steps manually.
- Logs and port forwarding should start alongside the shared development environment.
Not a fit when
- The application must run without any Kubernetes cluster.
- The user has read-only access but the workflow requires deployment.
- Local-to-container file synchronization violates environment policy.
Example request
Read devspace.yaml and report the cluster, namespace and workflow actions without deploying yet.Limitations
A local or remote Kubernetes cluster and a working connection are required. DevSpace uses the current kube-context, the connection selected for kubectl; confirm the cluster and namespace before running a workflow. Hot reload depends on the application and synchronization rules, so some changes still require rebuilding. Workflow configuration does not itself provision cluster or external image-registry credentials.
How to disable. Stop DevSpace, synchronization and port forwarding. Deployed applications remain in the cluster and need a separately approved cleanup.
FAQ
How do I install DevSpace?
Quickstart links to the [installation guide](https://devspace.sh/docs/getting-started/installation), which lists `brew install devspace` for Homebrew.
Does DevSpace need a cluster-side component?
DevSpace itself needs no separate server-side component. Set up normal kubectl access to the selected cluster, then prepare `devspace.yaml`.
How do I repeat an existing deployment?
With an approved `devspace.yaml`, `devspace deploy` runs its image builds and deployment, including dependencies. Read the configuration and confirm the target cluster first.
Can I use a local cluster?
Yes. Supported options include kind, minikube and k3s. Point kubectl at it before using the project’s DevSpace configuration.
Where do developer-specific values go?
Use variables in `devspace.yaml`, such as per-developer application addresses. Keep the shared workflow in one file and move varying values into [configuration variables](https://devspace.sh/cli/docs/configuration/variables/basics).
Discussion
No questions or reviews yet.
Related
CLI toolsThe CLI fetches platform-specific developer tools and installs Kubernetes apps for agent-assisted environment setup.
A Rust Kubernetes workspace: desktop app, terminal UI and an MCP server that lets an agent work with your clusters
KubeShark skill: the agent finds the failure mode first, then writes manifests, Helm and Kustomize to official practice with a rollback plan
Warms an isolated box, syncs your working diff into it and runs the suite without touching your machine
The terminal interface presents Docker containers, services and images for user-led investigation with agent assistance.
CLI for full-cycle CI/CD to Kubernetes: image builds, Helm-based deploys and container registry cleanup
README in short
DevSpace can build several images in parallel, tag them and deploy the application with its dependencies.