devspace-sh · toyeshhm · Sep 9, 2026
@@ -87,7 +87,7 @@ Instead of rebuilding images and redeploying containers, DevSpace allows you to
 <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
+- DevSpace lets you build multiple images in parallel, tag them automatically 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>

@@ -96,7 +96,7 @@ folder. Creates a devspace.yaml as a starting point.
 	}
 
 	initCmd.Flags().BoolVarP(&cmd.Reconfigure, "reconfigure", "r", false, "Change existing configuration")
-	initCmd.Flags().StringVar(&cmd.Context, "context", "", "Context path to use for intialization")
+	initCmd.Flags().StringVar(&cmd.Context, "context", "", "Context path to use for initialization")
 	initCmd.Flags().StringVar(&cmd.Dockerfile, "dockerfile", helper.DefaultDockerfilePath, "Dockerfile to use for initialization")
 	initCmd.Flags().StringVar(&cmd.Provider, "provider", "", "The cloud provider to use")
 
@@ -508,7 +508,7 @@ echo 'Anyone using this project can invoke it via "devspace run migrate-db"'`,
 	config.Pipelines["dev"] = &latest.Pipeline{
 		Run: `run_dependencies --all       # 1. Deploy any projects this project needs (see "dependencies")
 ensure_pull_secrets --all    # 2. Ensure pull secrets
-create_deployments --all     # 3. Deploy Helm charts and manifests specfied as "deployments"
+create_deployments --all     # 3. Deploy Helm charts and manifests specified as "deployments"
 start_dev ` + imageName + `                # 4. Start dev mode "` + imageName + `" (see "dev" section)`,
 	}
 
@@ -517,7 +517,7 @@ start_dev ` + imageName + `                # 4. Start dev mode "` + imageName +
 		Run: `run_dependencies --all                            # 1. Deploy any projects this project needs (see "dependencies")
 ensure_pull_secrets --all                         # 2. Ensure pull secrets
 build_images --all -t $(git describe --always)    # 3. Build, tag (git commit hash) and push all images (see "images")
-create_deployments --all                          # 4. Deploy Helm charts and manifests specfied as "deployments"`,
+create_deployments --all                          # 4. Deploy Helm charts and manifests specified as "deployments"`,
 	}
 
 	// Save config

@@ -50,7 +50,7 @@ func NewLogsCmd(f factory.Factory, globalFlags *flags.GlobalFlags) *cobra.Comman
 #######################################################
 #################### devspace logs ####################
 #######################################################
-Prints the last log of a pod container and attachs 
+Prints the last log of a pod container and attaches 
 to it
 
 Example:

diff --git a/docs/pages/_partials/config-dependencies.mdx b/docs/pages/_partials/config-dependencies.mdx
@@ -18,7 +18,7 @@ dependencies:                       # struct[]  | Array of dependencies (other p
     ports: false                    # bool      | Reuse dev.ports config from the dependency
     sync: false                     # bool      | Reuse dev.sync config from the dependency
   overwriteVars: true               # bool      | If not defined or true, will overwrite values of variables with the same name in the dependency
-  vars:                             # struct[]  | Variables in the dependency config that should be overriden with the specified values 
+  vars:                             # struct[]  | Variables in the dependency config that should be overridden with the specified values 
   - name: NAME
     value: value
   disableProfileActivation: true    # bool      | If true will ignore profile activations for this dependency

diff --git a/docs/pages/_partials/dependency-vars.mdx b/docs/pages/_partials/dependency-vars.mdx
@@ -1,4 +1,4 @@
-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.
+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 overridden 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

diff --git a/docs/pages/_partials/workflow-open-links.mdx b/docs/pages/_partials/workflow-open-links.mdx
@@ -1,4 +1,4 @@
 
-1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provideded via `dev.*.open[*].url`.
+1. DevSpace starts to periodically send `HTTP GET` requests to the URLs provided 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.
diff --git a/docs/pages/cli/devspace_init.md b/docs/pages/cli/devspace_init.md
@@ -26,7 +26,7 @@ folder. Creates a devspace.yaml as a starting point.
 ## Flags
 
 ```
-      --context string      Context path to use for intialization
+      --context string      Context path to use for initialization
       --dockerfile string   Dockerfile to use for initialization (default "./Dockerfile")
   -h, --help                help for init
       --provider string     The cloud provider to use

diff --git a/docs/pages/cli/devspace_logs.md b/docs/pages/cli/devspace_logs.md
@@ -17,7 +17,7 @@ devspace logs [flags]
 #######################################################
 #################### devspace logs ####################
 #######################################################
-Prints the last log of a pod container and attachs 
+Prints the last log of a pod container and attaches 
 to it
 
 Example:

diff --git a/docs/pages/configuration/dev/connections/file-sync.mdx b/docs/pages/configuration/dev/connections/file-sync.mdx
@@ -270,7 +270,7 @@ dev:
 The `initialSync` option expects a string with an initial sync strategy. The following strategies are available:
 
 `mirrorLocal` mirrors the local filesystem inside the container (default)  
-  1. deletes all files inside the conainer that are not existing on the local filesystem
+  1. deletes all files inside the container that are not existing on the local filesystem
   2. uploads all files which are existing on the local filesystem but are missing within the container
   3. resolves all file conflicts (different content on local filesystem than in inside the container) by preferring the file on the local filesystem (i.e. all files in the container will be replaced if they are different from on the local filesystem)
 
@@ -438,7 +438,7 @@ DevSpace establishes a bi-directional code synchronization between the specified
 The algorithm roughly works like this:
 
 1. Inject a small helper binary via `kubectl cp` into the target container
-2. Run initial sync accoring to the [`initialSync` config option](#initial-sync)
+2. Run initial sync according to the [`initialSync` config option](#initial-sync)
 3. Watch for file changes on both sides (local and remote) and sync them according to the [sync path mappings](#sync-path-mapping)
 4. After every sync process, [restart the container](#onuploadrestartcontainer) or run other custom [post-sync commands](#post-sync-commands) (optional)
 

diff --git a/docs/pages/configuration/dev/connections/terminal.mdx b/docs/pages/configuration/dev/connections/terminal.mdx
@@ -100,7 +100,7 @@ dev:
       lastLines: 100
 ```
 
