docs: update doc content

sites/docs-devsy-sh/pages/developing-in-workspaces/create-a-workspace.mdx

@@ -13,7 +13,7 @@ Once created, the workspace is reachable through the SSH host `WORKSPACE_NAME.de
 A workspace is defined by a `devcontainer.json`. If none exists, Devsy detects the project's language and picks a matching template.
 :::
 
-### Via Devsy Desktop Application
+### Devsy Desktop
 
 Open the Workspaces view and click **Create** to launch the wizard. It walks through five steps:
 
@@ -41,7 +41,7 @@ This can be useful if you are having trouble with a workspace trying to mount to
 For example: setting `--home=/mnt/c/Users/MyUser/` will result in a workspace path of something like `/mnt/c/Users/MyUser/.devsy/contexts/default/workspaces/...`
 :::
 
-### Via Devsy CLI
+### Devsy CLI
 
 [Install the Devsy CLI](../getting-started/install.mdx#install-devsy-cli) and add a provider to host the workspace (such as local docker):
 ```
@@ -152,7 +152,7 @@ Recreating a workspace re-applies changes from the `devcontainer.json` or its `D
 
 Only changes inside the project path or mounted volumes survive a recreate. **Everything else in the container is lost.**
 
-### Via Devsy CLI
+### Devsy CLI
 
 Rebuild an existing workspace:
 ```
@@ -165,7 +165,7 @@ Reset rebuilds the workspace from a clean slate — it pulls the latest Git chan
 
 **A reset preserves nothing.**
 
-### Via Devsy CLI
+### Devsy CLI
 
 Reset an existing workspace:
 ```

sites/docs-devsy-sh/pages/developing-in-workspaces/credentials.mdx

@@ -29,7 +29,7 @@ devsy context set default -o SSH_INJECT_DOCKER_CREDENTIALS=false
 
 Devsy will make gpg keys available inside the dev container through an ssh tunnel. This allows you to sign commits from inside the workspace.
 
-If you want Devsy to inject the gpg keys, you must that via the following command for all workspaces:
+To have Devsy inject the gpg keys, enable it via the following command for all workspaces:
 ```
 devsy context set default -o GPG_AGENT_FORWARDING=true
 ```

sites/docs-devsy-sh/pages/developing-in-workspaces/delete-a-workspace.mdx

@@ -9,11 +9,11 @@ Deleting a workspace means to erase all state of an existing workspace and remov
 Depending on the Devsy provider, this means either removing a Docker container or deleting a whole virtual machine.
 Devsy will automatically determine what specific action to take when a workspace is deleted.
 
-### Via Devsy Desktop Application
+### Devsy Desktop
 
 In the 'Workspaces' view, open the actions menu for the workspace and choose 'Delete', then confirm the deletion dialog.
 
-### Via Devsy CLI
+### Devsy CLI
 
 Run the following command to delete a workspace:
 ```

sites/docs-devsy-sh/pages/developing-in-workspaces/devcontainer-json.mdx

@@ -18,19 +18,12 @@ This makes it easy to reuse existing configurations and tooling around this stan
 :::
 
 :::info Additional References
