# Technical Documentation: devspace-sh/devspace

> ℹ️ **Provenance:** Multi-Tier Ingestion · [CodeWiki Reference](https://codewiki.google/github.com/devspace-sh/devspace)

### Overview (README.md)

<img src="docs/static/media/logos/devspace-logo-primary.svg" width="600">

### **[Website](https://devspace.sh)** • **[Quickstart](#quickstart)** • **[Documentation](https://devspace.sh/cli/docs/introduction)** • **[Blog](https://loft.sh/blog)** • **[Twitter](https://twitter.com/devspace)**







[](https://slack.loft.sh/)

### Client-Only Developer Tool for Cloud-Native Development with Kubernetes
- **Build, test and debug applications directly inside Kubernetes**
- **Develop with hot reloading**: updates your running containers without rebuilding images or restarting containers
- **Unify deployment workflows** within your team and across dev, staging and production
- **Automate repetitive tasks** for image building and deployment

<br>



<br>

<p align="center">
⭐️ <strong>Do you like DevSpace? Support the project with a star</strong> ⭐️
</p>

<br>

DevSpace was created by [Loft Labs](https://loft.sh) and is a [Cloud Native Computing Foundation (CNCF) sandbox project](https://www.cncf.io/sandbox-projects/).

<br>

## Contents
- [Why DevSpace?](#why-devspace)
- [Quickstart Guide](#quickstart)
- [Architecture & Workflow](#architecture--workflow)
- [Contributing](#contributing)
- [FAQ](#faq)

<br>

## Why DevSpace?
Building modern, distributed and highly scalable microservices with Kubernetes is hard - and it is even harder for large teams of developers. DevSpace is the next-generation tool for fast cloud-native software development.

<details>
<summary><b>Standardize & Version Your Workflows</b></summary>
<br>

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

<br>
</details>

<details>
<summary><b>Let Everyone on Your Team Deploy to Kubernetes</b></summary>
<br>

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](https://devspace.sh/cli/docs/configuration/variables/basics) 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](https://loft.sh/).

<br>
</details>

<details>
<summary><b>Speed Up Cloud-Native Development</b></summary>
<br>

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.

<br>
</details>

<details>
<summary><b>Automate Repetitive Tasks</b></summary>
<br>

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.

<br>
</details>

<details>
<summary><b>Works with Any Kubernetes Clusters</b></summary>
<br>

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.

<br>
</details>

<br>

## Quickstart

Please take a look at our [getting started guide](https://devspace.sh/docs/getting-started/installation).

<br>

## Architecture & Workflow


DevSpace runs as a single binary CLI tool directly on your computer and ideally, you use it straight from the terminal within your IDE. DevSpace does not require a server-side component as it communicates directly to your Kubernetes cluster using your kube-context, just like kubectl.

<br>

## Contributing

Participation in the DevSpace project is governed by the [CNCF code of conduct](https://github.com/cncf/foundation/blob/master/code-of-conduct.md).

Help us make DevSpace the best tool for developing, deploying and debugging Kubernetes apps.

[](https://slack.loft.sh/)

### Reporting Issues

If you find a bug while working with the DevSpace, please [open an issue on GitHub](https://github.com/loft-sh/devspace/issues/new?labels=kind%2Fbug&template=bug-report.md&title=Bug:) and let us know what went wrong. We will try to fix it as quickly as we can.

### Feedback & Feature Requests

You are more than welcome to open issues in this project to:

- [Give feedback](https://github.com/loft-sh/devspace/issues/new?labels=kind%2Ffeedback&title=Feedback:)
- [Suggest new features](https://github.com/loft-sh/devspace/issues/new?labels=kind%2Ffeature&template=feature-request.md&title=Feature%20Request:)
- [Report Bugs](https://github.com/loft-sh/devspace/issues/new?labels=kind%2Fbug&template=bug-report.md&title=Bug%20Report:)

### Contributing Code

This project is mainly written in Golang. If you want to contribute code:

1. Ensure you are running golang version 1.11.4 or greater for go module support
2. Set the following environment variables:
   ```
   GO111MODULE=on
   GOFLAGS=-mod=vendor
   ```
3. Check-out the project: `git clone https://github.com/loft-sh/devspace && cd devspace`
4. Make changes to the code
5. Build the project, e.g. via `go build -o devspace[.exe]`
6. Evaluate and test your changes `./devspace [SOME_COMMAND]`

See [Contributing Guidelines](CONTRIBUTING.md) for more information.

The DevSpace project follows the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md).

<br>

## FAQ

<details>
<summary>What is DevSpace?</summary>

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`.

</details>

<details>
<summary>Is DevSpace free?</summary>

**YES.** DevSpace is open-source and you can use it for free for any private projects and even for commercial projects.

</details>

<details>
<summary>Do I need a Kubernetes cluster to use DevSpace?</summary>

**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.

</details>

<details>
<summary>Can I use DevSpace with my existing Kubernetes clusters?</summary>

**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.

</details>

<details>
<summary>What is a Helm chart?</summary>

[Helm](https://helm.sh/) is the package manager for Kubernetes. Packages in Helm are called Helm charts.

</details>

<br>
<br>

## License

DevSpace is released under the Apache 2.0 license. See the [LICENSE](LICENSE) file for details.

DevSpace is a [Cloud Native Computing Foundation (CNCF) sandbox project](https://www.cncf.io/sandbox-projects/) and was contributed by [Loft Labs](https://www.loft.sh).

<div align="center">
    <img src="https://raw.githubusercontent.com/cncf/artwork/master/other/cncf-sandbox/horizontal/color/cncf-sandbox-horizontal-color.svg" width="300" alt="CNCF Sandbox Project">
</div>

---

### README (`docs/README.md`)

# Website

This website is built using [Docusaurus 2](https://v2.docusaurus.io/), a modern static website generator.

## Contributing

### Installation

```
yarn
```

### Development
```
yarn start
```
This command starts a local development server and open up a browser window. Most changes are reflected live without having to restart the server.

### Production Build
```
yarn build
```
This command generates static content into the `build` directory and can be served using any static contents hosting service.

### Create New Major Version
```bash
yarn run docusaurus docs:version 5.x
```

### Generate CLI Reference
```bash
cd ../ # main project directory
go run ./docs/hack/cli/main.go
```

### Generate Partials For Config (devspace.yaml)
```bash
cd ../ # main project directory

go run ./docs/hack/config/partials/main.go
```


### Generate Schema For Config (devspace.yaml)
```bash
cd ../ # main project directory

go run ./docs/hack/config/schemas/main.go
```

### Generate Function Docs
```bash
cd ../ # main project directory

go run ./docs/hack/functions/main.go
```

---

### Pages Plugins README (`docs/pages/plugins/README.mdx`)

---
title: DevSpace Plugins
sidebar_label: Plugins
---

The functionality of DevSpace can be extended and changed via plugins. Plugins are managed through DevSpace and are contained in a single binary or shell script. Plugins are able to extend DevSpace in the following ways:
- Add new commands to DevSpace (e.g. `devspace login` or `devspace list users`)
- Add new [predefined variables](../configuration/variables.mdx)
- Execute hooks at specific events (like a command execution)

## Installing a plugin
 
Plugins can be installed from an URL, Git Repository or local file. To install a plugin run:
```
# Add a plugin from a git repository
devspace add plugin https://github.com/my-organization/my-repo

# Add a plugin from an URL
devspace add plugin https://myorg.com/path/to/plugin.yaml

# Add a plugin from a local path
devspace add plugin ./plugin.yaml
```

After installing a plugin you can check all your existing plugins via:
```
devspace list plugins
```

## Updating a plugin

To update a DevSpace plugin run the following command:

```
# Enter the name and not the path
devspace update plugin PLUGIN_NAME

# This only works for GIT plugins
devspace update plugin PLUGIN_NAME --version GIT_TAG
```

## Removing a plugin

To remove a plugin via the DevSpace command line:
```
# Enter the name and not the path
devspace remove plugin PLUGIN_NAME
```

If the plugin cannot be removed because a certain hook fails (or any other reason), you can also delete the plugin manually. DevSpace saves all plugin data in `$HOME/.devspace/plugins`. You will have to check each folders `plugin.yaml` to see which plugin is stored in the folder. To remove a plugin, simply delete the complete plugin folder.

## Developing a custom DevSpace plugin

Creating an own DevSpace plugin is quite easy. You only need a `plugin.yaml` that specifies where DevSpace can find the plugin binary and how DevSpace should execute it. You can also take a look at the [devspace-plugin-example](https://github.com/loft-sh/devspace-plugin-loft) project for a complete example.
For each installed plugin, DevSpace will create a folder in `$HOME/.devspace/plugins` with a `plugin.yaml` and a downloaded or copied `binary` that will be executed.

### plugin.yaml

The `plugin.yaml` specifies how the plugin is installed and integrates into DevSpace and consists of the following parts.

#### `name`

Name of the plugin as shown in devspace list plugins and used for devspace update plugin and devspace remove plugin. (e.g. `my-devspace-plugin`)

#### `version`

The semantic current version of the plugin (e.g. `0.0.1`)

#### `binaries`

This section states where DevSpace can retrieve the plugin binary for the current operating system and architecture. If devspace cannot find a binary for the current [runtime.GOOS](https://golang.org/pkg/runtime/#pkg-constants) and [runtime.GOARCH](https://golang.org/pkg/runtime/#pkg-constants) it will not install the plugin.
The `binaries` section expects an array with objects that can have the following properties:
* `os` is the runtime.GOOS name of the operating system (e.g. darwin, windows, linux etc.)
* `arch` is the runtime.GOARCH name of the system (e.g. amd64, 386 etc.)
* `path` is the URL to the binary to download or the local path to the binary to copy

#### `commands`

This section specifies which commands should be added to DevSpace. It expects an array with objects that can have the following properties:
* `name` of the command that should be added to devspace (e.g. `login` will add `devspace login`)
* `baseArgs` these args are prepended to the plugin binary, so when a user will call 'devspace login other --flag 123', devspace will call the plugin binary with 'plugin-binary baseArgs... other --flag 123'
* `usage` the usage of the command to print in `devspace --help`
* `description` the description of the command to print in `devspace --help`
* `subCommand` (Optional) the subcommand to append the command to (e.g. `add` will add the command to `devspace add`)

DevSpace will forward all passed arguments and flags to the plugin command. 

#### `vars`

This section specifies which [predefined variables](../configuration/variables.mdx) are added to DevSpace. These variable values will be retrieved from the plugin binary instead of asking the user. It expects an array with objects that can have the following properties:
* `name` of the predefined variable to add (e.g. `EXAMPLE_VARIABLE` which can then be used in a `devspace.yaml` as `${EXAMPLE_VARIABLE}`)
* `baseArgs` these args are appended to the plugin binary (e.g. `["print", "var", "test"]` will cause devspace to call the plugin binary with: `plugin-binary print var test`)

DevSpace expects the plugin binary to either fail (exit code unequal zero) or print the variable value to the stdout stream. Furthermore when executing the plugin-binary, DevSpace will set the following environment variables:
- `DEVSPACE_PLUGIN_OS_ARGS` all arguments that were used to call the current command encoded as JSON (e.g. `["devspace", "dev", "--wait", "--force-build"]`)
- `DEVSPACE_PLUGIN_KUBE_NAMESPACE_FLAG` the value of `--namespace` if set (e.g. `namespace`)
- `DEVSPACE_PLUGIN_KUBE_CONTEXT_FLAG` the value of `--kube-context` if set (e.g. `my-kube-context`)

#### `hooks`

This section specifies certain plugin commands that should be executed at certain DevSpace events. It expects an array with objects that can have the following properties:
* `event` name of the event when to execute the command. The following events exist:
  * `after:installPlugin` executed after the plugin was installed
  * `before:updatePlugin` executed before the plugin will be updated
  * `after:updatePlugin` executed after the plugin was updated
  * `before:removePlugin` executed before the plugin will be removed
  * `before:build`, `before:build:*`, `after:build`, `after:build:*`, `error:build:*` executed when DevSpace will build an image. The environment variables `DEVSPACE_PLUGIN_IMAGE_CONFIG_NAME`, `DEVSPACE_PLUGIN_IMAGE_NAME`, `DEVSPACE_PLUGIN_IMAGE_TAGS` and `DEVSPACE_PLUGIN_IMAGE_CONFIG` will be available in the hook
  * `before:deploy`, `after:deploy`, `before:deploy:*`, `after:deploy:*`, `error:deploy:*`, `skip:deploy:*`, `before:render`, `after:render`, `before:render:*`, `after:render:*`, `error:render:*`, `before:purge`, `after:purge`, `before:purge:*`, `after:purge:*`, `error:purge:*` executed when DevSpace will deploy a defined deployment. The environment variables `DEVSPACE_PLUGIN_DEPLOY_CONFIG` will be available in the hook
  * `before:resolveDependency:*`, `after:resolveDependency:*`, `error:resolveDependency:*`, `before:buildDependency:*`, `after:buildDependency:*`, `error:buildDependency:*`, `before:deployDependency:*`, `after:deployDependency:*`, `error:deployDependency:*`, `before:renderDependency:*`, `after:renderDependency:*`, `error:renderDependency:*`, `before:purgeDependency:*`, `after:purgeDependency:*`, `error:purgeDependency:*` executed before, after or onError during dependency handling. The environment variables `DEVSPACE_PLUGIN_DEPENDENCY_CONFIG`, `DEVSPACE_PLUGIN_DEPENDENCY_CONFIG_PATH`and `DEVSPACE_PLUGIN_DEPENDENCY_NAME` will be available in the hook
  * `before:configLoad`, `after:configLoad`, `error:configLoad` executed when DevSpace tries to load a `devspace.yaml`. The environment variables `DEVSPACE_PLUGIN_LOAD_PATH`, `DEVSPACE_PLUGIN_LOADED_RAW`, `DEVSPACE_PLUGIN_LOADED_VARS` and `DEVSPACE_PLUGIN_LOADED_CONFIG` (only in `config.afterLoad`) will be available in the hook
  * `start:sync:*`, `stop:sync:*`, `error:sync:*`, `restart:sync:*` executed when DevSpace will start syncing a new sync config, closing a running one or restarting/stopping because of an error. The environment variables `DEVSPACE_PLUGIN_SYNC_CONFIG` will be available in the hook
  * `before:initialSync:*`, `after:initialSync:*`, `error:initialSync:*` executed right before DevSpace will do an initial sync and afterwards (if successful). The environment variables `DEVSPACE_PLUGIN_SYNC_CONFIG` will be available in the hook
  * `start:portForwarding:*`, `restart:portForwarding:*`, `error:portForwarding:*`, `stop:portForwarding:*` executed when DevSpace will start, restart, stop port forwarding. The environment variables `DEVSPACE_PLUGIN_PORT_FORWARDING_CONFIG` will be available in the hook
  * `start:reversePortForwarding:*`, `restart:reversePortForwarding:*`, `error:reversePortForwarding:*`, `stop:reversePortForwarding:*` executed when DevSpace will start, restart, stop reverse port forwarding. The environment variables `DEVSPACE_PLUGIN_REVERSE_PORT_FORWARDING_CONFIG` will be available in the hook
  * `before:createPullSecrets`, `after:createPullSecrets`, `error:createPullSecrets`: executed while DevSpace creates `pullSecrets`
  * `devCommand:before:sync`, `devCommand:after:sync`, `devCommand:before:portForwarding`, `devCommand:after:portForwarding`, `devCommand:before:replacePods`, `devCommand:after:replacePods`, `devCommand:before:runPipeline`, `devCommand:after:runPipeline`, `devCommand:before:deployDependencies`, `devCommand:after:deployDependencies`, `devCommand:before:build`, `devCommand:after:build`, `devCommand:before:deploy`, `devCommand:after:deploy`, `devCommand:before:openTerminal`, `devCommand:before:streamLogs`, `devCommand:before:execute`, `devCommand:after:execute`, `devCommand:interrupt`, `devCommand:error` executed at different checkpoints when `devspace dev` is executed
  * `deployCommand:before:execute`, `deployCommand:after:execute`, `deployCommand:error`, `deployCommand:interrupt` executed at different checkpoints when `devspace deploy` is executed
  * `purgeCommand:before:execute`, `purgeCommand:after:execute`, `purgeCommand:error`, `purgeCommand:interrupt` executed at different checkpoints when `devspace purge` is executed
  * `buildCommand:before:execute`, `buildCommand:after:execute`, `buildCommand:error`, `buildCommand:interrupt` executed at different checkpoints when `devspace build` is executed
  * `command:before:execute`, `command:after:execute`, `command:error` executed at the beginning, ending or if an error occurs during any DevSpace command execution
  * `analyze`, `attach`, `build`, `deploy`, `dev`, `enter`, `init`, `logs`, `open`, `print`, `purge`, `render`, `restart`, `run`, `sync`, `ui`, `upgrade` are executed after the corresponding devspace command has loaded the config and created a kubernetes client (if there is a config to load or a kubernetes client to create)
* `baseArgs` these args are appended to the plugin binary (e.g. `["run", "my", "command"]` will cause devspace to call the plugin binary with: `plugin-binary run my command`)
* `background` if true will execute the hook in the background and continue DevSpace command execution

If a non-background hook fails (exit code unequals zero) DevSpace will stop command execution and the complete DevSpace command fails. Furthermore when executing the plugin-binary, DevSpace will set the following environment variables (if they apply for the event):
- `DEVSPACE_PLUGIN_EXECUTION_ID` a unique identifier that stays the complete duration of a command but will change each time DevSpace is re-executed
- `DEVSPACE_PLUGIN_EVENT` the event that has triggered the hook
- `DEVSPACE_PLUGIN_OS_ARGS` all arguments that were used to call the current command encoded as JSON (e.g. `["devspace", "dev", "--wait", "--force-build"]`)
- `DEVSPACE_PLUGIN_CONFIG` the config that was loaded for the command as yaml encoded (all profiles and variables are resolved at this point)
- `DEVSPACE_PLUGIN_COMMAND` the name of the DevSpace command that was executed (e.g. `dev`)
- `DEVSPACE_PLUGIN_COMMAND_LINE` the complete name of the DevSpace command that was executed (e.g. `devspace dev [FLAGS]`)
- `DEVSPACE_PLUGIN_COMMAND_FLAGS` the flags that were passed to the DevSpace command encoded as JSON (e.g. `["--namespace", "test", "--skip-build", "true"]`)
- `DEVSPACE_PLUGIN_COMMAND_ARGS` the arguments that were passed to the DevSpace command encoded as JSON (without any flags) (e.g. `["arg1"]`)
- `DEVSPACE_PLUGIN_KUBE_NAMESPACE_FLAG` the kubernetes namespace where DevSpace will operate in (e.g. `namespace`)
- `DEVSPACE_PLUGIN_KUBE_CONTEXT_FLAG` the kubernetes context where DevSpace will operate in (e.g. `my-kube-context`)
- `DEVSPACE_PLUGIN_ERROR` the error that occurred at a certain event (usually only supplied in the `error` or `restart` events)

### Example

An example `plugin.yaml` could look like this:
```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Versioned Docs Version 5.X Quickstart (`docs/versioned_docs/version-5.x/quickstart.mdx`)

---
title: Quickstart
sidebar_label: Quickstart
---

import InstallFragment from './fragments/install-cli.mdx';
import ChooseProjectFragment from './fragments/choose-project.mdx';
import StartAppFragment from './fragments/start-app.mdx';

This is a 2-minute quickstart guide. For additional details and explanations, see the [Getting Started Guide](./getting-started/installation.mdx).

## 1. Download CLI
<InstallFragment/>

## 2. Choose a Project
You can either deploy one of your own projects or alternatively, checkout one of our demo applications using git:

<ChooseProjectFragment/>

## 3. Initialize Project
```bash
devspace init
```
Choose `Component Chart` and `Based on this existing Dockerfile` for quickstart projects.


## 4. Start Development
```bash
devspace use namespace my-namespace  # will be created by DevSpace if it does not exist
devspace dev
```

As soon as the terminal opens up, you can start your application:

<StartAppFragment/>

**Hot Reloading**: Now, change a file on your local computer and re-run the application inside the container terminal.

**Port Forwarding**: You can access your application via `localhost:PORT` if your port is specified in `dev.ports` within `devspace.yaml`.

When you're done testing development, type `exit` or hit `Ctrl-d` to exit the container terminal.

## 5. Deploy Project
To build your container image and deploy a clean version of this project, run:
```bash
devspace use namespace my-namespace  # will be created by DevSpace if it does not exist
devspace deploy -p production
```

## 6. Cleanup
To purge your deployment from the cluster, run:
```bash
devspace purge
```

---

### Pages Configuration Commands README (`docs/pages/configuration/commands/README.mdx`)

---
title: Custom Commands
sidebar_label: commands
---

import ConfigPartialCommands from '../_partials/v2beta1/commands.mdx'

The idea of custom commands is that someone on a team defines a set of useful commands and stores them in the `devspace.yaml`, then commits and pushes this config to the code repository. Now, others can run these custom commands without having to remember all the details or having to read through endless pages of documentation.

Custom commands are being shared in the `commands` section of `devspace.yaml`:
```yaml
# File: devspace.yaml
images:
  default:
    image: john/backend

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

:::note
Custom commands can be used for more than just running `devspace` commands, e.g. they can run any other script or command, set environment variables etc. If you are familiar with the `scripts` section of the `package.json` for Node.js, you will find that `devspace run [name]` works pretty much the same way as `npm run [name]`
:::

The above example configuration would allow everyone to run the custom command `debug-backend` like this:
```bash
devspace run debug-backend
devspace run debug-backend -n my-namespace
```

And `devspace run` would execute the following commands internally:
```bash
devspace dev
devspace dev -n my-namespace
```

:::note `--` End of Options Separator
The `--` between the command name and the additional flags for the command tells your terminal that the arguments and flags that follow after the `--` do not belong to `devspace run` and should not be parsed. It is not required but often helpful to use `--` when executing commands using `devspace run`.
:::

:::info Interactive Commands
Custom commands proxy input and output streams, so you can even share interactive commands such as `devspace enter`.
:::


## Configuration

<ConfigPartialCommands/>


<br/>

## Useful Commands

### `devspace list commands`
Run this command to list all custom commands that are configured:
```bash
devspace list commands
```


### `devspace run dependency1.command`
You can run a command defined in one of the dependencies of the current project like this:
```bash
devspace run [dependency].[command] [command-flags-and-args]
```

:::note Working Directory
When running a command of a dependency, DevSpace will use the root folder of the dependency as current working directory when executing the command.
:::

---

### Pages Configuration Dependencies README (`docs/pages/configuration/dependencies/README.mdx`)

---
title: Dependencies
sidebar_label: "Basics"
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import PartialDependenciesConfig from '../_partials/v2beta1/dependencies.mdx'

DevSpace allows you to define dependencies between several software projects that have a `devspace.yaml`, e.g. across different git repositories or local folders. This makes DevSpace a great tool for building and deploying software that consists of several microservices. Primary use cases of dependencies are:

- You want to reuse an already existing `devspace.yaml` of another project
- You want to define a more complex pipeline with multiple build, hook and deploy steps
- You want to define a common build / deploy step for other projects

Dependencies for DevSpace projects are defined within the `dependencies` section of `devspace.yaml`.

<Tabs
  defaultValue="git"
  values={[
    { label: 'Git Repository', value: 'git', },
    { label: 'Local Path', value: 'path', },
  ]
}>
<TabItem value="git">

```yaml
dependencies:
  api-server:
    git: https://github.com/my-api-server
    branch: stable
    pipeline: dev
  auth-server:
    git: https://github.com/my-auth-server
    revision: c967392
    profiles:
      - production
  database-server:
    git: https://github.com/my-database-server
    tag: v3.0.1
    subPath: /configuration
    vars:
      ROOT_PASSWORD: ${ROOT_PASSWORD}
```

</TabItem>
<TabItem value="path">

```yaml
dependencies:
  component-1:
    path: ./component-1
  component-2:
    path: ./component-2
```

</TabItem>
</Tabs>

## Dependency Source
DevSpace is able to work with dependencies from the following sources:
- [`git` repository](../../configuration/dependencies/git-repository.mdx) as dependency that has a devspace configuration
- [`path` to a local folder](../../configuration/dependencies/local-folder.mdx) that contains a dependency (path is relative to the current project's root directory)


## Execution Order

Dependencies will be executed in parallel and always before image building and deployments defined in the top-level `devspace.yaml`. If you want to execute dependencies sequentially, you can define a pipeline to do so. `dev` configuration that should be reused from a dependency will be executed alongside regular `dev` configuration specified in the top-level `devspace.yaml` after the DevSpace deployment pipeline ran through. Example:
```yaml
dependencies:
  dep1:
    path: dep1
    pipeline: dev
  dep2:
    path: dep2
    pipeline: dev
images:
  image1:
    image: myimage/image
deployments:
  deployment1:
    helm:
      ...
dev:
  my-dev:
    ports: ...
    sync: ...
```

### Explanation
In the above `devspace.yaml`, execution order would be as followed:
* Execute dependency dep1's pull secrets, image building & deployments (if dep1 has other dependencies as well, execute those first)
* Execute dependency dep2's pull secrets, image building & deployments
* Build image `image1`
* Deploy deployment `deployment1`
* Start merged portforwarding from `dep2` and `dev.ports`
* Start sync from `dep1` and `dev.sync`

## Referencing Dependencies

### Reference Image Names
You can reference dependencies images via `my-dependency.image` in the `./devspace.yaml`:
```yaml
dependencies:
  dep1:
    path: dep1

dev:
  my-dev:
    imageSelector: ${runtime.dependencies.dep1.images.image1}
    # Will open a terminal to the pod with the
    # image from dep1
    terminal: {}
```

With `dep1/devspace.yaml`:
```yaml
images:
  image1:
    image: myusername/devspace
deployments:
  quickstart:
    helm:
      values:
        containers:
          - image: myusername/devspace
```

### Referencing Dependencies in Deployment Values / Manifests

It is also possible to reference a dependency's image with runtime variables in a deployment:
```yaml
dependencies:
  dep1:
    path: dep1
deployments:
  quickstart:
    helm:
      values:
        containers:
          - image: ${runtime.dependencies.dep1.image1.image}:${runtime.dependencies.dep1.image1.tag} # -> replaced with 'myusername/devspace:xxxx'
```

With a dependency `dep1/devspace.yaml` that looks like:
```yaml
images:
  image1:
    image: myusername/devspace
```

## Dependency Resolution
When a DevSpace project has dependencies, DevSpace will:

1. Resolve all dependencies in a recursive manner and give the dependency an ID based on its path or git repository
2. Build a non-cyclic dependency tree where each dependency only occurs once (but could have multiple edges)
3. Choose a leave node from the dependency tree, build its images (unless skip is defined) and deploy its deployments as well as execute defined hooks or pull secrets
4. Remove the leave node from the tree and repeat step 3 until everything has been deployed

The algorithm used by DevSpace for building and deploying dependencies ensures that all dependencies have been deployed in the correct order before the project you are calling DevSpace from will be built and deployed.

### Redundant Dependencies
If DevSpace detects that two projects within the dependency tree define the same child-dependency (i.e. a redundant dependency), DevSpace will try to resolve this by removing the dependency that is "higher" (i.e. found first when resolving dependencies) within the tree.

### Circular Dependencies
If DevSpace detects two projects which define each other as dependencies (either directly or via child-dependencies), DevSpace will print a warning showing the problematic dependency path within the dependency tree.

## Configuration

<PartialDependenciesConfig/>

---

### Pages Configuration Deployments README (`docs/pages/configuration/deployments/README.mdx`)

---
title: Deployments
sidebar_label: Basics
---

import ConfigPartialDeployments from '../_partials/v2beta1/deployments.mdx'


The `deployments` section in `devspace.yaml` defines Helm charts, Kubernetes manifests and Kustomizations that can deployed using the [`create_deployments` function](../functions/README.mdx#create_deployments).


## Workflow
To deploy resources with DevSpace, you need to:
1. Define the `deployments` section of `devspace.yaml`
2. Call the `create_deployments` function inside the `pipelines` section of `devspace.yaml`
3. Execute the respective pipeline


### 1. Define Deployments
To deploy to Kubernetes using DevSpace, we need to define `deployments` in `devspace.yaml`:
```yaml title=devspace.yaml
version: v2beta1
deployments:
  configs:
    kubectl:
      manifests:
      - ./api/deploy/configmap.yaml
      - ./payments/deploy/configmap.yaml
  api:
    helm:
      chart:
        name: component-chart
        repo: https://charts.devspace.sh
      values:
        containers:
          - image: ghcr.io/loft-sh/devspace-example-api
        service:
          ports:
            - port: 8080
  payments:
    helm:
      chart:
        name: ./payments/chart/
      valuesFiles:
      - ./payments/helm-values-dev.yaml
  auth:
    helm:
      chart:
        name: auth-server-chart
        version: 3.2.1
        repo: https://mycompany.tld/helm/
      values:
        ...
```
The example above defines 4 deployments:
- `configs` which deploys two ConfigMap objects to Kubernetes from plain manifest files
- `api` which is deployed from the component chart provided by DevSpace
- `payments` which is deployed using a local Helm chart that is located in a folder
- `auth` which is deployed from a chart that has been pushed to a Helm repository


### 2. Call `create_deployments` in Pipeline
DevSpace deploys resources to Kubernetes when the [`create_deployments` function](../functions/README.mdx#create_deployments) is called within `pipelines` as shown in this example:

```yaml title=devspace.yaml
version: v2beta1
pipelines:
  # highlight-start
  dev: |-
    create_deployments --all
    start_dev --all
  deploy: |-
    build_images --all
    create_deployments --all
  deploy-api: |-
    create_deployments api
  deploy-ordered: |-
    create_deployments auth
    create_deployments api payments
  # highlight-end

deployments:
  api: ...          # see example above
  payments: ...     # see example above
  auth: ...         # see example above
```


### 3. Run Pipeline
Given the example above, you can now run:
- `devspace deploy` or `devspace dev` to deploy all deployments
- `devspace run-pipeline deploy-api` to deploy only the component chart deployment named `api`
- `devspace run-pipeline deploy-ordered` to  
  1. First deploy `auth` (blocking)
  2. Then deploy `api` and `payments` in parallel


## Config Reference

<ConfigPartialDeployments/>

---

### Pages Configuration Dev README (`docs/pages/configuration/dev/README.mdx`)

---
title: Development Mode
sidebar_label: Basics
---

import FragmentWarningMultipleDev from '../../_partials/warning-multiple-dev.mdx';
import FragmentWorkflowDeployDependencies from '../../_partials/workflow-deploy-dependencies.mdx';
import FragmentWorkflowBuildImages from '../../_partials/workflow-build-images.mdx';
import FragmentWorkflowReplaceTags from '../../_partials/workflow-replace-tags.mdx';
import FragmentWorkflowDeployProject from '../../_partials/workflow-deploy-project.mdx';
import FragmentNoteGeneralPurposeCommand from '../../_partials/note-general-purpose-command.mdx';
import FragmentWorkflowOpenLinks from '../../_partials/workflow-open-links.mdx';
import ConfigPartial from '../_partials/v2beta1/dev.mdx'
import ConfigPartialSelector from '../_partials/v2beta1/dev/group_selector.mdx'
import ConfigPartialModifications from '../_partials/v2beta1/dev/group_modifications.mdx'

A lot of teams configure DevSpace so that the development experience is very similar to using `docker-compose` but with the additional benefits of running inside Kubernetes, having a reproducible dev environment that is as close to production as it gets. If an engineer is already familiar with how to develop with `docker-compose`, DevSpace will be easy to get started with.


## Dev Containers
Dev containers are central to the DevSpace-based development experience. A dev container serves as a remote work environment for the engineer that is connected to the local machine of the engineer via port forwarding, file sync, etc. These connections allow engineers to work with their local IDE or with any cloud IDE without having to change their habits and familiar workflows.

DevSpace can turn any container into a dev container, no matter if this container has been deployed by DevSpace or by another tool. That means you could use a GitOps tool like ArgoCD for deployment of your dev environments and then use DevSpace to connect to the deployed applications to debug and develop them inside your dev cluster.

To define a dev container, you need to configure the `dev` section of `devspace.yaml` and first:
1. [Define a selector](#1-select-container) that matches a pod/container running inside your Kubernetes cluster
2. [Modify selected container](#2-modify-container-for-development) to prepare it for the use as remote development environment
3. Optionally [modify the dev container](#3-modify-container-for-development) to optimize it for the use as remote development environment


## 1. Select Container
DevSpace provides several ways to select a pod/container. The most common option to select a container is by defining an `imageSelector` which selects the container that runs the specified image. Alternatively, you could also use the `labelSelector` that is a common pattern in Kubernetes to select objects in a cluster.

<ConfigPartialSelector/>

:::tip Logical `&&` For Selectors
If multiple selectors (e.g. `imageSelector` and `labelSelector`) are specified, DevSpace will combine them with a logical AND (`&&`) when looking for a pod/container to match the specified conditions.
:::


## 2. Add Dev Connections
Dev connections defines how your local machine and IDE is connected to the dev container that runs in Kubernetes.

Common dev connections include:
- **[Bi-directional file sync](./connections/file-sync.mdx)** to make sure files on localhost and inside the containers main working dir are kept in sync
- **[Port forwarding (and reverse port forwarding)](./connections/port-forwarding.mdx)** to allow engineers to access services inside the dev container via localhost on their local machine (and vice versa)
- **[Connecting the local terminal to the dev container](./connections/terminal.mdx)** either by starting a new terminal session, by attaching the container's entrypoint process, or by simply streaming the container logs
- **[Injecting an SSH server into the dev container](./connections/ssh.mdx)** to SSH into the container, e.g. to use the remote environment capabilities in IDEs such as VS Code
- **[Auto-restart the container](./connections/restart-helper.mdx)** to create a hot reloading experience without the need for image building
- **[Proxy certain commands](./connections/proxy-commands.mdx)** to make commands on the local machine accessible inside the container (e.g. be able to run `kubectl` commands inside the dev container without having to copy credentials inside the dev container)
- **[Auto-open URLs](./connections/open.mdx)** to provide a starting point for the engineer when the dev container is ready to go


## 3. Modify Container For Development
Because the idea behind dev containers is that you just deploy your prod/stable containers and then turn one or even multiple containers into dev containers later on when you actually want to work on them, DevSpace allows you to make modifications for these containers on-the-fly.

A common example for modifying a container to optimize it for development would be to use the `devImage` feature which tells DevSpace to swap out the container's prod/stable image with a prebuilt dev-optimized image (e.g. that contains a remote debugger and other dev tooling).

<ConfigPartialModifications/>



## Start Development Mode
Start the development mode using this command:
```bash
devspace dev
```

<FragmentWarningMultipleDev/>


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Functions README (`docs/pages/configuration/functions/README.mdx`)

---
title: Functions
sidebar_label: functions
---

import ConfigPartial from '../_partials/v2beta1/functions.mdx'
import PipelineFunctionRef from '../_partials/functions/reference_pipeline.mdx'
import GlobalFunctionRef from '../_partials/functions/reference_global.mdx'


Functions are bash functions that can be called inside the remainder of `devspace.yaml`. A common use case is to define reusable functionality that is called from within the scripts you specify within the `pipelines` section.

There are two types of functions:
1. [Custom Functions](#custom-functions) defined in `devspace.yaml` (often added via [`imports`](../imports/README.mdx))
2. [Built-In Functions](#built-in-functions) such as `build_images` or `create_deployments`


## Custom Functions
DevSpace provides support for custom functions. To use them, you need to:
1. Declare your custom functions within the `functions` section of `devspace.yaml`
2. Call custom functions from any scripted field in `devspace.yaml` such as in `pipelines` or in any value defined using an inline script such as `$(command)`

### 1. Declare Functions
Declaring a function means adding a key with the function name to the `functions` section in `devspace.yaml` as shown in the example below:
```yaml title=devspace.yaml
version: v2beta1
functions:
  hello_world: |-
    echo "Hello World"
  get_tag: |-
    echo $(git rev-parse --short HEAD)
```

### 2. Call Functions
To call a custom function
```yaml title=devspace.yaml
version: v2beta1
pipelines:
  deploy: |-
    build_images --tag $(get_git_commit)
    create_deployments --all
  dev: |-
    hello_world
    run_default_pipeline dev
```
Please note that custom functions can only be called from `pipelines` and other `functions` as these run in a `pipeline` context.


## Built-In Functions
DevSpace provides a set of built-in functions. There are two types of functions:
1. [Pipeline-Only Functions](#pipeline-only-functions)
2. [Global Functions](#global-functions)


### Pipeline-Only Functions
Pipeline-only functions can only be used inside the scripts within the `pipelines` section of `devspace.yaml`. They can be overridden through the functions section to avoid changing a default pipeline.

Example:
```yaml
functions:
  create_deployments: |-
    echo "create_deployments was called with $@"
    __create_deployments "$@"
```

<PipelineFunctionRef/>


### Global Functions
Global functions can be used anywhere in `devspace.yaml`, either in config fields that expect a bash script such as within `functions` or using [`$(command)` vars](../variables.mdx#from-commands) in any other config field.

<GlobalFunctionRef/>


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Hooks README (`docs/pages/configuration/hooks/README.mdx`)

---
title: Hooks
sidebar_label: hooks
---

import ConfigPartialHooks from '../_partials/v2beta1/hooks.mdx'

DevSpace allows you to define certain actions that should be executed during the pipeline. This makes it possible to customize the deployment and development process with DevSpace. The following actions can be executed with hooks:
- Execute a command on the local machine (in a golang shell or directly on the system)
- Execute a command in a container
- Upload a file or folder into a container
- Download a file or folder from a container
- Wait for a container to start or terminate
- Print the logs of container

Hooks can be defined in the `hooks` section of `devspace.yaml`:
```yaml
hooks:
# Execute the hook in a golang shell (cross operating system compatible)
- name: "pre-image-build-hook"
  command: "echo before image building"
  events: ["before:build"]
# Execute the hook in a golang shell (cross operating system compatible)
- name: "post-image-build-hook"
  command: |
    echo Built Image image(image-1):tag(image-1)
  events: ["after:build:image-1"]
# Execute the hook directly on the system (echo binary must exist)
- command: "echo"
  args: ["before image building"]
  events: ["before:build:image-1", "before:build:image-2"]
# Execute the hook only on windows
- command: "echo before each image"
  os: windows
  events: ["before:build:*"]
```

This tells DevSpace to execute the command `echo before image building` before any image will be built. 

## Lifecycle Events  

You are able to define hooks for the following lifecycle events:
- `before:deploy`, `after:deploy`, `before:deploy:[name]`, `after:deploy:[name]`, `error:deploy:[name]`, `skip:deploy:[name]`: executed while DevSpace deploys `deployments`. `[name]` can be replaced with the config name of a deployment or `*` to match all.
- `before:render`, `after:render`, `before:render:[name]`, `after:render:[name]`, `error:render:[name]`: executed while DevSpace renders `deployments` during `devspace render`. `[name]` can be replaced with the config name of a deployment or `*` to match all.
- `before:purge`, `after:purge`, `before:purge:[name]`, `after:purge:[name]`, `error:purge:[name]`: executed while DevSpace purges `deployments` during `devspace purge`. `[name]` can be replaced with the config name of a deployment or `*` to match all.
- `before:build`, `after:build`, `before:build:[name]`, `after:build:[name]`, `error:build:[name]`, `skip:build:[name]`: executed while DevSpace builds `images`. `[name]` can be replaced with the config name of an image or `*` to match all.
- `start:sync:[name]`, `stop:sync:[name]`, `error:sync:[name]`, `restart:sync:[name]`, `before:initialSync:[name]`, `after:initialSync:[name]`, `error:initialSync:[name]`: executed while DevSpace syncs files with `dev.sync`. `[name]` can be replaced with the config name of a sync configuration or `*` to match all.
- `start:portForwarding:[name]`, `restart:portForwarding:[name]`, `error:portForwarding:[name]`, `stop:portForwarding:[name]`: executed while DevSpace port forwards with `dev.ports`. `[name]` can be replaced with the config name of a port forwarding configuration or `*` to match all.
- `start:reversePortForwarding:[name]`, `restart:reversePortForwarding:[name]`, `error:reversePortForwarding:[name]`, `stop:reversePortForwarding:[name]`: executed while DevSpace reverse port forwards with `dev.ports`. `[name]` can be replaced with the config name of a port forwarding configuration or `*` to match all.
- `before:createPullSecrets`, `after:createPullSecrets`, `error:createPullSecrets`: executed while DevSpace creates `pullSecrets`

:::info Errors in Hooks
If any hook returns a non-zero exit code, DevSpace will abort and print an error message.
:::

For `error:` events the actual error will be passed to the hook via the environment variable `DEVSPACE_HOOK_ERROR`. For example:
```yaml
# This will print the error to the console that has occured during a deployment
hooks:
- events: ["error:deploy:*"]
  command: "echo The following error has occurred during deploying $DEVSPACE_HOOK_DEPLOY_NAME: $DEVSPACE_HOOK_ERROR"
  os: darwin,windows
  name: "error-hook"
```

## Execute hooks in a container

DevSpace allows you to execute commands directly in a container instead of the local system. You can specify this in the `container` section of the hook:

```yaml
...
hooks:
- command: |
    echo Hello World!
    echo From within the container!
  container:
    imageSelector: nginx
    # Or select via labelSelector etc.
    # labelSelector: ...
    # namespace: ...
    # containerName: ...
    # pod: ...
  events: ["after:deploy:my-deployment"]
...
```

By default, DevSpace will wait for all pods / containers that were selected with the given selector to come up. As soon as all targets are running, DevSpace will execute the hook and wait for it to finish. You can define if DevSpace should wait and how long it should wait with `wait` and `timeout`:

```yaml
...
hooks:
- command: "echo"
  args: ["Hello from within the container!"]
  container:
    imageSelector: image(app):tag(app)
    # Or select via labelSelector etc.
    # labelSelector: ...
    # namespace: ...
    # containerName: ...
    # pod: ...
    wait: true   # This is the default
    timeout: 300 # Timeout in seconds
  events: ["after:deploy:my-deployment"]
...
```

## Upload or Download files from a container

Hooks can be used to upload or download files from a container. In the background, DevSpace will basically do a `kubectl cp` to the specified container. Example:
```yaml
hooks:
# Upload the complete local bin folder to the container path ./bin
- upload:
    localPath: bin
    containerPath: bin
  container:
    imageSelector: image(test):tag(test)
  events: ["after:deploy:my-deployment"]
  name: "upload-hook"
# Download a single file from the container to the local path
- download:
    localPath: build/artifact.jar
    containerPath: /abs/path/build/artifact-test.jar
  container:
    imageSelector: image(java):tag(java)
  events: ["after:deploy:my-deployment-2"]
  name: "download-hook"
```

## Wait for a pod to be running

This hook action can be useful if you want to ensure a certain pod is running before you continue with the pipeline. An example configuration could look like this:
```yaml
...
deployments:
  my-database:
    helm:
      chart:
        name: component-chart
        repo: https://charts.devspace.sh
      values:
...
hooks:
# This hook will ensure that every time the deployment
# my-database is deployed that DevSpace will wait until
# all pods and containers that match the labelSelector
# app.kubernetes.io/component: my-database are running
- wait:
    # DevSpace will wait for all containers that match the label selector below to become running. 
    # If there are init containers, make sure to set terminatedWithCode as well.
    running: true
    # This can be needed if there are for example init containers
    # that terminate instead of become running.
    terminatedWithCode: 0
  container:
    labelSelector:
      app.kubernetes.io/component: my-database
      # You could also select just a specific container with
      # containerName: database-container
  events: ["after:deploy:my-database"]
  name: "wait-for-pod-hook"
...
```

## Print the logs of a container 

This action can be useful to print logs of jobs or print the logs of init containers that would not be printed otherwise during `devspace dev`. An example configuration could look like this:

`job.yaml`:
```yaml
apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app.kubernetes.io/component: my-job
spec:
  restartPolicy: Never
  containers:
    - command: ["sh"]
      args: ["-c", "echo 'Job Start' && sleep 5 && echo 'Doing Things...' && sleep 5 && echo 'Job End'"]
      image: alpine
      name: job
```

`devspace.yaml`:
```yaml
version: ...
deployments:
  my-job:
    kubectl:
      manifests:
      - job.yaml
hooks:
# This hook will wait until the selected container is either running or already  
# terminated and then print the logs of it until it terminates.
- logs: {}
  container:
    labelSelector:
      app.kubernetes.io/component: my-job
  events: ["after:deploy:my-job"]
  name: "print-logs-hook"
```

## Execute hooks in the background

By default, DevSpace will wait for a hook to finish and then move on with the pipeline. However, in some cases it might be desired that a hook is executed in the background to speed up a process. You can specify a background hook with the `background` option:

```yaml
...
hooks:
- command: "sh"
  args: ["-c", "sleep 10 && echo 'Hello, I was run inside the background!'"]
  background: true
  events: ["after:deploy"]
  name: "background-hook"
...
```

If you do not want to stream the output of the hook to the console, you can also mark the hook as silent, which will prevent any hook output:
```yaml
...
hooks:
- command: "sh"
  args: ["-c", "sleep 10 && echo 'Hello, I was run inside the background!'"]
  background: true
  silent: true
  events: ["after:deploy"]
  name: "silent-background-hook"
...
```

## Execute hooks only on certain operating systems

Hooks can be executed only on certain operating systems:

```yaml {3,6}
hooks:
- command: echo before image building on windows
  os: windows
  events: ["after:build"]
  name: windows-hook
- command: echo before image building on mac and linux
  os: darwin,linux
  events: ["after:build"]
  name: darwin-linux-hook
```

## Execute hooks once

Hooks can be executed only once for each targeted container. This means as long as the container where the hook was executed stays running, the hook will not be executed for this container again until it restarts. This can be useful for running one-time development tasks without using init containers. In the following example, the command would only run once for the newest container running with the image `nginx:1.21`.

```yaml {8}
...
hooks:
- command: |
    echo Hello World!
    echo From within the container!
  container:
    imageSelector: nginx:1.21
    once: true
  events: ["after:deploy"]
  name: one-time-hook
...
```

If you run `devspace dev` or `devspace deploy` now multiple times and the container is not replaced or restarted, the hook is only executed once.

## Hook Context Information

DevSpace passes certain environment variables to the hook execution:
- **DEVSPACE_HOOK_KUBE_CONTEXT**: the name of the kube context that was used
- **DEVSPACE_HOOK_KUBE_NAMESPACE**: the name of the kube namespace that was used
- **DEVSPACE_HOOK_OS_ARGS**: json encoded os.Args that were used to call devspace
- **DEVSPACE_HOOK_ERROR**: if an error has occured contains the error string (only for onError hooks)
- **DEVSPACE_HOOK_EVENT**: the event that has triggered the hook

Depending on the hook there will be other context variables set that are prefixed with `DEVSPACE_HOOK_`. 

## Config Reference

<ConfigPartialHooks />

---

### Pages Configuration Images README (`docs/pages/configuration/images/README.mdx`)

---
title: Image Building
sidebar_label: Basics
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import FragmentFaqImageContext from '../../_partials/faq-image-context.mdx';
import WarningBuildToolPriority from '../../_partials/warning-build-tool-priority.mdx';
import ConfigPartial from '../_partials/v2beta1/images.mdx'
import PreventBuildTip from './_partials/prevent_build.mdx'

DevSpace can build, tag and push images using a variety of build engines.

<PreventBuildTip/>


## Workflow
To build, tag and push images with DevSpace, you need to:
1. Define your images in the `images` section of `devspace.yaml`
2. Call the `build_images` function inside the `pipelines` section of `devspace.yaml`
3. Execute the respective pipeline


### 1. Define `images`
Define as many images as need in your `devspace.yaml`:
```yaml
images:
  backend:
    dockerfile: ./Dockerfile
  frontend:
    dockerfile: ./frontend/Dockerfile
    context: ./frontend
  other: ...
```


### 2. Call `build_images` in Pipeline

<Tabs
  defaultValue="all"
  values={[
    { label: 'Build All Images', value: 'all', },
    { label: 'Build Single Image', value: 'single', },
    { label: 'Build Multiple Images', value: 'multiple', },
  ]
}>
<TabItem value="all">

```yaml
pipelines:
  build:
    run: |
      build_images --all
```

</TabItem>
<TabItem value="single">

```yaml
pipelines:
  build:
    run: |
      build_images backend
```

</TabItem>
<TabItem value="multiple">

```yaml
pipelines:
  build:
    run: |
      build_images backend frontend
```

</TabItem>
</Tabs>


### 3. Run Pipeline
Any of the pipelines shown above can be executed via:
- `devspace build` (shortcut)
- `devspace run-pipeline build` (long form)


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Imports README (`docs/pages/configuration/imports/README.mdx`)

---
title: Import Other devspace.yaml Files
sidebar_label: imports
---

import ConfigPartialImports from '../_partials/v2beta1/imports.mdx'


Importing other `devspace.yaml` files is a powerful way to standardize things across multiple projects. Common use cases include:
- Importing a library of custom [`functions`](../functions/README.mdx) that should be available in each project
- Importing a set of standardized [`pipelines`](../pipelines/README.mdx) to make the `devspace dev` behavior consistent across a set of projects
- Importing a set of custom [`commands`](../commands/README.mdx) that should be available for engineers in similar project (e.g. you want that all Java Spring Boot applications should provide a `devspace run migrate-db` command)


## Example
Let's say we have a `devspace.yaml` in `project-a` with the following content:
```yaml title="File: github.com/project-a/devspace.yaml"
version: v2beta1
imports:
- git: github.com/project-b.git
  tag: v1.2.0
- ...
functions:
  function_in_project_a_only: |-
    echo "This is a function only available in project a"
```

The `devspace.yaml` above imports the `devspace.yaml` from `project-b` which looks like this:
```yaml title="File: github.com/project-b/devspace.yaml"
version: v2beta1
functions:
  shared_function: |-
    echo "This is a shared function"
```

If we run `devspace print` inside `project-a`, it will show the following merged config:
```yaml title="project-a/ $ devspace print"
version: v2beta1
functions:
  shared_function: |-
    echo "This is a shared function"
  function_in_project_a_only: |-
    echo "This is a function only available in project a"
```


## `imports` vs `dependencies`
The following table clarifies when to use `imports` and when to use `dependencies`:

| Difference | `imports`                                                                                                                                                                           | `dependencies`                                                                                                                                                                                                       |
| ---------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Use Case   | Importing shared/standardized functionality (e.g. `functions`, `pipelines`, `commands`) into **independent** projects                                                               | Defining logical dependencies between **inter-dependent** projects (app A requiring app B to be deployed)                                                                                                                                                  |
| Example    | If projects A and B should both have some shared functionality that is defined in a shared `devspace.yaml`                                                                          | If a project A with requires projects B and C to be deployed in order to work correctly                                                                                                                              |
| Impact     | If project A imports a `devspace.yaml` from another `devspace.yaml`, then everything defined in this imported `devspace.yaml` will be merged into the `devspace.yaml` of project A. | If project A has a `devspace.yaml` that defines project B as a git-based `dependency`, then DevSpace will `git clone` project B and deploy it when you run `run_dependency_pipelines b` inside your pipeline script. |


## Naming Conflicts
If a project imports a `devspace.yaml` that defines a named object (e.g. `function`, `pipeline`, etc.), the main `devspace.yaml` that is defining the `imports` takes precedence over the imported `devspace.yaml`.

Let's assume the following `devspace.yaml` inside `project-a`:
```yaml title="File: github.com/project-a/devspace.yaml"
version: v2beta1
imports:
- git: github.com/project-b.git
functions:
  function_x: |-
    echo "This is a function_x from project-a"
```

The `devspace.yaml` above imports the `devspace.yaml` from `project-b` which looks like this:
```yaml title="File: github.com/project-b/devspace.yaml"
version: v2beta1
functions:
  function_x: |-
    echo "This is function_x from project-b"
```

If we run `devspace print` inside `project-a`, it will show the following merged config:
```yaml title="project-a/ $ devspace print"
version: v2beta1
functions:
  function_x: |-
    echo "This is a function_x from project-a"
```

## Import Sections
The following DevSpace config sections are allowed to be imported:
```
/require/*
/vars/*
/dev/*
/deployments/*
/images/*
/localRegistry/*
/pipelines/*
/commands/*
/functions/*
/pullSecrets/*
/dependencies/*
/profiles/*
/hooks/*
```

All other config sections will be ignored during import.

## Config Reference
The `imports` section in your `devspace.yaml` file is an array and each entry (import) supports the following fields:

<ConfigPartialImports/>

---

### Pages Configuration LocalRegistry README (`docs/pages/configuration/localRegistry/README.mdx`)

---
title: Local Registry
sidebar_label: localRegistry
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import ConfigPartial from '../_partials/v2beta1/localRegistry.mdx'

DevSpace will detect when the local environment lacks push permissions for an image's registry. If the destination cluster is a local [KinD](https://kind.sigs.k8s.io/) cluster, images will be loaded using `kind load docker-image`. For other clusters, DevSpace will deploy a local image registry to the cluster and update the image URLs to use this local registry.

Unless persistence is enabled, the local registry will be deployed using a `Deployment` and an `emptyDir` volume, meaning your registry images will not be persisted during local registry restarts. Persistence using a `StatefulSet` and persistent volumes can be configured if you wish to avoid repeated image pushes.

Local registry configuration is defined in the `localRegistry` section of the `devspace.yaml`.

:::note
localRegistry currently only supports docker and buildkit
:::

<Tabs
    defaultValue="default"
    values={[
        { label: 'Defaults', value: 'default', },
        { label: 'Build locally with Docker/Podman', value: 'localbuild', },
        { label: 'Force Local Registry', value: 'force', },
        { label: 'Persistence', value: 'persistence', },
    ]
    }>
<TabItem value="default">

```yaml
# If you do not configure anything, the local registry will be deployed with the following
# defaults when the image cannot be pushed and 'kind load docker-image' cannot be used.
# 
# localRegistry:
#   name: registry
#   namespace: [KUBE CONTEXT NAMESPACE]
#   localbuild: false
#   image: registry:2.8.1
#   port: 5000
```

</TabItem>
<TabItem value="localbuild">

```yaml
# The local registry will not use buildkit on the cluster, but your docker/podman daemon
# and then push it to the local registry in the cluster
localRegistry:
  localbuild: true
```

</TabItem>
<TabItem value="persistence">

```yaml
# The local registry will use an emptyDir volume by default. If the registry is restarted all
# previously pushed images will be lost. If you wish to add persistence, here is an example
# using the cluster's default storage class and a 10Gi volume size.
localRegistry:
  persistence:
    enabled: true
    size: 10Gi
```

</TabItem>
<TabItem value="force">

```yaml
# If you want to always use the local registry.
localRegistry:
  enabled: true
```

</TabItem>
</Tabs>

## Image URLs
The local registry is deployed with a NodePort service and will be assigned a port by the Kubernetes control plane. DevSpace will transparently update all image URLs to refer to the local registry using **`localhost:[NODE_PORT]`**. This applies to every location the image is used, however no modifications will be saved to the `devspace.yaml` on disk.

```yaml title=devspace.yaml
images:
  backend:
    # highlight-start
    image: ghcr.io/org/project/image           # localhost:[NODE_PORT]/org/project/image
    # highlight-end
  backend-dev:
    # highlight-start
    image: ghcr.io/org/project/image-dev       # localhost:[NODE_PORT]/org/project/image-dev
    # highlight-end

deployments:
  backend:
    helm:
      values:
        containers:
          # highlight-start
          - image: ghcr.io/org/project/image   # localhost:[NODE_PORT]/org/project/image
          # highlight-end

dev:
  backend:
    # highlight-start
    imageSelector: ghcr.io/org/project/image   # localhost:[NODE_PORT]/org/project/image
    devImage: ghcr.io/org/project/image-dev    # localhost:[NODE_PORT]/org/project/image-dev
    # highlight-end
```

## Runtime Variables
In addition to image URLs, the following runtime variables are updated to the local registry URL:
- **`runtime.images.IMAGE_NAME`**
- **`runtime.images.IMAGE_NAME.image`**

Similarly, the following hook environment variable is updated to the local registry URL:
- **`$DEVSPACE_HOOK_IMAGE_NAME`**

## Configuration

<ConfigPartial/>

---

### Pages Configuration Pipelines README (`docs/pages/configuration/pipelines/README.mdx`)

---
title: Pipelines
sidebar_label: pipelines
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import ConfigPartialPipeline from '../_partials/v2beta1/pipelines.mdx'
import PipelineFunctionRef from '../_partials/functions/reference_pipeline.mdx'
import GlobalFunctionRef from '../_partials/functions/reference_global.mdx'

Pipelines allow you to fully customize the execution logic in DevSpace, i.e. they define what happens when a users run commands such as `devspace dev`, `devspace build`, `devspace deploy` or `devspace run-pipeline my-custom-pipeline`

Pipelines are defined in POSIX shell syntax and a DevSpace pipeline reads as a regular POSIX script. However, DevSpace implements certain special commands that can be used inside the POSIX script to tell DevSpace when to build, deploy or start developing. For a complete function reference, please take a look below.

<br />

<Tabs
  defaultValue="executionorder"
  values={[
    { label: 'Execution Order', value: 'executionorder' },
    { label: 'Dynamic Config', value: 'configoverride' },
    { label: 'Rerun Pipeline', value: 'rerun' },
    { label: 'Deploy / Sync / Open', value: 'deploywaitsync', },
    { label: 'Custom Dockerfile Flag', value: 'dockerfile', },
  ]
}>
<TabItem value="configoverride">

```yaml
# Simple deployment that deploys an nginx pod
deployments:
  test:
    helm:
      values:
        containers:
        - image: nginx

pipelines:
  deploy: |-
    # You can use the --set, --set-string, --from and --from-file
    # arguments to dynamically change the config of the images,
    # deployments or dev configurations you want to use inside the
    # pipeline.

    # Exchange the image in our deployment
    if is_equal ${DEVSPACE_NAMESPACE} "test"; then
      create_deployments test --set "helm.values.containers[0].image=bitnami/nginx"
    fi

    # Create a new deployment based on another deployment and change the image.
    # This will copy over the values from the test deployment and then change the image
    create_deployments nginx --from test \
                             --set helm.values.containers[0].image=mysql

    # Create a new deployment from a file. ${DEVSPACE_TMPDIR} is always cleaned up
    # after each run
    echo """
    helm:
      values:
        containers:
        - image: nginx
    """ > ${DEVSPACE_TMPDIR}/my-deployment.yaml
    create_deployments nginx-from-file --from-file ${DEVSPACE_TMPDIR}/my-deployment.yaml

    # Force the container name to be a string (true) as DevSpace will otherwise convert
    # those automatically.
    create_deployments nginx-string-annotation --from test \
                                               --set-string "helm.values.containers[0].name=true"
```

</TabItem>
<TabItem value="executionorder">

```yaml
pipelines:
  deploy: |-
    # Pipelines are a great tool to define your custom execution order of
    # building, deploying and starting dev configurations. This works for
    # all special commands such as: build_images, create_deployments, start_dev
    # run_dependencies and run_pipelines.

    # Run two pipelines in parallel
    run_pipelines other-pipeline-1 other-pipeline-2

    # Wait until all 4 deployments were deployed
    echo "All deployments are deployed"

  other-pipeline-1: |-
    # Deploys deployments deploy-a and deploy-b in parallel
    create_deployments deploy-a deploy-b
    echo "Deployment deploy-a and deploy-b are deployed"

  other-pipeline-2: |-
    # Deploys deployments deploy-c and then deploy-d
    create_deployments deploy-c
    echo "Deployment deploy-c is deployed"
    create_deployments deploy-d
    echo "Deployment deploy-d is deployed"


deployments:
  deploy-a: ...
  deploy-b: ...
  deploy-c: ...
  deploy-d: ...
```

</TabItem>
<TabItem value="rerun">

```yaml
pipelines:
  deploy: |-
    # This pipeline watches a secret and applies it as well as deploys the application
    # Start two pipelines in parallel
    run_pipelines watch-secret default-deploy

  watch-secret: |-
    # Rerun the pipeline as soon as the secret.yaml changes
    run_watch -p secret.yaml -- kubectl apply -n ${DEVSPACE_NAMESPACE} -f secret.yaml

  default-deploy: |-
    # Run regular deploy pipeline to start the application
    run_default_pipeline deploy

deployments: ...
dev: ...
```

</TabItem>
<TabItem value="deploywaitsync">

```yaml
pipelines:
  # Run with devspace run-pipeline custom-pipeline
  custom-pipeline: |-
    # Deploy simple nginx pod with the default DevSpace component chart
    create_deployments nginx --set helm.values.containers[0].image=nginx

    # Create a file we want to sync to the nginx pod
    echo "Hello World!" > ${DEVSPACE_TMPDIR}/index.html

    # Sync the file into the nginx pod via DevSpace sync
    start_dev nginx --set imageSelector=nginx \
                    --set "sync[0].path=${DEVSPACE_TMPDIR}:/usr/share/nginx/html" \
                    --set "sync[0].noWatch=true"

    # Print contents within the nginx pod
    exec_container --image-selector=nginx -- cat /usr/share/nginx/html/index.html

    # Start port-forwarding and open the url
    start_dev nginx --set imageSelector=nginx \
                    --set 'ports[0].port=8080:80' \
                    --set 'open[0].url=http://localhost:8080'
```

</TabItem>
<TabItem value="dockerfile">

```yaml
images:
  my-image:
    dockerfile: ./Dockerfile

pipelines:
  # Executed on 'devspace deploy'
  deploy:
    flags:
    - name: dockerfile
      description: If enabled, will build the image with the given dockerfile
      type: string
    run: |-
        if ! is_empty $(get_flag dockerfile); then
            echo "Building the image with the overriden dockerfile $(get_flag dockerfile)"
            run_default_pipeline deploy --set "images.my-image.dockerfile=$(get_flag dockerfile)"
        else
            run_default_pipeline deploy
        fi
```

</TabItem>
</Tabs>






## Using Pipelines

### 1. Define Pipelines
An example `pipelines` section could look like this in `devspace.yaml`:
```yaml title=devspace.yaml
version: v2beta1
pipelines:
  # Override the default pipeline for 'devspace dev'
  dev: |-
    run_dependency_pipelines --all    # 1. Deploy any projects this project needs (see "dependencies")
    create_deployments --all          # 2. Deploy Helm charts and manifests specfied as "deployments"
    start_dev app                     # 3. Start dev mode "app" (see "dev" section)
  deploy: |-
    run_dependency_pipelines --all                    # 1. Deploy any projects this project needs (see "dependencies")
    build_images --all -t $(git describe --always)    # 2. Build, tag (git commit hash) and push all images (see "images")
    create_deployments --all                          # 3. Deploy Helm charts and manifests specfied as "deployments"
  build:
    # Here we are using the long-form using `run:` instead of passing the script directly
    run: |-
      build_images --all -t $(git describe --always)
  custom: ...
```

Pipelines can:
- Call built-in functions such as `build_images`, `create_deployments` or `start_dev`
- Call functions defined in `devspace.yaml` or in any `import`
- Use bash-like syntax including `if []; then ... fi`, `&&`, `||` or `;`
- Access environment variables and DevSpace variables


### 2. Run Pipelines
Pipelines are invoked via:
```bash
devspace run-pipeline [name]
```

:::info Cross-Platform Execution
Write all pipeline scrips in `bash` fashion. DevSpace is using a library to make them cross-platform executable.
:::


## Default Pipelines
Internally DevSpace uses pipelines for the following commands that can be overriden according to your preferences. DevSpace provides default pipeline scripts for the following top-level commands:
- [`devspace dev`](#dev)
- [`devspace deploy`](#deploy)
- [`devspace build`](#build)
- [`devspace purge`](#purge)

<details>
<summary>

### `dev`

</summary>

The `dev` pipeline is executed by running `devspace dev` and has the following default workflow:

```bash
run_dependencies --all
ensure_pull_secrets --all
build_images --all
create_deployments --all
start_dev --all
```

</details>

<details>
<summary>

### `deploy`

</summary>

The `deploy` pipeline is executed by running `devspace deploy` and has the following default workflow:

```bash
run_dependencies --all
ensure_pull_secrets --all
build_images --all
create_deployments --all
```

</details>


<details>
<summary>

### `build`

</summary>

The `build` pipeline is executed by running `devspace build` and has the following default workflow:

```bash
run_dependencies --all --pipeline build
build_images --all
```

</details>


<details>
<summary>

### `purge`

</summary>

The `purge` pipeline is executed by running `devspace purge` and has the following default workflow:

```bash
stop_dev --all
purge_deployments --all
run_dependencies --all --pipeline purge
```

</details>


## Custom Flags
To add custom flags to commands such as `devspace dev` or `devspace run-pipeline my-custom-pipeline`, you can specify the `flags` field for the respective pipeline.

The following example defines two flags for `devspace dev`:
- `--logs / -l` with `type` not specified (defaults to `bool`)
- `--env / -e` with `type: stringArray`

```yaml title=devspace.yaml
version: v2beta1
pipelines:
  dev:
    flags:
    - name: logs
      short: l
    - name: env
      short: e
      type: stringArray
    run: |-
      extraEnv=($(get_flag "env"))    # Retrieve the value of the `env` flag and store it in an array variable
      echo ${extraEnv[0]}             # Arrays are zero indexed

      TERMINAL_ENABLED=true
      if [ $(get_flag "logs") == "true" ]; then     # Test if --logs/-l flag is used or not
        TERMINAL_ENABLED=false                      # Disable terminal, so DevSpace falls back to log streaming
      fi

      start_dev app --set terminal.enabled=$TERMINAL_ENABLED
```


## Built-In Functions
DevSpace provides a set of built-in functions. There are two types of functions:
1. [Pipeline-Only Functions](#pipeline-only-functions)
2. [Global Functions](#global-functions)

### Pipeline-Only Functions
Pipeline-only functions can only be used inside the scripts within the `pipelines` section of `devspace.yaml`.

<PipelineFunctionRef/>


### Global Functions
Global functions can be used anywhere in `devspace.yaml`, either in config fields that expect a bash script such as within `functions` or using [`$(command)` vars](../variables.mdx#from-commands) in any other config field.

<GlobalFunctionRef/>


## Config Reference

<ConfigPartialPipeline/>

---

### Pages Configuration Profiles README (`docs/pages/configuration/profiles/README.mdx`)

---
title: Config Profiles
sidebar_label: Basics
---

import FragmentInfoPrintConfig from '../../_partials/tip-print-config.mdx';
import FragmentApplyMultiple from '../../_partials/profiles-apply-multiple.mdx';

DevSpace allows you to define different profiles for different use cases (e.g. working on different services in the same project, starting certain debugging environments) or for different deployment targets (e.g. dev, staging production). 

Profiles allow you to define:
- [`replace`](../../configuration/profiles/replace.mdx) statements to override entire sections of the config.
- [`merge`](../../configuration/profiles/merge.mdx) patches ([JSON Merge Patch, RFC 7386](https://tools.ietf.org/html/rfc7386)) to change specific parts of the config.
- [`patches`](../../configuration/profiles/patches.mdx) ([JSON Patch, RFC 6902](https://tools.ietf.org/html/rfc6902)) to modify certain paths in the config.

:::note Combine several strategies
It is possible to use several strategies together within one profile. The execution order inside a single profile is:  
1. `replace`  
2. `merge`  
3. `patches`  

You can also apply multiple profiles through the `--profile` flag
:::

:::tip Debug Profiles

<FragmentInfoPrintConfig/>

:::

A profile has to be configured in the `profiles` section of the `devspace.yaml`.
```yaml {15-25}
images:
  backend:
    image: john/devbackend
  backend-debugger:
    image: john/debugger
deployments:
  backend:
    helm:
      values:
        containers:
        - image: john/devbackend
        - image: john/debugger
profiles:
- name: production
  patches:
  - op: replace
    path: images.backend.image
    value: john/prodbackend
  - op: remove
    path: deployments.backend.helm.values.containers[1]
  - op: add
    path: deployments.backend.helm.values.containers
    value:
      image: john/cache
```

## Useful Commands

### `devspace print -p [profile]`

<FragmentInfoPrintConfig/>

<FragmentApplyMultiple/>

### `devspace list profiles`
To get a list of available profiles, you can run this command:
```bash
devspace list profiles
```

### `devspace [deploy] -p [profile]`
Most DevSpace commands support the `-p / --profile` flag. Using this flag, you can run a single command with a different profile without switching your profile permenantly:
```bash
devspace build -p [PROFILE_NAME]
devspace deploy -p [PROFILE_NAME]
devspace dev -p [PROFILE_NAME]
devspace dev -i -p [PROFILE_NAME]
```

---

### Pages Configuration PullSecrets README (`docs/pages/configuration/pullSecrets/README.mdx`)

---
title: Pull Secrets
sidebar_label: pullSecrets
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import ConfigPartialPullSecrets from '../_partials/v2beta1/pullSecrets.mdx'

DevSpace allows you to configure additional [pull secrets](https://kubernetes.io/docs/tasks/configure-pod-container/pull-image-private-registry/) that should be created in the target namespace. For each configured pull secret in the `devspace.yaml`, DevSpace will create a secret in the target namespace and add the secret to the `imagePullSecrets` field of the service account.

For [images](../images/README.mdx), DevSpace will also automatically create a pull secret, if authentication data can be found in the local docker store and creation is [enabled](../images/README.mdx#8-create-pull-secrets) via `createPullSecret`. 

Image Pull Secrets are defined in the `pullSecrets` section of the `devspace.yaml`.

<Tabs
    defaultValue="password"
    values={[
        { label: 'With Password', value: 'password', },
        { label: 'From Docker', value: 'docker', },
        { label: 'Custom Secret & Service Account', value: 'custom', },
    ]
    }>
<TabItem value="password">

```yaml
# If you don't want to specify the password and username directly in the config
# you can use variables, .env file or save the credentials in the local docker store
pullSecrets:
  my-pullsecret:
    registry: my-registry.com:5000
    username: ${REGISTRY_USER}
    password: ${REGISTRY_PASSWORD}
```

</TabItem>
<TabItem value="docker">

```yaml
# If you leave out the username & password DevSpace will try
# to get these from the local docker store. Make sure you
# are logged into the registry with `docker login my-registry.com:5000`
pullSecrets:
  my-pullsecret:
    registry: my-registry.com:5000
```

</TabItem>
<TabItem value="custom">

```yaml
pullSecrets:
  my-pullsecret:
    registry: my-registry.com:5000
    secret: my-pull-secret-name
    serviceAccounts:
      - default
      - my-other-service-account
```

</TabItem>
</Tabs>

## Configuration

<ConfigPartialPullSecrets/>

---

### Pages Configuration Require README (`docs/pages/configuration/require/README.mdx`)

---
title: Required Versions
sidebar_label: require
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import ConfigPartialRequire from '../_partials/v2beta1/require.mdx'

DevSpace allows you to define certain requirements that must be met to use DevSpace for a certain project. This is useful if you want to ensure that all developers that use DevSpace in a project have a certain DevSpace version, specific plugins or commands installed. You can define one or multiple of:

- **DevSpace Version** (`require.devspace`): You can define a required DevSpace version 
- **Installed Plugins** (`require.plugins`): You can define required plugins and their version
- **Installed Commands** (`require.commands`): You can define arbitrary commands such as `kubectl` or `helm` that need to be present locally in a specific version or range

Requirements are defined in the `require` section of the `devspace.yaml`.

<Tabs
    defaultValue="devspace"
    values={[        
        { label: 'DevSpace Version', value: 'devspace', },
        { label: 'Plugins', value: 'plugins', },
        { label: 'Commands', value: 'commands', },
    ]
    }>
<TabItem value="devspace">

```yaml
# You can either specify an exact version or a version range or even
# multiple versions.
require: 
  devspace: '>= 4.0, < 6.0'
```

</TabItem>
<TabItem value="plugins">

```yaml
# Each plugin that is defined under plugins needs to be installed 
# in the required version.
require:
  plugins:
  - name: loft
    version: ">= 1.11.0"
```

</TabItem>
<TabItem value="commands">

```yaml
require:
  # By default devspace will try to call the command 'NAME version' 
  # and use the regex '(v\\d+\\.\\d+\\.\\d+)' to find the version
  commands:
  - name: helm
    version: '> 3.0.0'
  - name: my-custom-command
    # Override the default args
    versionArgs: ["--version"]
    # Override the default reg ex
    versionRegEx: "Version: (v?\\d+\\.\\d+\\.\\d+)"
    version: '4.6.7'
```

</TabItem>
</Tabs>

## Configuration

<ConfigPartialRequire/>

---

### Pages Configuration Deployments Helm README (`docs/pages/configuration/deployments/helm/README.mdx`)

---
title: Deploy Helm Charts
sidebar_label: helm
---

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import ConfigPartial from '../../_partials/v2beta1/deployments/helm.mdx'
import FragmentInfoComponentChart from '../../../_partials/info-component-chart.mdx';

To deploy Helm charts, you need to configure them within the `deployments` section of the `devspace.yaml`.

## Examples

<Tabs
  defaultValue="component"
  values={[
    { label: 'Component Chart', value: 'component', },
    { label: 'Custom Chart', value: 'remote', },
    { label: 'Local Chart', value: 'local', },
    { label: 'Git Chart Repo', value: 'git', },
  ]
}>
<TabItem value="component">

```yaml
deployments:
  backend:
    helm:
      chart:
        name: component-chart
        repo: https://charts.devspace.sh
      values:
        containers:
        - image: reg.tld/username/devspace
        service:
          ports:
          - port: 3000
```

<FragmentInfoComponentChart/>

</TabItem>
<TabItem value="remote">

```yaml {4-6}
deployments:
  backend:
    helm:
      chart:
        name: chart-name
        repo: https://my-charts.company.tld/
      values:
        # If registry.url/repo/image was found under images as well, will be
        # rewritten to registry.url/repo/image:generated_tag
        imageWithTag: registry.url/repo/image
        # If registry.url/repo/image was found under images.app as well, will be
        # rewritten to registry.url/repo/image
        imageWithoutTag: ${runtime.images.app.image}
        # If registry.url/repo/image was found under images.app as well, will be
        # rewritten to generated_tag
        onlyTag: ${runtime.images.app.tag}
```

</TabItem>
<TabItem value="local">

```yaml {5}
deployments:
  backend:
    helm:
      chart:
        name: ./path/to/chart
      values:
        # If registry.url/repo/image was found under images as well, will be
        # rewritten to registry.url/repo/image:generated_tag
        imageWithTag: registry.url/repo/image
        # If registry.url/repo/image was found under images.app as well, will be
        # rewritten to registry.url/repo/image
        imageWithoutTag: ${runtime.images.app.image}
        # If registry.url/repo/image was found under images.app as well, will be
        # rewritten to generated_tag
        onlyTag: ${runtime.images.app.tag}
```

</TabItem>

<TabItem value="git">

```yaml {5}
deployments:
  backend:
    helm:
      chart:
        git: https://github.com/<org>/<repo>.git
        # optional git configs
        branch: branchName
        tag: tag
        revision: revision
        subPath: subpath/chartdir
```

</TabItem>
</Tabs>


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Deployments Kubectl README (`docs/pages/configuration/deployments/kubectl/README.mdx`)

---
title: Deploy with kubectl
---


import ConfigPartial from '../../_partials/v2beta1/deployments/kubectl.mdx'


DevSpace supports two types of deployments aside from Helm charts:
- [`Manifests`](./manifests.mdx):
  - [`Kubernetes file manifests`](./manifests.mdx) (think `kubectl apply -f manifest.yaml`)
  - [`Kubernetes inline manifests`](./inline_manifests.mdx) (think `kubectl apply -f manifest.yaml`)
- [`Kustomizations`](./kustomizations.mdx) (think `kubectl apply -k kustomization/`)


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Dev Connections README (`docs/pages/configuration/dev/connections/README.mdx`)

---
title: Dev Workflows
---

import ConfigPartialSync from '../../_partials/v2beta1/dev/sync.mdx'
import ConfigPartialPorts from '../../_partials/v2beta1/dev/ports.mdx'
import ConfigPartialReversePorts from '../../_partials/v2beta1/dev/reversePorts.mdx'
import ConfigPartialTerminal from '../../_partials/v2beta1/dev/terminal.mdx'
import ConfigPartialAttach from '../../_partials/v2beta1/dev/attach.mdx'
import ConfigPartialLogs from '../../_partials/v2beta1/dev/logs.mdx'
import ConfigPartialSSH from '../../_partials/v2beta1/dev/ssh.mdx'
import ConfigPartialRestartHelper from '../../_partials/v2beta1/dev/restartHelper.mdx'
import ConfigPartialProxyCommands from '../../_partials/v2beta1/dev/proxyCommands.mdx'
import ConfigPartialOpen from '../../_partials/v2beta1/dev/open.mdx'

Dev connections defines how your local machine and IDE is connected to the dev container that runs in Kubernetes.

Common dev connections include:
- **[Bi-directional file sync](./file-sync.mdx)** to make sure files on localhost and inside the containers main working dir are kept in sync
- **[Port forwarding (and reverse port forwarding)](./port-forwarding.mdx)** to allow engineers to access services inside the dev container via localhost on their local machine (and vice versa)
- **[Connecting the local terminal to the dev container](./terminal.mdx)** either by starting a new terminal session, by attaching the container's entrypoint process, or by simply streaming the container logs
- **[Injecting an SSH server into the dev container](./ssh.mdx)** to SSH into the container, e.g. to use the remote environment capabilities in IDEs such as VS Code
- **[Auto-restart the container](./restart-helper.mdx)** to create a hot reloading experience without the need for image building
- **[Proxy certain commands](./proxy-commands.mdx)** to make commands on the local machine accessible inside the container (e.g. be able to run `kubectl` commands inside the dev container without having to copy credentials inside the dev container)
- **[Auto-open URLs](./open.mdx)** to provide a starting point for the engineer when the dev container is ready to go


## Config Reference

<ConfigPartialSync/>
<ConfigPartialPorts/>
<ConfigPartialReversePorts/>
<ConfigPartialTerminal/>
<ConfigPartialAttach/>
<ConfigPartialLogs/>
<ConfigPartialSSH/>
<ConfigPartialRestartHelper/>
<ConfigPartialProxyCommands/>
<ConfigPartialOpen/>

---

### Pages Configuration Dev Modifications README (`docs/pages/configuration/dev/modifications/README.mdx`)

---
title: Dev Container Modifications
sidebar_label: 2. Modify Container
---

import ConfigPartial from '../../_partials/v2beta1/dev/group_modifications.mdx'

DevSpace allows you to modify the selected dev container to optimize it for development.


## How does it work?
When any modifications are defined for a dev container, DevSpace will do the following:
1. Find the Kubernetes pod that contains the dev container according to the [selectors](../selectors/README.mdx) defined for this dev container.
2. Find the replica owner that this pod was created from (e.g. Deployment, StatefulSet, etc.)
3. Scale down the replica number for the replica owner object, i.e. set `replicas: 0` for the Deployment, StatefulSet, etc.
4. Clone the replica owner object to create a new Deployment/StatefulSet with the name `[old-object-name]-devspace`
5. Apply the modifications to the newly created Deployment/StatefulSet, e.g. swap out the image, add env vars, etc.
6. Wait until the a new pod was created from the new Deployment/StatefulSet


## Undo Modifications
To undo the changes that DevSpace made to create the modified version of our dev container, you can run:

```bash
devspace reset pods
```


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Dev Selectors README (`docs/pages/configuration/dev/selectors/README.mdx`)

---
title: Select Container as Dev Container
sidebar_label: 1. Select Dev Container
---

import ConfigPartial from '../../_partials/v2beta1/dev/group_selector.mdx'


The first step to turn a regular container deployed to your cluster into a dev container is to tell DevSpace how to find this container inside the cluster. You can achieve this by defining one or multiple selectors.

DevSpace supports the following selectors:
1. [`imageSelector`](./image.mdx) to select based on the image running the container
2. [`labelSelector`](#select-by-pod-labels) to select based on Kubernetes pod labels

Additionally, the following two fields can be used:
- `container` to select one specific container if a pod has multiple containers
- `namespace` to select containers from another namespace

:::tip Logical `&&` For Selectors
If multiple selectors (e.g. `imageSelector` and `labelSelector`) are specified, DevSpace will combine them with a logical AND (`&&`) when looking for a pod/container to match the specified conditions.
:::


## Config Reference

<ConfigPartial/>

---

### Pages Configuration Images Build Engines README (`docs/pages/configuration/images/build-engines/README.mdx`)

---
title: Build Engines
---

DevSpace supports the following build engines:
- [Docker](./docker.mdx)
- [Buildkit](./buildkit.mdx)
- [Kaniko](./kaniko.mdx)
- [Custom](./custom.mdx)

If no build engine is explicitly defined for the respective image, DevSpace uses:
1. Docker (if docker is installed and the Docker daemon is running)
2. Kaniko (as a fallback for Docker)

---

### Pages Configuration Deployments Helm Chart README (`docs/pages/configuration/deployments/helm/chart/README.mdx`)

---
title: Helm Charts
sidebar_label: Chart
---

import ConfigPartial from '../../../_partials/v2beta1/deployments/helm/chart.mdx'

DevSpace can deploy any Helm chart, including:
- [The DevSpace component-chart](./component-chart.mdx)
- [Local charts](./local.mdx) stored on your filesystem
- [Remote charts](./remote.mdx) stored in a remote Helm registry, in another git repository (e.g. infra repo), etc.


## Config Reference

<ConfigPartial/>

---

### Pages Cli (`docs/pages/cli.md`)

---
title: "devspace --help"
sidebar_label: devspace
---

## devspace

Welcome to the DevSpace!

### Synopsis

DevSpace accelerates developing, deploying and debugging applications with Docker and Kubernetes. Get started by running the init command in one of your projects:
	
		devspace init
		# Develop an existing application
		devspace dev
		DEVSPACE_CONFIG=other-config.yaml devspace dev

### Options

```
/* Detailed source-code truncated for AI context efficiency. */
```

```

```


## Flags
## Global & Inherited Flags

---

### Pages  Partials Choose Project (`docs/pages/_partials/choose-project.mdx`)

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';

<Tabs
  defaultValue="javascript"
  groupId="language"
  values={[
    { label: 'Node.js', value: 'javascript', },
    { label: 'Python', value: 'python', },
    { label: 'Java', value: 'java', },
    { label: 'Ruby', value: 'ruby', },
    { label: 'Golang', value: 'golang', },
    { label: 'PHP', value: 'php', },
    { label: 'ASP.NET', value: 'dotnet', },
    { label: 'Your Own Project', value: 'custom', },
  ]
}>
<TabItem value="javascript">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-nodejs
cd devspace-quickstart-nodejs
```

</TabItem>
<TabItem value="python">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-python
cd devspace-quickstart-python
```

</TabItem>
<TabItem value="ruby">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-ruby
cd devspace-quickstart-ruby
```

</TabItem>
<TabItem value="golang">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-golang
cd devspace-quickstart-golang
```

</TabItem>
<TabItem value="java">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-java
cd devspace-quickstart-java
```

</TabItem>
<TabItem value="php">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-php
cd devspace-quickstart-php
```

</TabItem>
<TabItem value="dotnet">

```bash
git clone https://github.com/loft-sh/devspace-quickstart-asp-dotnet
cd devspace-quickstart-asp-dotnet
```

</TabItem>
<TabItem value="custom">

```bash
# Navigate to the root directory of your project
cd /path/to/your/project
```

:::info 
If you are using DevSpace for the first time, it is highly recommended that you use one of the demo projects.
:::

</TabItem>
</Tabs>

---

### Pages  Partials Command Cat (`docs/pages/_partials/command_cat.mdx`)

The function `cat` prints the content of a given filename to the terminal.

## Arguments

### `[filename]`

Takes an existing filename.

```
cat [filename]
```

### Examples

Use `cat` as a function under your pipeline definitions:

```yaml
pipelines:
  dev:
    run: |-
      cat file.txt
```

---

### Pages  Partials Command Is Command (`docs/pages/_partials/command_is_command.mdx`)

The function `is_command` checks if a given argument is a command in DevSpace.

## Arguments

### `[DevSpace command]`

```
is_command [command]
```

### Example

```yaml
pipelines:
  dev:
    run: |-
      if is_command dev; then
        start_dev --all
      fi
```

---

### Pages  Partials Command Is Equal (`docs/pages/_partials/command_is_equal.mdx`)

The function `is_equal` checks if two given arguments are a command in DevSpace.

## Arguments

### `[arg1 arg2]`

```
is_equal [arg1] [arg2]
```

### Example

Use `is_equal` as a function under your pipeline definitions:

```yaml
pipelines:
  dev:
    run: |-
      is_equal 1 1
```
Returns exit status 0

```yaml
pipelines:
  dev:
    run: |-
      is_equal 1 2
```
Returns exist status 1 (fatal)

---

### Pages  Partials Command Is In (`docs/pages/_partials/command_is_in.mdx`)

The function `is_in` checks if the first argument can be found in the second argument.

## Arguments

### `[arg1 arg2]`

```
is_in [arg1] [arg2]
```

### Example

Use `is_in` as a function under your pipeline definitions:

```yaml
pipelines:
  dev:
    run: |-
      is_in apples "apples peaches"
```
Returns exit status 0

```yaml
pipelines:
  dev:
    run: |-
      is_in apples "peaches bananas"
```
Returns exist status 1 (fatal)

---

### Pages  Partials Command Is Os (`docs/pages/_partials/command_is_os.mdx`)

The function `is_os` checks if a given argument is the current runtime GOOS.

## Arguments

### `[operatingSystemString]`

```
is_os [os]
```

### Example

```yaml
pipelines:
  dev:
    run: |-
      if is_os windows; then
        echo "Running on Windows!"
      fi
```

---

### Pages  Partials Command Is True (`docs/pages/_partials/command_is_true.mdx`)

The function `is_true` checks for the string "true". NOTE: This function does not check for a boolean value.

## Arguments

### `["true"|<string>]`

```
is_true [value]
```

### Example

Use `is_true` as a function under your pipeline definitions:

```yaml
pipelines:
  dev:
    run: |-
      is_true true
```
Returns exit status 0

```yaml
pipelines:
  dev:
    run: |-
      is_true nope!
```
Returns exit status 1 (fatal)

---

### Pages  Partials Command Run Watch (`docs/pages/_partials/command_run_watch.mdx`)

The function `run_watch` takes in a path to watch and a subcommand to run on that path.

## Arguments

### `--fail-on-error`

If true, the command will fail on an error while running the subcommand.

```
run_watch --path [MY_PATH] -- [my_command]
```

### `--path`, `-p`

The paths to watch. Can be patterns in the form of `"./**/my-file.txt"`.

Please note that globgs need to be quoted in order to avoid them being expanded
by your shell, for example:


```
run_watch --path "**/*.go" -- devspace dev
```


```
```

### Example

```yaml
commands:
  # Overwrites dev
  dev: |-
    run_watch -p devspace.yaml -p *.go -- devspace run-pipeline dev $@
```

---

### Pages  Partials Command Sleep (`docs/pages/_partials/command_sleep.mdx`)

The function `sleep` takes in the number of seconds for a process to wait before continuing.

## Arguments

### [seconds]

```
sleep 5   # process waits for 5 seconds
```

### Example

Use `sleep` as a function under your pipeline definitions:

```yaml
pipelines:
  dev:
    run: |-
      sleep 5
```

---

### Pages  Partials Command Xargs (`docs/pages/_partials/command_xargs.mdx`)

The function `xargs` allows a user to overwrite current flags and utilities.

## Usage

```
xargs [utility [argument ...]]
```

## Arguments

### Example

```yaml
pipelines:
  dev:
    run: |-
      echo [image1] [image2] | xargs build_images
```

---

### Pages  Partials Config Commands (`docs/pages/_partials/config-commands.mdx`)

```yaml
commands:                             # struct[]  | Array of custom commands
- name: "debug-backend"               # string    | Name of the command to run via `devspace run debug-backend`
  command: "devspace dev -i backend"  # string    | Command to be executed when running `devspace run [name]`
  appendArgs: false                   # bool      | If true, DevSpace will append all arguments to the command
  args: ...                           # string[]  | Args for the command to be executed
```

---

### Pages  Partials Config Dependencies (`docs/pages/_partials/config-dependencies.mdx`)

```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Pages  Partials Config Deployments (`docs/pages/_partials/config-deployments.mdx`)

```yaml
deployments:                        # struct[] | Array of deployments
- name: my-deployment               # string   | Name of the deployment
  namespace: ""                     # string   | Namespace to deploy to (Default: "" = namespace of the active namespace/Space)
  disabled: false                   # bool     | If true, the deployment will not be deployed, purged or rendered
  concurrent: false                 # bool     | Deploy concurrently with other deployments that also have concurrency enabled (Default: false)
  helm: ...                         # struct   | Use Helm as deployment tool and set options for Helm
  kubectl: ...                      # struct   | Use "kubectl apply" as deployment tool and set options for kubectl
```

---

### Pages  Partials Config Dev (`docs/pages/_partials/config-dev.mdx`)

```yaml
dev:                                # struct   | Options for "devspace dev"
  ports: []                         # struct[] | Array of port-forwarding settings for selected pods
  open: []                          # struct[] | Array of auto-open settings
  sync: []                          # struct[] | Array of file sync settings for selected pods
  logs: ...                         # struct   | Options for configuring multi-container log streaming
  autoReload: ...                   # struct   | Options for auto-reloading (i.e. re-deploying deployments and re-building images)
  interactive: ...                  # struct   | Options for configuring the interactive mode
```

---

### Pages  Partials Config Hooks (`docs/pages/_partials/config-hooks.mdx`)

```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Pages  Partials Config Images (`docs/pages/_partials/config-images.mdx`)

```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Pages  Partials Config Overwrite Flags (`docs/pages/_partials/config-overwrite-flags.mdx`)

## Config Overwrite Flags

These flags can be used to overwrite values in the current configuration.

### `--set`

Set configuration.

Assigns argument to configuration.

```
devspace [command] --set=[configuration value]
```

### `--set-string`

Set configuration as string.

Takes a map and parses values to their new configuration keys.

```
devspace [command] --set-string=[key1:value1, key2:value2]
```

### `--from`

Reuse an existing configuration.

```
devspace [command] --from=[existing configuration]
```

### `--from-file`

Reuse an existing configuration from a file

```
devspace [command] --from-file=[path to existing configuration file]
```

### Example

---

### Pages  Partials Config Profiles (`docs/pages/_partials/config-profiles.mdx`)

```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Pages  Partials Config Vars (`docs/pages/_partials/config-vars.mdx`)

```
/* Detailed source-code truncated for AI context efficiency. */
```

---

### Pages  Partials Dependency Dev (`docs/pages/_partials/dependency-dev.mdx`)

The `dev` option allows you to reuse certain parts of a dependencies `dev` configuration.

:::note
If `dev` configuration is reused this will be merged into the top-level `devspace.yaml` and executed after image building and deployment
::: 

#### Example: Override Config Vars for Dependency
```yaml
# This will use the dev.ports configuration of the dependency
# component-1
dependencies:
- source:
    path: component-1
  dev:
    ports: true
```

### `dev.ports`

If enabled will reuse the dependency's `dev.ports` configuration. 

### `dev.sync`

If enabled will reuse the dependency's `dev.sync` configuration. **The base path of the sync configurations reused from a dependency is the folder where the dependency is saved in and not the current working directory.**

### `dev.replacePods`

If enabled will reuse the dependency's `dev.replacePods` configuration.

---

### Pages  Partials Dependency IgnoreDependencies (`docs/pages/_partials/dependency-ignoreDependencies.mdx`)

The `ignoreDependencies` option expects a boolean that defines if the dependencies of this dependencies should not be resolved and deployed.

:::info
Using `ignoreDependencies` can be useful to prevent problematic **circular dependencies**.
:::

#### Default Value For `ignoreDependencies`
```yaml
ignoreDependencies: false
```

#### Example: Ignore Dependencies of Dependency
```yaml
dependencies:
- source:
    git: https://github.com/my-api-server
  ignoreDependencies: true
```

---

### Pages  Partials Dependency Name (`docs/pages/_partials/dependency-name.mdx`)

The `name` option is optional and expects a string stating the name of this dependency.

:::note
Adding a `name` for a dependency makes it possible to reference the dependency using flags, e.g.
```bash
devspace deploy --dependency=[name]
devspace purge --dependency=[name]
devspace render --dependency=[name]
```
:::

---

### Pages  Partials Dependency Namespace (`docs/pages/_partials/dependency-namespace.mdx`)

The `namespace` option is optional and expects a string stating a namespace that should be used to deploy the dependency to.

:::note
By default, DevSpace deploys project dependencies in the same namespace as the project itself. 
:::

:::info
You should only use the `namespace` option if you are an advanced user because using this option requires any user that deploys this project to be able to create this namespace during the deployment process or to have access to the namespace with the current kube-context, if the namespace already exists.
:::

---

### Pages  Partials Dependency Overwrite Vars (`docs/pages/_partials/dependency-overwrite-vars.mdx`)

The `overwriteVars` option is optional and expects a boolean. If this option is enabled it will overwrite all defined variables within the dependency config with the values of the variables defined in the base config. Variables that are not used or not defined within the base config aren't overwritten in the dependency config.

For example:
```yaml
# devspace.yaml
vars:
- name: DEFINED_AND_USED
  value: my-base-value
- name: DEFINED_AND_NOT_USED
  value: my-other-base-value
dependencies:
- name: dep1
  source:
    path: dep1
  overwriteVars: true
  # If overwriteVars is true, all variables that are used within this
  # config are passed to the dependency and will overwrite the values of variables with 
  # the same name there. In this case only the variable DEFINED_AND_USED
  # will be passed to the dependency, as DEFINED_AND_NOT_USED is not used within the config.
  # overwriteVars: true
  #
  # If you want to pass the variable DEFINED_AND_NOT_USED to the dependency as well,
  # you can either use it somewhere within the config or explicitly pass it to the dependency with vars.
  # vars:
  # - name: DEFINED_AND_NOT_USED
  #   value: ${DEFINED_AND_NOT_USED}
deployments:
- name: deployment
  helm:
    componentChart: true
    values:
      containers:
      - image: ${DEFINED_AND_USED}
```

and

```yaml
# dep1/devspace.yaml
vars:
- name: DEFINED_AND_USED
  value: my-dep-value
- name: DEFINED_AND_NOT_USED
  value: my-other-dep-value
deployments:
  # This will be my-other-dep-value
- name: ${DEFINED_AND_NOT_USED}
  helm:
    componentChart: true
    values:
      containers:
        # This will be my-base-value
      - image: ${DEFINED_AND_USED}
```

---

### Pages  Partials Dependency Profile (`docs/pages/_partials/dependency-profile.mdx`)

The `profile` option expects a string with the name of a profile defined in the `devspace.yaml` of this dependency. When configuring this option, this profile will be used to deploy the dependency, i.e. the dependency will be deployed similar to running `devspace deploy -p [profile]` within the folder of the dependency.

#### Example: Use Config Profile for Dependency
```yaml
dependencies:
- source:
    git: https://github.com/my-api-server
  profile: production
```

---

### Pages  Partials Dependency SkipBuild (`docs/pages/_partials/dependency-skipBuild.mdx`)

The `skipBuild` option expects a boolean that defines if the image building process should be skipped when deploying this dependency. This is often useful if you rather want to use the tags that are defined in the deployment files (e.g. manifests or helm charts) which may reference more stable, production-like versions of the images.

:::info
Using `skipBuild` is useful when trying to speed up the dependency deployment process, especially when working with many dependencies that frequently change.
:::

#### Default Value For `skipBuild`
```yaml
skipBuild: false
```

#### Example: Skip Build for Dependency
```yaml
dependencies:
- source:
    git: https://github.com/my-api-server
  skipBuild: true
```

---

### Pages  Partials Dependency Vars (`docs/pages/_partials/dependency-vars.mdx`)

The `vars` option expects an array of objects with name and value of variables defined in the `devspace.yaml` of this dependency. When configuring this option, the variables will be overriden similar to passing variables via the `--var` flag to devspace.
It is also useful to deploy the same dependency multiple times with just small adjustments.

#### Example: Override Config Vars for Dependency
```yaml
# This will deploy the api server two times with
# different variable configurations
dependencies:
- source:
    git: https://github.com/my-api-server
  vars:
  - name: NAME
    value: api-server-1
- source:
    git: https://github.com/my-api-server
  vars:
  - name: NAME
    value: api-server-2
```

---

### Pages  Partials Faq Image Context (`docs/pages/_partials/faq-image-context.mdx`)

<details>
<summary>What does "context" mean in terms of image building?</summary>

<br/>

The context is archived and sent to the Docker daemon before starting to process the Dockerfile. All references of local files within the Dockerfile are relative to the root directory of the context. 

That means that a Dockerfile statement such as `COPY ./src /app` would copy the folder `src/` within the context path into the path `/app` within the container image. So, if the context would be `/my/project/database`, for example, the folder that would be copied into `/app` would have the absolute path `/my/project/database/src` on your local computer.

</details>

---

### Pages  Partials Info Component Chart (`docs/pages/_partials/info-component-chart.mdx`)

:::info Component Chart Docs
The component chart is a flexible Helm chart for deploying custom applications in a standardized manner. Learn more about **[configuring component-chart deployments](../configuration/deployments/helm/chart/component-chart.mdx)**.
:::

---

### Pages  Partials Install Cli (`docs/pages/_partials/install-cli.mdx`)

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';


DevSpace is a client-only binary. It is super lightweight, does not require any server-side component, and it does not have any dependencies.

<Tabs
  defaultValue="brew"
  values={[
    { label: 'brew', value: 'brew', },
    { label: 'Mac', value: 'mac', },
    { label: 'Linux', value: 'linux', },
    { label: 'Windows Powershell', value: 'windows-ps', },
    { label: 'Windows Scoop', value: 'windows-scoop', },
  ]
}>
<TabItem value="brew">

```bash
brew install devspace
```

</TabItem>
<TabItem value="mac">

```bash
# AMD64 / Intel
curl -L -o devspace "https://github.com/loft-sh/devspace/releases/latest/download/devspace-darwin-amd64" && sudo install -c -m 0755 devspace /usr/local/bin

# ARM64 / Silicon Mac
curl -L -o devspace "https://github.com/loft-sh/devspace/releases/latest/download/devspace-darwin-arm64" && sudo install -c -m 0755 devspace /usr/local/bin
```

</TabItem>
<TabItem value="linux">

```bash
# AMD64
curl -L -o devspace "https://github.com/loft-sh/devspace/releases/latest/download/devspace-linux-amd64" && sudo install -c -m 0755 devspace /usr/local/bin

# ARM64
curl -L -o devspace "https://github.com/loft-sh/devspace/releases/latest/download/devspace-linux-arm64" && sudo install -c -m 0755 devspace /usr/local/bin
```

</TabItem>
<TabItem value="windows-ps">

```powershell
md -Force "$Env:APPDATA\devspace"; [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]'Tls,Tls11,Tls12';
Invoke-WebRequest -URI "https://github.com/loft-sh/devspace/releases/latest/download/devspace-windows-amd64.exe" -o $Env:APPDATA\devspace\devspace.exe;
$env:Path += ";" + $Env:APPDATA + "\devspace";
[Environment]::SetEnvironmentVariable("Path", $env:Path, [System.EnvironmentVariableTarget]::User);
```

</TabItem>
<TabItem value="windows-scoop">

```powershell
scoop install devspace
```

</TabItem>
</Tabs>

Alternatively, you can simply download the binary for your platform from the [GitHub Releases](https://github.com/loft-sh/devspace/releases) page and add this binary to your PATH.

---

### Pages  Partials Kube Context (`docs/pages/_partials/kube-context.mdx`)

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';
import Step from '@site/src/components/Step/Step';
import FragmentTipUseNamespace from './tip-use-namespace.mdx';
import FragmentNoteCreateSpace from './note-create-space.mdx';

<Tabs
  defaultValue="local"
  values={[
    { label: 'Local Cluster', value: 'local', },
    { label: 'Remote Cluster', value: 'remote', },
  ]
}>
<TabItem value="local">

:::note Local Clusters
Local clusters run on your local dev machine and include: minikube, kind, k3s, mikrok8s etc.
:::

If you want to deploy to a local Kubernetes cluster, make sure your **current kube-context** points to this cluster and tell DevSpace which namespace to use:

```bash
devspace use context                  # to select the right k8s cluster
devspace use namespace my-namespace   # will be automatically created during deployment
```

<FragmentTipUseNamespace/>

</TabItem>
<TabItem value="remote">

:::note Remote Clusters
Remote clusters run in a cloud or private data center and include: GKE, EKS, AKS, bare metal etc.
:::

<Tabs
  defaultValue="alone"
  values={[
    { label: 'Use cluster alone', value: 'alone', },
    { label: 'Share cluster with others', value: 'shared', },
  ]
}>
<TabItem value="alone">

```bash
devspace use context                  # to select the right k8s cluster
devspace use namespace my-namespace   # will be automatically created during deployment
```

<FragmentTipUseNamespace/>

</TabItem>
<TabItem value="shared">

#### Kubernetes multi-tenancy

One of the options for setting up a multi-tenant Kubernetes environment would be to use [Loft](https://loft.sh/).
It allows the developers to create isolated Kubernetes environments in a self-service fashion.

[Loft](https://loft.sh/) offers a wide range of features to facilitate multi-tenancy in Kubernetes. One of such features is the ability to create [Virtual Clusters](https://loft.sh/features/virtual-kubernetes-clusters) - a lightweight, fully functional and certified Kubernetes distribution that runs fully within the host cluster. 

[Loft](https://loft.sh/) also adds a resource called "Space" into your Kubernetes cluster. A "Space" is a virtual representation of a Kubernetes namespace, and we will be creating one in the steps below.


#### How to use Loft

<Step>1</Step>

#### Setup Loft and connect your cluster

See the [Loft getting started guide](https://loft.sh/docs/getting-started/setup) for details.

<br/>
<Step>2</Step>

#### Install the Loft plugin for DevSpace

```bash
devspace add plugin https://github.com/loft-sh/loft-devspace-plugin
```

<br/>
<Step>3</Step>

#### Login to Loft via DevSpace

```bash
devspace login https://your-loft-instance.tld
```

<br/>
<Step>4</Step>

#### Create isolated namespaces (= Spaces)

```bash
devspace create space my-app
```

<FragmentNoteCreateSpace/>

<br/>
<Step>5</Step>

#### Add cluster users and allow them to create Spaces

Learn more about how to do this in the [Loft documentation](https://loft.sh/docs/getting-started/cluster-accounts).

</TabItem>
</Tabs>

</TabItem>
</Tabs>

---

### Pages  Partials Kubectl Kustomize (`docs/pages/_partials/kubectl-kustomize.mdx`)

The `kustomize` option expects a boolean stating if DevSpace should deploy using `kustomize` (or alternatively: `kubectl apply -k` when `kustomize` is not installed).

:::warning
If you set `kustomize: true`, all of your `manifests` must be paths to Kustomizations. If you want to deploy some plain manifests and some Kustomizations, create multiple deployments for each of them.
:::

#### Default Value for `kustomize`
```yaml
kustomize: false
```

#### Example: Kustomize
```yaml {4}
deployments:
  backend:
    kubectl:
      kustomize: true
      manifests:
      - kustomization1/
      - glob/path/to/more/kustomizations/
```

---

### Pages  Partials Kubectl Options ApplyArgs (`docs/pages/_partials/kubectl-options-applyArgs.mdx`)

The `applyArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kubectl apply`.

:::info Apply for Kustomize Deployments
Even if you set `kustomize: true`, DevSpace only renders the manifest templates using kustomize but the actual deployment will be executed using `kubectl apply`.
:::

#### Example: Custom Kubectl Args & Flags
```yaml
deployments:
  backend:
    kubectl:
      manifests:
      - backend/
      applyArgs:
      - "--timeout"
      - "10s"
      - "--grace-period"
      - "30"
```
Deploying the above example would roughly be equivalent to this command:
```bash
kubectl apply --timeout=10s --grace-period=30 -f backend/
```

---

### Pages  Partials Kubectl Options BinaryPath (`docs/pages/_partials/kubectl-options-binaryPath.mdx`)

The `kubectlBinaryPath` is optional expects a path to the `kubectl` binary. By default, DevSpace will use the `kustomize` located on your `$PATH`.  Use this to specify a location for `kubectl` if it is not on your `$PATH` and you do not want DevSpace to download the latest version.

:::warning
Setting `kubectlBinaryPath` makes it much harder to share your `devspace.yaml` with other team mates. It is recommended to add `kubectl` to your `$PATH` environment variable instead.
:::

#### Example: Setting Path To Kubectl Binary
```yaml
deployments:
  backend:
    kubectl:
      kubectlBinaryPath: /path/to/kubectl
      manifests:
      - backend/
```
**Explanation:**  
Deploying the above example would roughly be equivalent to this command:
```bash
/path/to/kubectl apply -f backend/
```

---

### Pages  Partials Kubectl UpdateImageTags (`docs/pages/_partials/kubectl-updateImageTags.mdx`)

If the `updateImageTags` field is set to `true` for a deployment, DevSpace will replace/update all image tags before deploying the project.

When enabled, DevSpace searches all your manifests for images that are defined in the `images` section of the `devspace.yaml`. If DevSpace finds an image, it replaces or appends the image tag with the tag it created during the image building process. Image tag replacement makes sure that your application will always be started with the most up-to-date image that DevSpace has built for you.

#### Example: Enable Tag Updates
```yaml {3}
deployments:
  backend:
    updateImageTags: true
    kubectl:
      manifests:
      - backend/
```

:::info In-Memory Tag Replacement
Tag replacement takes place **in-memory** and is **not** writing anything to the filesystem, i.e. it will **never** change any of your configuration files.
:::

---

### Pages  Partials Kustomize Options KustomizeArgs (`docs/pages/_partials/kustomize-options-kustomizeArgs.mdx`)

The `kustomizeArgs` option expects an array of strings stating additional arguments (and flags) that should be used when calling `kustomize build`.

#### Example: Custom Kustomize Args & Flags
```yaml
deployments:
- name: backend
  kubectl:
    manifests:
    - backend/
    kustomize: true
    kustomizeArgs:
    - "--timeout"
    - "10s"
    - "--grace-period"
    - "30"
```
Deploying the above example would roughly be equivalent to this command:
```bash
kustomize build --timeout=10s --grace-period=30 -f backend/
```

**Note:** Directly copying the example shown above would result in your deploy failing (it would result in `Error: unknown flag: --timeout`).

---

### Pages  Partials Note Create Space (`docs/pages/_partials/note-create-space.mdx`)

:::note Kube-Context
DevSpace automatically sets up a kube-context for this Space, so you can also access your namespace using `kubectl`, `helm` or any other Kubernetes tool. Try it:
```bash
kubectl get pods
```
:::

---

### Pages  Partials Note General Purpose Command (`docs/pages/_partials/note-general-purpose-command.mdx`)

:::note
This command is a general purpose command which also works for any pod/container in Kubernetes even if you are not within a DevSpace project.
:::

---

### Pages  Partials Profiles Apply Multiple (`docs/pages/_partials/profiles-apply-multiple.mdx`)

:::tip Apply Multiple Profiles with Flags

It is possible to apply multiple profiles in a single command with the `--profile` flag. This flag can take one or multiple profiles that will be applied in the order that they are specified.

Example:
```
# Apply profile1, profile2 and profile3 in this order
devspace print --profile profile1 --profile profile2 --profile profile3
```

:::

---

### Pages  Partials Selector Image Selector (`docs/pages/_partials/selector-image-selector.mdx`)

The `imageSelector` option expects a string that specifies an image (e.g. `my-registry.com/lib/my-image:tag`) to select a target pod and container with. The newest running pod that has a container which matches this image will be selected by DevSpace.

In addition, you can also reference images from the `images` section in the `imageSelector` with:
- If the image in `imageSelector` matches a `images.*.image`, DevSpace will automatically append the latest built tag during runtime to the `imageSelector`.
- You can also let DevSpace resolve the target image and tag by using runtime variables `${runtime.images.IMAGE_NAME}`, `${runtime.images.IMAGE_NAME.image}` or `${runtime.images.IMAGE_NAME.tag}`

For example:
```yaml
images: 
  app: 
    image: my-registry.com/lib/my-image
dev:
  ...
  # DevSpace will search for the newest pod with a container that
  # uses my-registry.com/lib/other-image:latest
  - imageSelector: my-registry.com/lib/other-image:latest
  # DevSpace will search for the newest pod with a container that
  # uses my-registry.com/lib/my-image:xxxxx (latest built tag by DevSpace)
  - imageSelector: my-registry.com/lib/my-image
  # DevSpace will search for the newest pod with a container that
  # uses my-registry.com/lib/my-image:xxxxx (latest built tag by DevSpace)
  - imageSelector: ${runtime.images.app}
  # DevSpace will search for the newest pod with a container that
  # uses my-registry.com/lib/my-image:custom-tag
  - imageSelector: ${runtime.images.app.image}:custom-tag
  # DevSpace will search for the newest pod with a container that
  # uses my-registry.com/lib/my-image:xxxxx (latest built tag by DevSpace)
  - imageSelector: ${runtime.images.app.image}:${runtime.images.app.tag}
  # DevSpace will search for the newest pod with a container that
  # uses the image of app of dependency dep1 with the latest built tag by DevSpace
  - imageSelector: ${runtime.dependencies.dep1.images.app.image}:${runtime.dependencies.dep1.images.app.tag}
```

---

### Pages  Partials Selector Label Selector (`docs/pages/_partials/selector-label-selector.mdx`)

The `labelSelector` option expects a key-value map of strings with Kubernetes labels. This can be used to select the correct target pod with labels instead of the image name like `imageSelector` or `imageName`. If the pod you want to select has multiple containers, make sure to use `containerName` as well.

---

### Pages  Partials Start App (`docs/pages/_partials/start-app.mdx`)

import Tabs from '@theme/Tabs';
import TabItem from '@theme/TabItem';


<Tabs
  defaultValue="javascript"
  groupId="language"
  values={[
    { label: 'Node.js', value: 'javascript', },
    { label: 'Python', value: 'python', },
    { label: 'Java', value: 'java', },
    { label: 'Ruby', value: 'ruby', },
    { label: 'Golang', value: 'golang', },
    { label: 'PHP', value: 'php', },
    { label: 'ASP.NET', value: 'dotnet', },
    { label: 'Your Own Project', value: 'custom', },
  ]
}>
<TabItem value="javascript">

```bash
npm start  
# or: npm run dev
# or: yarn start
```

</TabItem>
<TabItem value="python">

```bash
python main.py
```

</TabItem>
<TabItem value="ruby">

```bash
bundle exec rails server -p 3000 -b 0.0.0.0
```

</TabItem>
<TabItem value="golang">

```bash
go run main.go
```

</TabItem>
<TabItem value="java">

```bash
./build.sh run
```

</TabItem>
<TabItem value="php">

```bash
# Your application may already be running
# Try to open the browser on localhost to access it

# You can also run other commands now:
php ...
composer ...
ps aux
```

</TabItem>
<TabItem value="dotnet">

```bash
dotnet run
```

</TabItem>
<TabItem value="custom">

```bash
# Whatever command is needed to start your application
```

</TabItem>
</Tabs>

---

### Pages  Partials Tip Print Config (`docs/pages/_partials/tip-print-config.mdx`)

The following command is useful to verify that the profile modifies the config as intended:
```bash
devspace print -p profile-1 -p profile-2
```
The above command would print the config after applying all profile `patches` and `replace` statements from `profile-1` first and then `profile-2`.

---

### Pages  Partials Tip Use Namespace (`docs/pages/_partials/tip-use-namespace.mdx`)

:::tip Kube-Context Namespace
Running the command above will change the default namespace of your kube-context, i.e. instead of using the `default` namespace, `kubectl` and other tools will now use a different namespace when working with this kube-context. That also means, you will not always need to use the `--namespace / -n` flag.
:::

---

### Pages  Partials Vars Default (`docs/pages/_partials/vars-default.mdx`)

The `default` option expects a string, integer or boolean defining the default value for the variable. You can also use other variables in a default value, with one of the following conditions being true:
- The used variable is defined before the variable that wants to use it
- The used variable is a predefined variable

:::note Type Casting
If a default value is specified, DevSpace will assume the type of the default value as the type for the variable, i.e. when `default: "123"` is defined and a value of `123` (int) is provided it would be casted to `"123"` (string). To explicitly use the value of a variable as a string within `devspace.yaml`, use `$!{VAR_NAME}` instead of `${VAR_NAME}`.
:::

Example:
```yaml
images:
  default:
    image: ${IMAGE}
vars:
  - name: IMAGE_REPOSITORY
    default: myrepository
    source: none
  - name: IMAGE_NAME
    default: devspace
    source: none
  - name: IMAGE
    default: ${IMAGE_REPOSITORY}/${IMAGE_NAME}
    source: none
  - name: NAMESPACE
    default: ${devspace.namespace}
    source: none
```

---

### Pages  Partials Vars Force String (`docs/pages/_partials/vars-force-string.mdx`)

:::note Variable Type
By default, the type (string, int, bool) of variable will be determined by the type of its `default` value (if defined) or automatically detected if no default value is defined. To explicitly use the value of a variable as a string, use `$!{VAR_NAME}` instead of `${VAR_NAME}`.
:::

---

### Pages  Partials Vars Name (`docs/pages/_partials/vars-name.mdx`)

The `name` option expects a string stating the name of the config variable that will be used to reference it within the remainder of the configuration.

:::info Must be unique
The `name` of a config variable must be unique and is mandatory when defining a config variable.
:::

---

### Pages  Partials Warning Build Tool Priority (`docs/pages/_partials/warning-build-tool-priority.mdx`)

:::warning Build Tool Priority
If you specify multiple build tools, DevSpace will try to use them in the following order:
1. `disabled`
2. `custom`
3. `docker` (uses kaniko as fallback if Docker host not reachable)
4. `kaniko`
:::

---

### Pages  Partials Warning Multiple Dev (`docs/pages/_partials/warning-multiple-dev.mdx`)

:::warning
Running `devspace dev` multiple times in parallel for the <u>same project</u> does not work and returns a fatal error because multiple instances of port forwarding and file sync will disturb each other. However, running `devspace dev` for several different projects (i.e. 2 different `devspace.yaml` files with different `name`) works seamlessly.
:::

---

### Pages  Partials Workflow Build Images (`docs/pages/_partials/workflow-build-images.mdx`)

DevSpace triggers the image building process for the images specified in the `images` section of the `devspace.yaml`.

---

### Pages  Partials Workflow Deploy Dependencies (`docs/pages/_partials/workflow-deploy-dependencies.mdx`)

DevSpace loads the `dependencies` section from the `devspace.yaml` and creates a dependency tree. The current project will represent the root of this tree. Based on this dependency tree, DevSpace will start from the leaves and run these steps for each dependency:
- Build images of the dependency as configured in the `images` section of the dependency's `devspace.yaml` (unless `skipBuild: true`)
- Deploy the dependency as configured in the `deployments` section of the dependency's `devspace.yaml`

:::note What are Dendencies?
Dependencies allow you to deploy microservices, that the project you are currently deploying relies on. Dependencies can be located in a subpath of your project or they can be automatically loaded from a different git repository.
:::

---

### Pages  Partials Workflow Deploy Project (`docs/pages/_partials/workflow-deploy-project.mdx`)

DevSpace iterates over every item in the `deployments` array defined in the `devspace.yaml` and deploys each of the deployments using the respective deployment tool:
- `kubectl` deployments will be deployed with `kubectl` (optionally using `kustomize` if `kustomize: true`)
- `helm` deployments will be deployed with the `helm` client that comes in-built with DevSpace

:::info kubectl Required
Deployments with `kubectl` require `kubectl` to be installed.
:::

---

### Pages  Partials Workflow Open Links (`docs/pages/_partials/workflow-open-links.mdx`)

1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provideded via `dev.*.open[*].url`.
2. As soon as the first HTTP response has a status code which is neither 502 (Bad Gateway) nor 503 (Service Unavailable), DevSpace assumes that the application is now started, stops sending any further requests and opens the provided URL in the browser.
3. If the URL is still returning status code 502 or 503 after 4min, DevSpace will stop trying to open it. To not disturb the log streaming or the interactive terminal session, DevSpace will not show an error when hitting the 4min timeout.

---

### Pages  Partials Workflow Replace Tags (`docs/pages/_partials/workflow-replace-tags.mdx`)

After finishing the image building process, DevSpace searches your deployments for references to the images that are specified in the `images` section of the `devspace.yaml`. If DevSpace finds that an image is used by one of your deployments and the deployment does not explicitly define a tag for the image, DevSpace will append the tag that has been auto-generated as part of the automated image tagging during the image building process.

:::warning Prevent Hard-Coded Tags
To use automated tag replacement, make sure you do **not** specify image tags in the deployment configuration.
:::

Replacing or appending tags to images that are used in your deployments makes sure that your deployments are always started using the most recently pushed image tag. This automated process saves a lot of time compared to manually replacing image tags each time before you deploy something.

DevSpace will replace the following things:
- **registry.url/repo/name** that corresponds to a `images.*.image`, will be rewritten to `registry.url/repo/name:generated_tag`
- **`${runtime.images.image-key.image}`** that corresponds to a `images.*` key, will be rewritten to `registry.url/repo/name`. You can also use dependency images here with `${runtime.dependencies.dep1.images.dep-image.image}`
- **`${runtime.images.image-key.tag}`** that corresponds to a `images.*` key, will be rewritten to `generated_tag`. You can also use dependency images here with `${runtime.dependencies.dep1.images.dep-image.tag}`

---

### Pages Cli Devspace Add (`docs/pages/cli/devspace_add.md`)

---
title: "devspace add --help"
sidebar_label: devspace add
---


Adds something to devspace.yaml

## Synopsis


```
#######################################################
#################### devspace add #####################
#######################################################
Adds config sections to devspace.yaml
```


## Flags

```
  -h, --help   help for add
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Add Plugin (`docs/pages/cli/devspace_add_plugin.md`)

---
title: "devspace add plugin --help"
sidebar_label: devspace add plugin
---


Adds a plugin to devspace

## Synopsis


```
devspace add plugin [flags]
```

```
#######################################################
############### devspace add plugin ###################
#######################################################
Adds a new plugin to devspace

devspace add plugin https://github.com/my-plugin/plugin
#######################################################
```


## Flags

```
  -h, --help             help for plugin
      --version string   The git tag to use
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Analyze (`docs/pages/cli/devspace_analyze.md`)

---
title: "devspace analyze --help"
sidebar_label: devspace analyze
---


Analyzes a kubernetes namespace and checks for potential problems

## Synopsis


```
devspace analyze [flags]
```

```
#######################################################
################## devspace analyze ###################
#######################################################
Analyze checks a namespaces events, replicasets, services
and pods for potential problems

Example:
devspace analyze
devspace analyze --namespace=mynamespace
#######################################################
```


## Flags

```
  -h, --help                  help for analyze
      --ignore-pod-restarts   If true, analyze will ignore the restart events of running pods
      --patient               If true, analyze will ignore failing pods and events until every deployment, statefulset, replicaset and pods are ready or the timeout is reached
      --timeout int           Timeout until analyze should stop waiting (default 120)
      --wait                  Wait for pods to get ready if they are just starting (default true)
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Attach (`docs/pages/cli/devspace_attach.md`)

---
title: "devspace attach --help"
sidebar_label: devspace attach
---


Attaches to a container

## Synopsis


```
devspace attach [flags]
```

```
#######################################################
################# devspace attach #####################
#######################################################
Attaches to a running container

devspace attach
devspace attach --pick # Select pod to enter
devspace attach -c my-container
devspace attach -n my-namespace
#######################################################
```


## Flags

```
  -c, --container string        Container name within pod where to execute command
  -h, --help                    help for attach
      --image-selector string   The image to search a pod for (e.g. nginx, nginx:latest, ${runtime.images.app}, nginx:${runtime.images.app.tag})
  -l, --label-selector string   Comma separated key=value selector list (e.g. release=test)
      --pick                    Select a pod (default true)
      --pod string              Pod to open a shell to
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Build (`docs/pages/cli/devspace_build.md`)

---
title: "devspace build --help"
sidebar_label: devspace build
---


Builds all defined images and pushes them

## Synopsis


```
devspace build [flags]
```

```
#######################################################
################## devspace build #####################
#######################################################
Builds all defined images and pushes them
#######################################################
```


## Flags

```
      --build-sequential            Builds the images one after another instead of in parallel
      --dependency strings          Deploys only the specified named dependencies
  -b, --force-build                 Forces to build every image (default true)
  -d, --force-deploy                Forces to deploy every deployment
      --force-purge                 Forces to purge every deployment even though it might be in use by another DevSpace project
  -h, --help                        help for build
      --max-concurrent-builds int   The maximum number of image builds built in parallel (0 for infinite)
      --pipeline string             The pipeline to execute (default "build")
      --render                      If true will render manifests and print them instead of actually deploying them
      --sequential-dependencies     If set set true dependencies will run sequentially
      --show-ui                     Shows the ui server
      --skip-build                  Skips building of images
      --skip-dependency strings     Skips the following dependencies for deployment
      --skip-deploy                 If enabled will skip deploying
      --skip-push                   Skips image pushing, useful for minikube deployment
      --skip-push-local-kube        Skips image pushing, if a local kubernetes environment is detected (default true)
  -t, --tag strings                 Use the given tag for all built images
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Cleanup (`docs/pages/cli/devspace_cleanup.md`)

---
title: "devspace cleanup --help"
sidebar_label: devspace cleanup
---


Cleans up resources

## Synopsis


```
#######################################################
################## devspace cleanup ###################
#######################################################
```


## Flags

```
  -h, --help   help for cleanup
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Cleanup Images (`docs/pages/cli/devspace_cleanup_images.md`)

---
title: "devspace cleanup images --help"
sidebar_label: devspace cleanup images
---


Deletes all locally created images from docker

## Synopsis

 
```
devspace cleanup images [flags]
```

```
#######################################################
############# devspace cleanup images #################
#######################################################
Deletes all locally created docker images from docker
#######################################################
```


## Flags

```
  -h, --help   help for images
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Cleanup Local Registry (`docs/pages/cli/devspace_cleanup_local-registry.md`)

---
title: "devspace cleanup local-registry --help"
sidebar_label: devspace cleanup local-registry
---


Deletes the local image registry

## Synopsis

 
```
devspace cleanup local-registry [flags]
```

```
#######################################################
######### devspace cleanup local-registry #############
#######################################################
Deletes the local image registry
#######################################################
```


## Flags

```
  -h, --help   help for local-registry
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Completion (`docs/pages/cli/devspace_completion.md`)

---
title: "devspace completion --help"
sidebar_label: devspace completion
---


Outputs shell completion for the given shell (bash or zsh)

## Synopsis


	```
devspace completion SHELL [flags]
```

```
Outputs shell completion for the given shell (bash or zsh)

	This depends on the bash-completion binary.  Example installation instructions:
	OS X:
		$ brew install bash-completion
		$ source $(brew --prefix)/etc/bash_completion
		$ devspace completion bash > ~/.devspace-completion  # for bash users
		$ devspace completion fish > ~/.devspace-completion  # for fish users
		$ devspace completion zsh > ~/.devspace-completion   # for zsh users
		$ source ~/.devspace-completion
	Ubuntu:
		$ apt-get install bash-completion
		$ source /etc/bash-completion
		$ source <(devspace completion bash) # for bash users
		$ devspace completion fish | source # for fish users
		$ source <(devspace completion zsh)  # for zsh users

	Additionally, you may want to output the completion to a file and source in your .bashrc
```


## Flags

```
  -h, --help   help for completion
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Deploy (`docs/pages/cli/devspace_deploy.md`)

---
title: "devspace deploy --help"
sidebar_label: devspace deploy
---


Deploys the project

## Synopsis


```
devspace deploy [flags]
```

```
#######################################################
################## devspace deploy ####################
#######################################################
Deploys the current project to a Space or namespace:

devspace deploy
devspace deploy -n some-namespace
devspace deploy --kube-context=deploy-context
#######################################################
```


## Flags

```
      --build-sequential            Builds the images one after another instead of in parallel
      --dependency strings          Deploys only the specified named dependencies
  -b, --force-build                 Forces to build every image
  -d, --force-deploy                Forces to deploy every deployment
      --force-purge                 Forces to purge every deployment even though it might be in use by another DevSpace project
  -h, --help                        help for deploy
      --max-concurrent-builds int   The maximum number of image builds built in parallel (0 for infinite)
      --pipeline string             The pipeline to execute (default "deploy")
      --render                      If true will render manifests and print them instead of actually deploying them
      --sequential-dependencies     If set set true dependencies will run sequentially
      --show-ui                     Shows the ui server
      --skip-build                  Skips building of images
      --skip-dependency strings     Skips the following dependencies for deployment
      --skip-deploy                 If enabled will skip deploying
      --skip-push                   Skips image pushing, useful for minikube deployment
      --skip-push-local-kube        Skips image pushing, if a local kubernetes environment is detected (default true)
  -t, --tag strings                 Use the given tag for all built images
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Dev (`docs/pages/cli/devspace_dev.md`)

---
title: "devspace dev --help"
sidebar_label: devspace dev
---


Starts the development mode

## Synopsis


```
devspace dev [flags]
```

```
#######################################################
################### devspace dev ######################
#######################################################
Starts your project in development mode
#######################################################
```


## Flags

```
      --build-sequential            Builds the images one after another instead of in parallel
      --dependency strings          Deploys only the specified named dependencies
  -b, --force-build                 Forces to build every image
  -d, --force-deploy                Forces to deploy every deployment
      --force-purge                 Forces to purge every deployment even though it might be in use by another DevSpace project
  -h, --help                        help for dev
      --max-concurrent-builds int   The maximum number of image builds built in parallel (0 for infinite)
      --pipeline string             The pipeline to execute (default "dev")
      --render                      If true will render manifests and print them instead of actually deploying them
      --sequential-dependencies     If set set true dependencies will run sequentially
      --show-ui                     Shows the ui server
      --skip-build                  Skips building of images
      --skip-dependency strings     Skips the following dependencies for deployment
      --skip-deploy                 If enabled will skip deploying
      --skip-push                   Skips image pushing, useful for minikube deployment
      --skip-push-local-kube        Skips image pushing, if a local kubernetes environment is detected (default true)
  -t, --tag strings                 Use the given tag for all built images
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Enter (`docs/pages/cli/devspace_enter.md`)

---
title: "devspace enter --help"
sidebar_label: devspace enter
---


Open a shell to a container

## Synopsis


```
devspace enter [flags]
```

```
#######################################################
################## devspace enter #####################
#######################################################
Execute a command or start a new terminal in your 
devspace:

devspace enter
devspace enter --pick # Select pod to enter
devspace enter bash
devspace enter -c my-container
devspace enter bash -n my-namespace
devspace enter bash -l release=test
devspace enter bash --image-selector nginx:latest
devspace enter bash --image-selector "${runtime.images.app.image}:${runtime.images.app.tag}"
#######################################################
```


## Flags

```
  -c, --container string        Container name within pod where to execute command
  -h, --help                    help for enter
      --image-selector string   The image to search a pod for (e.g. nginx, nginx:latest, ${runtime.images.app}, nginx:${runtime.images.app.tag})
  -l, --label-selector string   Comma separated key=value selector list (e.g. release=test)
      --pick                    Select a pod / container if multiple are found (default true)
      --pod string              Pod to open a shell to
      --reconnect               Will reconnect the terminal if an unexpected return code is encountered
      --screen                  Use a screen session to connect
      --screen-session string   The screen session to create or connect to (default "enter")
      --tty                     If to use a tty to start the command (default true)
      --wait                    Wait for the pod(s) to start if they are not running
      --workdir string          The working directory where to open the terminal or execute the command
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace Init (`docs/pages/cli/devspace_init.md`)

---
title: "devspace init --help"
sidebar_label: devspace init
---


Initializes DevSpace in the current folder

## Synopsis


```
devspace init [flags]
```

```
#######################################################
#################### devspace init ####################
#######################################################
Initializes a new devspace project within the current
folder. Creates a devspace.yaml as a starting point.
#######################################################
```


## Flags

```
      --context string      Context path to use for intialization
      --dockerfile string   Dockerfile to use for initialization (default "./Dockerfile")
  -h, --help                help for init
      --provider string     The cloud provider to use
  -r, --reconfigure         Change existing configuration
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List (`docs/pages/cli/devspace_list.md`)

---
title: "devspace list --help"
sidebar_label: devspace list
---


Lists configuration

## Synopsis


```
#######################################################
#################### devspace list ####################
#######################################################
```


## Flags

```
  -h, --help   help for list
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Commands (`docs/pages/cli/devspace_list_commands.md`)

---
title: "devspace list commands --help"
sidebar_label: devspace list commands
---


Lists all custom DevSpace commands

## Synopsis


```
devspace list commands [flags]
```

```
#######################################################
############## devspace list commands #################
#######################################################
Lists all DevSpace custom commands defined in the 
devspace.yaml
#######################################################
```


## Flags

```
  -h, --help   help for commands
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Contexts (`docs/pages/cli/devspace_list_contexts.md`)

---
title: "devspace list contexts --help"
sidebar_label: devspace list contexts
---


Lists all kube contexts

## Synopsis


```
devspace list contexts [flags]
```

```
#######################################################
############## devspace list contexts #################
#######################################################
Lists all available kube contexts

Example:
devspace list contexts
#######################################################
```


## Flags

```
  -h, --help   help for contexts
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Deployments (`docs/pages/cli/devspace_list_deployments.md`)

---
title: "devspace list deployments --help"
sidebar_label: devspace list deployments
---


Lists and shows the status of all deployments

## Synopsis


```
devspace list deployments [flags]
```

```
#######################################################
############# devspace list deployments ###############
#######################################################
Lists the status of all deployments
#######################################################
```


## Flags

```
  -h, --help   help for deployments
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Namespaces (`docs/pages/cli/devspace_list_namespaces.md`)

---
title: "devspace list namespaces --help"
sidebar_label: devspace list namespaces
---


Lists all namespaces in the current context

## Synopsis


```
devspace list namespaces [flags]
```

```
#######################################################
############ devspace list namespaces #################
#######################################################
Lists all namespaces in the selected kube context
#######################################################
```


## Flags

```
  -h, --help   help for namespaces
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Plugins (`docs/pages/cli/devspace_list_plugins.md`)

---
title: "devspace list plugins --help"
sidebar_label: devspace list plugins
---


Lists all installed devspace plugins

## Synopsis


```
devspace list plugins [flags]
```

```
#######################################################
############# devspace list plugins ##################
#######################################################
Lists all installed plugins

devspace list plugins
#######################################################
```


## Flags

```
  -h, --help   help for plugins
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Ports (`docs/pages/cli/devspace_list_ports.md`)

---
title: "devspace list ports --help"
sidebar_label: devspace list ports
---


Lists port forwarding configurations

## Synopsis


```
devspace list ports [flags]
```

```
#######################################################
############### devspace list ports ###################
#######################################################
Lists the port forwarding configurations
#######################################################
```


## Flags

```
  -h, --help            help for ports
  -o, --output string   The output format of the command. Can be either empty or json
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

### Pages Cli Devspace List Profiles (`docs/pages/cli/devspace_list_profiles.md`)

---
title: "devspace list profiles --help"
sidebar_label: devspace list profiles
---


Lists all DevSpace profiles

## Synopsis


```
devspace list profiles [flags]
```

```
#######################################################
############## devspace list profiles #################
#######################################################
Lists all DevSpace configurations for this project
#######################################################
```


## Flags

```
  -h, --help   help for profiles
```


## Global & Inherited Flags

```
      --debug                        Prints the stack trace if an error occurs
      --disable-profile-activation   If true will ignore all profile activations
      --inactivity-timeout int       Minutes the current user is inactive (no mouse or keyboard interaction) until DevSpace will exit automatically. 0 to disable. Only supported on windows and mac operating systems
      --kube-context string          The kubernetes context to use
      --kubeconfig string            The kubeconfig path to use
  -n, --namespace string             The kubernetes namespace to use
      --no-colors                    Do not show color highlighting in log output. This avoids invisible output with different terminal background colors
      --no-warn                      If true does not show any warning when deploying into a different namespace or kube-context than before
      --override-name string         If specified will override the DevSpace project name provided in the devspace.yaml
  -p, --profile strings              The DevSpace profiles to apply. Multiple profiles are applied in the order they are specified
      --silent                       Run in silent mode and prevents any devspace log output except panics & fatals
  -s, --switch-context               Switches and uses the last kube context and namespace that was used to deploy the DevSpace project
      --var strings                  Variables to override during execution (e.g. --var=MYVAR=MYVALUE)
```

---

--- METRICS ---
- Files Extracted: 100
- Estimated Token Budget: ~46242 tokens
- Canonical Reference: https://codewiki.google/github.com/devspace-sh/devspace