-DevSpace will continously check what pods match the given selectors and start or end log streaming accordingly.
+DevSpace will continuously check what pods match the given selectors and start or end log streaming accordingly.
 
 
 ## Config Reference

diff --git a/docs/pages/configuration/hooks/README.mdx b/docs/pages/configuration/hooks/README.mdx
@@ -55,7 +55,7 @@ If any hook returns a non-zero exit code, DevSpace will abort and print an error
 
 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
+# This will print the error to the console that has occurred during a deployment
 hooks:
 - events: ["error:deploy:*"]
   command: "echo The following error has occurred during deploying $DEVSPACE_HOOK_DEPLOY_NAME: $DEVSPACE_HOOK_ERROR"
@@ -272,7 +272,7 @@ 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_ERROR**: if an error has occurred 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_`. 

diff --git a/docs/pages/configuration/images/build-engines/buildkit.mdx b/docs/pages/configuration/images/build-engines/buildkit.mdx
@@ -67,7 +67,7 @@ If in-cluster building is not explicitly enabled, DevSpace checks if a local Doc
 DevSpace preferably uses the Docker daemon running in the virtual machine that belongs to your local Kubernetes cluster instead of your regular Docker daemon. This has the advantage that images do not need to be pushed to a registry because Kubernetes can simply use the images available in the Docker daemon belonging to the kubelet of the local cluster. Using this method is only possible when your current kube-context points to a local Kubernetes cluster and is named `minikube`, `docker-desktop` or `docker-for-desktop`.
 
 
-### In-Cluster Deamon
+### In-Cluster Daemon
 If the `inCluster` field is defined for an image, DevSpace will build the image directly in the Kubernetes cluster instead of using the local Docker daemon. DevSpace will start or reuse a BuildKit deployment in the Kubernetes cluster that acts as target BuildKit daemon. For example:
 ```yaml
 images:

diff --git a/docs/pages/configuration/images/build-engines/kaniko.mdx b/docs/pages/configuration/images/build-engines/kaniko.mdx
@@ -303,7 +303,7 @@ images:
       pullSecret: custom-pull-secret
 ```
 **Explanation:**
-The image `backend` is built using kaniko. Kaniko uses the Kubernete secret, `custom-pull-secret`, to pull images from registries that require authentication.
+The image `backend` is built using kaniko. Kaniko uses the Kubernetes secret, `custom-pull-secret`, to pull images from registries that require authentication.
 
 :::tip Creating Pull Secrets using `pullSecrets`
 If you use the `pullSecret` option, you must create the secret before DevSpace tries to build your images. You can automate this by [using the pullSecrets feature](../../pullSecrets/README.mdx) as shown in this example:

diff --git a/docs/pages/configuration/images/build.mdx b/docs/pages/configuration/images/build.mdx
@@ -196,7 +196,7 @@ DevSpace provides several config options to make in-memory changes to the build
 By default, DevSpace tries to skip building images as much as possible. Once any of your images is built once, DevSpace will only rebuild it if one of the conditions is true:
 - The `dockerfile` has changed
 - Any file within the build `context` folder has changed (while respecting `.dockerignore` rules)
-- The image configuration within the `devspace.yaml` has changed (including values set in the pipeline scripe, e.g. via `--set`)
+- The image configuration within the `devspace.yaml` has changed (including values set in the pipeline script, e.g. via `--set`)
 - The image was **not** been built before or the `.devspace/` folder has been deleted/manipulated
 
 You can explicitly override this behavior using the `rebuildStrategy` field:

diff --git a/docs/pages/configuration/images/push.mdx b/docs/pages/configuration/images/push.mdx
@@ -61,7 +61,7 @@ The local registry is used as a fallback by default. DevSpace will try to push i
 - Use `kind load docker-image` if using a local [KinD](https://kind.sigs.k8s.io/) cluster
 - Deploy and use local registry
 
-The local registry can be explicity enabled or disabled to change the default behavior. Changing `enabled` to `true` will force using the local registry instead of `kind load docker-image`
+The local registry can be explicitly enabled or disabled to change the default behavior. Changing `enabled` to `true` will force using the local registry instead of `kind load docker-image`
 ```yaml title=devspace.yaml
 version: v2beta1
 localRegistry:

