DevSpace Documentation

DevSpace is a client-only developer tool designed for cloud-native development with Kubernetes. It allows you to build, test, and debug applications directly inside Kubernetes clusters. Key features include:

• Hot Reloading: Updates running containers without rebuilding images or restarting containers via high-performance, bi-directional file synchronization.
• Declarative Workflows: Store all build, deploy, and dependency workflows in a single devspace.yaml file to version and share with your team.
• Automated Tasks: Automates repetitive tasks like parallel image building, automatic tagging, port-forwarding, and log streaming.
• Cluster Compatibility: Works with any Kubernetes cluster accessible via kubectl, including local clusters (minikube, k3s, kind, Docker Desktop) and managed cloud clusters (GKE, EKS, AKS, Digital Ocean).

DevSpace supports several build engines for container image construction. You can explicitly configure which engine to use for a specific image in your devspace.yml configuration.

Supported engines include:

• Docker: Uses the standard Docker daemon.
• Buildkit: Uses the BuildKit backend for advanced features.
• Kaniko: A tool to build container images from a Dockerfile inside a container or Kubernetes cluster without a Docker daemon.
• Custom: Allows you to define your own build logic.

Running devspace init introduces three changes to your project directory:

1. devspace.yaml: The primary configuration file that defines how your project is built, deployed, and developed.
2. devspace_start.sh: A script used to display information to the user when a development container terminal is opened.
3. .devspace/ folder: A local directory used by DevSpace for internal information and caching to speed up operations (this folder is automatically added to .gitignore).

DevSpace functionality can be extended using plugins, which are contained in a single binary or shell script. Plugins allow you to:

• Add new commands to DevSpace (e.g., devspace login).
• Add new predefined variables.
• Execute hooks at specific events (such as command execution).

To quickly test the integration, clone the example project and run the DevSpace development command:

# Clone the example project
git clone https://github.com/loft-sh/devspace-vscode-example.git

# Switch to the folder
cd devspace-vscode-example

# Open Visual Studio Code in a Container
devspace dev -n my-namespace

DevSpace allows you to manage environment variables and profiles dynamically:

• Override variables: Use --var=KEY=VALUE to pass variables during execution.
• Persist variables: Use --restore-vars to load variables from Kubernetes and --save-vars to save them back to Kubernetes. The storage secret is controlled by --vars-secret (defaults to devspace-vars).
• Apply profiles: Use -p or --profile to specify profiles. You can chain profiles using --profile-parent to ensure base profiles are applied before your target profile.

You can define a set of reusable scripts in the commands section of your devspace.yaml file. This allows team members to execute complex or frequently used commands without needing to know the underlying details. Custom commands can execute any shell script, run other devspace commands, or set environment variables. They behave similarly to the scripts section in a Node.js package.json.

# File: devspace.yaml
images:
  default:
    image: john/backend

commands:
  debug-backend: |- 
    devspace dev $@

You can use BuildKit as a build engine to build images either locally or inside your Kubernetes cluster without requiring a Docker daemon.

To use BuildKit, you must have either Docker or the buildx CLI installed locally. If you are using the in-cluster build functionality, a running Docker daemon is not required; only the CLI tools are needed.

To enable BuildKit for a specific image, define the buildKit field in your devspace.yaml.

images:
  backend:
    image: john/appbackend
    buildKit: {}

Config expressions allow you to load devspace.yaml dynamically by specifying $( my bash expression ). The stdout of the bash expression is used as the value for the option or the entire section.

Expressions are evaluated after variables and profiles are applied. They run in a POSIX-compatible shell (via a Go-based shell implementation) that works across all operating systems.

Variables are resolved both before and after expressions, meaning you can load a file via an expression that contains variables which will then be resolved.