-This page mostly gives you an introduction on how to work with devcontainers. For additional information take a look at:
+This page introduces working with devcontainers. For more detail, see:
 * [DevContainer Reference](https://containers.dev/implementors/json_reference/)
 * [VS Code DevContainer Documentation](https://code.visualstudio.com/docs/devcontainers/create-dev-container)
 * [GitHub Codespaces Documentation](https://docs.github.com/en/codespaces/setting-up-your-project-for-codespaces/adding-a-dev-container-configuration/introduction-to-dev-containers#devcontainerjson)
 :::
 
-:::warning Unsupported Properties
-Currently, these `devcontainer.json` properties are not supported in Devsy. These may be implemented in future releases.
-* userEnvProve
-* waitFor
-* Parallel lifecycle scripts
-:::
-
 ## devcontainer.json
 
 The primary file to configure your workspace is the `devcontainer.json`, that lives in the `.devcontainer` sub-folder of your project.

sites/docs-devsy-sh/pages/developing-in-workspaces/dotfiles-in-a-workspace.mdx

@@ -34,9 +34,9 @@ in the `$HOME` directory of the container.
 It is possible to specify **custom install script locations** for your special setup.
 If a custom install script is specified, Devsy will directly run that one instead.
 
-### Via Devsy CLI
+### Devsy CLI
 
-Run the following command to a workspace with a dotfiles repo:
+Run the following command to start a workspace with a dotfiles repo:
 
 ```
 devsy workspace up https://github.com/example/repo --dotfiles https://github.com/my-user/my-dotfiles-repo

sites/docs-devsy-sh/pages/developing-in-workspaces/stop-a-workspace.mdx

@@ -10,11 +10,11 @@ Depending on the provider used, this either means to stop a container (see [dock
 or shutdown the underlying VM where the container is running.
 Devsy will automatically determine what specific action to take when a workspace is stopped.
 
-### Via Devsy Desktop Application
+### Devsy Desktop
 
 In the 'Workspaces' view, open the actions menu for a running workspace and choose 'Stop'. Once stopped, the menu will show a 'Start' option to resume the workspace.
 
-### Via Devsy CLI
+### Devsy CLI
 
 Run the following command to stop a workspace:
 ```
@@ -26,7 +26,7 @@ Afterwards, you can start the workspace via:
 devsy workspace up my-workspace
 ```
 
-## Automatic stopping via a Provider
+## Automatic stop
 
 Some providers allow automatic stop of a workspace, usually to save costs when a workspace is not used.
 For example, the Google Cloud provider will shutdown the virtual machine where the workspace is running after it's unused for 10 minutes, by default.

sites/docs-devsy-sh/pages/developing-in-workspaces/what-are-workspaces.mdx

@@ -3,7 +3,7 @@ title: What are Workspaces?
 sidebar_label: What are Workspaces?
 ---
 
-A workspace in Devsy is a containerized development environment that holds a project's source code along with the dependencies needed to work on it, such as a compiler and debugger. The underlying environment where the container runs is created and managed through a Devsy provider. This gives every engineer a consistent development experience no matter where the container actually runs — a remote machine in a public cloud, localhost, or a Kubernetes cluster.
+A workspace in Devsy is a containerized development environment that holds a project's source code along with the dependencies needed to work on it, such as a compiler and debugger. The underlying environment where the container runs is created and managed through a Devsy provider. This gives every engineer a consistent development experience wherever the container runs — a remote machine in a public cloud, localhost, or a Kubernetes cluster.
 
 To configure the development container, Devsy reuses the [devcontainer.json](https://containers.dev/) specification, which is also used by other popular tools such as [VS Code dev containers](https://code.visualstudio.com/docs/devcontainers/containers) and [GitHub Codespaces](https://github.com/features/codespaces). This means any project that already uses this configuration can spin up a workspace in Devsy with no extra setup. If no configuration is found, Devsy detects the project's programming language and provides an appropriate template.
 

sites/docs-devsy-sh/pages/getting-started/update.mdx

@@ -9,16 +9,10 @@ import CodeBlock from '@theme/CodeBlock';
 
 ## Devsy Desktop
 
-Devsy Desktop checks GitHub for updates every 15 minutes. When an update is available, this popup confirms the update:
+Devsy Desktop checks GitHub for new releases shortly after launch and every few hours while running. When an update is available, it downloads in the background and prompts you to restart. After you restart, Devsy runs the latest version.
 
-The update downloads in the background. When it's ready, Devsy prompts you to restart.
+If you installed Devsy from a `.deb` or `.rpm` package, update through your package manager instead: [download the latest package](https://github.com/devsy-org/devsy/releases/latest/) and install it again.
 
-After restart, Devsy runs the latest version.
+## Devsy CLI
 
-## Devsy Desktop — alternative
-
-If you installed Devsy from a deb or rpm package, [download the new package](https://github.com/devsy-org/devsy/releases/latest/) and install it again through your package manager.
-
-## Update Devsy CLI
-
-Re-run the installation command from [Install Devsy CLI](./install.mdx#install-devsy-cli) to download the latest version.
+Re-run the command from [Install Devsy CLI](./install.mdx#install-devsy-cli) to download the latest version.

sites/docs-devsy-sh/pages/managing-providers/add-provider.mdx

@@ -14,7 +14,7 @@ The Devsy team maintains providers for popular services such as:
 - [Azure (azure)](https://github.com/devsy-org/devsy-provider-azure)
 - [Digital Ocean (digitalocean)](https://github.com/devsy-org/devsy-provider-digitalocean)
 
-These providers can be installed with the Devsy CLI in the following form:
+Install these providers with the Devsy CLI:
 ```
 devsy provider add docker
 ```
@@ -25,7 +25,7 @@ You can get a list of available 1st party providers by using the command:
 devsy provider list --available
 ```
 
-## Via Devsy Desktop Application
+## Devsy Desktop
 
 Open the Providers view and click **Add**. The provider wizard has four steps:
 
@@ -40,15 +40,15 @@ The ProviderSheet (click any provider in the list) exposes edit settings, switch
 The Desktop Application calls `devsy provider add PROVIDER` under the hood.
 :::
 
-### Adding a custom provider
+### Custom Providers
 
 In the Select step, type one of the following into the **Provider Source** field below the preset grid:
 
 - A GitHub link to the provider's project
 - A URL to a `provider.yaml`
 - A file path to a `provider.yaml`
 
-## Via Devsy CLI
+## Devsy CLI
 Install any provider from the list with:
 
 ```sh
@@ -100,17 +100,16 @@ devsy provider add https://github.com/devsy-org/devsy-provider-ssh/releases/down
 
 ## Set Provider Options
 
-Each provider has a set of options, those options can be different for each of
-them, as they are defined by the provider's developers.
+Each provider defines its own options, so they differ from provider to provider.
 
-### Managing options from Devsy Desktop Application
+### Desktop Options
 
 To manage options from the app, head over the `Providers` section, and click
 `Edit` on the provider you want to configure.
 
-### Managing options from Devsy CLI
+### CLI Options
 
-Options for providers can be set during the `configure` or `add` phase:
+Set options during the `add` or `configure` phase:
 
 ```sh
 devsy provider add <provider-name> -o KEY=value
@@ -123,8 +122,7 @@ devsy provider init <provider-name> -o KEY=value
 ```
 
 
-Else, to can manage options afterwards from CLI, you can list the table of provider's options by using:
-
+To manage options later, list the current values with:
 
 ```sh
 devsy provider get <provider-name>
@@ -156,43 +154,19 @@ INJECT_GIT_CREDENTIALS    | false    | If Devsy should inject git    | true
                           |          | host.                          |                         |
 ```
 
-You can see this table as an overview, you can change each option using:
+This table is an overview. Change any option with:
 
 ```sh
 devsy provider set <provider-name> --option <KEY>=<VALUE>
 ```
 
-So for example, to change the default disk size from 40gb to 120gb, you could use:
+For example, to change the disk size from 40GB to 120GB:
 
 ```sh
 devsy provider set aws --option AWS_DISK_SIZE=120
 ```
 
-And check again the options for the provider using `devsy provider get aws`:
-
-```
-          NAME            | REQUIRED |          DESCRIPTION           |         DEFAULT         |          VALUE
-----------------------------+----------+--------------------------------+-------------------------+--------------------------
-AGENT_PATH                | false    | The path where to inject the   | /var/lib/toolbox/devsy | /var/lib/toolbox/devsy
-                          |          | Devsy agent to.               |                         |
-AWS_ACCESS_KEY_ID         | false    | The aws access key id          |                         |
-AWS_AMI                   | false    | The disk image to use.         |                         |
-AWS_DISK_SIZE             | false    | The disk size to use.          | 40                      | 120
-AWS_INSTANCE_TYPE         | false    | The machine type to use.       | c5.xlarge               | c5.xlarge
-AWS_REGION                | true     | The aws cloud region to create |                         | us-west-2
-                          |          | the VM in, e.g. us-west-1      |                         |
-AWS_SECRET_ACCESS_KEY     | false    | The aws secret access key      |                         |
-AWS_VPC_ID                | false    | The vpc id to use.             |                         |
-INACTIVITY_TIMEOUT        | false    | If defined, will automatically | 10m                     | 10m
-                          |          | stop the VM after the          |                         |
-                          |          | inactivity period.             |                         |
-INJECT_DOCKER_CREDENTIALS | false    | If Devsy should inject docker | true                    | true
-                          |          | credentials into the remote    |                         |
-                          |          | host.                          |                         |
-INJECT_GIT_CREDENTIALS    | false    | If Devsy should inject git    | true                    | true
-                          |          | credentials into the remote    |                         |
-                          |          | host.                          |                         |
-```
+Run `devsy provider get aws` again to confirm — the `VALUE` column for `AWS_DISK_SIZE` now reads `120`.
 
 ## Single Machine Provider
 
@@ -210,9 +184,7 @@ devsy provider init <provider-name> --single-machine
 
 ## Default Provider
 
-When adding a provider to Devsy, you can specify it to be the **default provider**,
-this implies that when you create a Workspace, this provider will be used if no
-other is specified.
+When you add a provider, you can mark it as the **default provider**. Devsy then uses it for any workspace you create without specifying another.
 
 In **the desktop app**, you can set a provider to be default in the option management interface for the provider
 (see section above)
@@ -238,7 +210,7 @@ The community maintains providers for additional services.
 - [Vultr (navaneeth-dev/devsy-provider-vultr)](https://github.com/navaneeth-dev/devsy-provider-vultr)
 - [STACKIT (stackitcloud/devsy-provider-stackit)](https://github.com/stackitcloud/devsy-provider-stackit)
 
-These providers can be installed with the Devsy CLI in the following form:
+Install these providers with the Devsy CLI:
 ```
 devsy provider add <user/repository>
 ```

sites/docs-devsy-sh/pages/managing-providers/remove-provider.mdx

@@ -3,17 +3,17 @@ title: Remove a Provider
 sidebar_label: Remove a Provider
 ---
 
-## Via Devsy Desktop Application
+## Devsy Desktop
 
 Navigate to the 'Providers' view and click on the trash icon of the provider
 you want to remove.
 
 If a workspace is currently using the provider, you'll be prompted to first
 remove that workspace, in order to then remove the provider.
 
-## Via Devsy CLI
+## Devsy CLI
 
-An already installed provider can be removed by using:
+Remove an installed provider with:
 
 ```sh
 devsy provider delete <provider name>

sites/docs-devsy-sh/pages/managing-providers/what-are-providers.mdx

@@ -3,40 +3,25 @@ title: What are Providers?
 sidebar_label: What are Providers?
 ---
 
-Providers are simple CLI programs that let Devsy create, manage and run the workspaces requested by the user.
-In the simplest form, a provider defines a command to create, delete and connect to a virtual machine in a cloud.
+A provider is the CLI program Devsy uses to create, manage, and run workspaces on a given backend. This model is what lets Devsy target any infrastructure — local, cloud, Kubernetes, or remote SSH — without changing how you work.
 
-Devsy relies on the provider model in order to allow flexibility and adaptability for any backend of choice.
-Providers in Devsy are defined through a `provider.yaml` that defines the necessary options, configuration, binaries and commands needed to handle workspace creation.
+Each provider is defined by a `provider.yaml` that declares the options, configuration, binaries, and commands Devsy needs to create workspaces on that backend.
 
-See the [Add a provider](./add-provider.mdx) section to learn more about how to add a provider to Devsy.
-See [How to develop a provider](../developing-providers/quickstart.mdx) to learn more about how to create your own provider for Devsy.
+To get started, see [Add a provider](./add-provider.mdx). To build your own, see [How to develop a provider](../developing-providers/quickstart.mdx).
 
-## Type of providers
+## Provider Types
 
-There are two types of providers:
-
-* Machine providers
-* Non-machine providers
+Devsy supports two kinds of providers:
 
 ### Machine providers
 
-Machine providers are those who will create and manage a VM for the workspace
-selected.
-An example of a Machine provider is the AWS Provider, which uses EC2 instances to
-run the environment.
-These type of providers will also manage the lifecycle of the VM, starting/stopping
-and deleting it when needed.
+Machine providers create and manage a VM for the workspace, then run the container on it. They also handle the VM lifecycle — starting, stopping, and deleting it as needed. The AWS provider is one example, using EC2 instances to run the environment.
 
-### Non-Machine providers
+### Non-machine providers
 
-Non-machine providers are those who will work directly with containers, instead
-of using VMs.
-An example of this can be the SSH, Kubernetes, Docker and Podman providers.
-Those providers will **not** create any VMs, but instead directly run the workspace
-container on the target.
+Non-machine providers run the workspace container directly on the target, with no VM to manage. Docker, Podman, Kubernetes, and SSH are examples.
 
-## Managing providers
+## Manage Providers
 
 You can head over the next sections on how to manage Devsy providers:
 

sites/docs-devsy-sh/pages/what-is-devsy.mdx

@@ -10,7 +10,7 @@ Devsy helps organizations scale their engineering operations with standardized,
   <figcaption>Devsy</figcaption>
 </figure>
 
-Devsy connects each developer's local IDE to the infrastructure where the work runs. The same workspace can live on a laptop, a cloud machine, or a shared remote host, and every workspace is created and managed the same way. That consistency lets a team standardize on one environment definition and move between backends without re-learning their tooling.
+Devsy connects each developer's local IDE to the infrastructure where the work runs. The same workspace can live on a laptop, a cloud machine, or a shared remote host, and Devsy creates and manages every workspace the same way. That consistency lets a team standardize on one environment definition and move between backends without re-learning their tooling.
 
 ## Why Devsy?