diff --git a/docs/pages/configuration/pipelines/README.mdx b/docs/pages/configuration/pipelines/README.mdx
@@ -172,7 +172,7 @@ pipelines:
       type: string
     run: |-
         if ! is_empty $(get_flag dockerfile); then
-            echo "Building the image with the overriden dockerfile $(get_flag dockerfile)"
+            echo "Building the image with the overridden dockerfile $(get_flag dockerfile)"
             run_default_pipeline deploy --set "images.my-image.dockerfile=$(get_flag dockerfile)"
         else
             run_default_pipeline deploy
@@ -197,12 +197,12 @@ 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"
+    create_deployments --all          # 2. Deploy Helm charts and manifests specified 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"
+    create_deployments --all                          # 3. Deploy Helm charts and manifests specified as "deployments"
   build:
     # Here we are using the long-form using `run:` instead of passing the script directly
     run: |-
@@ -224,12 +224,12 @@ 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.
+Write all pipeline scripts 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:
+Internally DevSpace uses pipelines for the following commands that can be overridden according to your preferences. DevSpace provides default pipeline scripts for the following top-level commands:
 - [`devspace dev`](#dev)
 - [`devspace deploy`](#deploy)
 - [`devspace build`](#build)

diff --git a/docs/pages/configuration/profiles/README.mdx b/docs/pages/configuration/profiles/README.mdx
@@ -71,7 +71,7 @@ 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:
+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 permanently:
 ```bash
 devspace build -p [PROFILE_NAME]
 devspace deploy -p [PROFILE_NAME]

diff --git a/docs/pages/configuration/profiles/activation.mdx b/docs/pages/configuration/profiles/activation.mdx
@@ -110,4 +110,4 @@ dependencies:
 ```
 
 ### Disable Activations Globally
-The `--disable-profile-activation` flag can be used to disable all profile activations, including those specifed within each dependency's `devspace.yaml`.
+The `--disable-profile-activation` flag can be used to disable all profile activations, including those specified within each dependency's `devspace.yaml`.
diff --git a/docs/pages/configuration/variables.mdx b/docs/pages/configuration/variables.mdx
@@ -31,7 +31,7 @@ DevSpace provides a set of built-in variables:
 - `${DEVSPACE_VERSION}` contains the version of DevSpace that is currently running
 
 ## Custom Variables
-DevSpace lets you define custom varables inside `devspace.yaml` within the `vars` section.
+DevSpace lets you define custom variables inside `devspace.yaml` within the `vars` section.
 
 :::tip Mix & Match Variable Types
 You can define several types of variables in the same config file, e.g. one `devspace.yaml` can contain static variables, env variables and more.

diff --git a/docs/pages/getting-started/development.mdx b/docs/pages/getting-started/development.mdx
@@ -35,7 +35,7 @@ pipelines:
   dev:
     run: |-
       run_dependencies --all       # 1. Deploy any projects this project needs (see "dependencies")
-      create_deployments --all     # 2. Deploy Helm charts and manifests specfied as "deployments"
+      create_deployments --all     # 2. Deploy Helm charts and manifests specified as "deployments"
       start_dev app                # 3. Start dev mode "app" (see "dev" section)
 ```
 

diff --git a/docs/pages/getting-started/initialize-project.mdx b/docs/pages/getting-started/initialize-project.mdx
@@ -98,7 +98,7 @@ You can now run:
 
 Run `devspace -h` or `devspace [command] -h` to see a list of available commands and flags
 ```
-Congratulations! You have succesfully initialized your first DevSpace project! 🎉
+Congratulations! You have successfully initialized your first DevSpace project! 🎉
 
 After running `devspace init`, you will see 3 changes in your project:
 1. New file `devspace.yaml` (tells DevSpace how this project should be build, deployed, and developed)
@@ -116,14 +116,14 @@ pipelines:
   dev:
     run: |-
       run_dependencies --all       # 1. Deploy any projects this project needs (see "dependencies")
-      create_deployments --all     # 2. Deploy Helm charts and manifests specfied as "deployments"
+      create_deployments --all     # 2. Deploy Helm charts and manifests specified as "deployments"
       start_dev app                # 3. Start dev mode "app" (see "dev" section)
   # You can run this pipeline via `devspace deploy` (or `devspace run-pipeline deploy`)
   deploy:
     run: |-
       run_dependencies --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"
+      create_deployments --all                          # 3. Deploy Helm charts and manifests specified as "deployments"
 
 # This is a list of `images` that DevSpace can build for this project
 # We recommend to skip image building during development (devspace dev) as much as possible