dstack 0.19.37__tar.gz → 0.19.38__tar.gz

dstack-0.19.38/.github/workflows/build-docs.yml

@@ -0,0 +1,25 @@
+name: Build Docs
+
+on:
+  workflow_call:
+
+jobs:
+  build-docs:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+        with:
+          python-version: 3.11
+      - name: Install dstack
+        run: |
+          uv sync --extra server
+      - name: Build
+        run: |
+          sudo apt-get update && sudo apt-get install -y libcairo2-dev libfreetype6-dev libffi-dev libjpeg-dev libpng-dev libz-dev
+          uv run mkdocs build -s
+      - uses: actions/upload-artifact@v4
+        with:
+          name: site
+          path: site
+          retention-days: 1

{dstack-0.19.37 → dstack-0.19.38}/.github/workflows/docs.yaml

@@ -2,15 +2,10 @@ name: Build & Deploy Docs
 
 on:
   workflow_dispatch:
-    inputs:
-      release-tag:
-        description: "dstack version"
 
 jobs:
   build-docs:
     uses: ./.github/workflows/build-docs.yml
-    with:
-      release-tag: ${{ inputs.release-tag }}
     secrets: inherit
 
   deploy-docs:

{dstack-0.19.37 → dstack-0.19.38}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dstack
-Version: 0.19.37
+Version: 0.19.38
 Summary: dstack is an open-source orchestration engine for running AI workloads on any cloud or on-premises.
 Project-URL: Homepage, https://dstack.ai
 Project-URL: Source, https://github.com/dstackai/dstack
@@ -22,7 +22,7 @@ Requires-Dist: cryptography
 Requires-Dist: cursor
 Requires-Dist: filelock
 Requires-Dist: gitpython
-Requires-Dist: gpuhunt==0.1.12
+Requires-Dist: gpuhunt==0.1.13
 Requires-Dist: ignore-python>=0.2.0
 Requires-Dist: jsonschema
 Requires-Dist: orjson
@@ -366,7 +366,7 @@ Backends can be set up in `~/.dstack/server/config.yml` or through the [project
 
 For more details, see [Backends](https://dstack.ai/docs/concepts/backends).
 
-> When using `dstack` with on-prem servers, backend configuration isn’t required. Simply create [SSH fleets](https://dstack.ai/docs/concepts/fleets#ssh) once the server is up.
+> When using `dstack` with on-prem servers, backend configuration isn’t required. Simply create [SSH fleets](https://dstack.ai/docs/concepts/fleets#ssh-fleets) once the server is up.
 
 ##### Start the server
 

{dstack-0.19.37/src → dstack-0.19.38}/README.md

@@ -52,7 +52,7 @@ Backends can be set up in `~/.dstack/server/config.yml` or through the [project
 
 For more details, see [Backends](https://dstack.ai/docs/concepts/backends).
 
-> When using `dstack` with on-prem servers, backend configuration isn’t required. Simply create [SSH fleets](https://dstack.ai/docs/concepts/fleets#ssh) once the server is up.
+> When using `dstack` with on-prem servers, backend configuration isn’t required. Simply create [SSH fleets](https://dstack.ai/docs/concepts/fleets#ssh-fleets) once the server is up.
 
 ##### Start the server
 

{dstack-0.19.37 → dstack-0.19.38}/contributing/DEVELOPMENT.md

@@ -48,3 +48,7 @@ pyright -p .
 ## 6. Frontend
 
 See [FRONTEND.md](FRONTEND.md) for the details on how to build and develop the frontend.
+
+## 7. Documentation
+
+See [DOCS.md](DOCS.md) for the details on how to preview or build the documentation.

dstack-0.19.38/contributing/DOCS.md

@@ -0,0 +1,49 @@
+# Documentation setup
+
+## 1. Clone the repo:
+
+```shell
+git clone https://github.com/dstackai/dstack
+cd dstack
+```
+
+## 2. Install uv:
+
+https://docs.astral.sh/uv/getting-started/installation
+
+```shell
+curl -LsSf https://astral.sh/uv/install.sh | sh
+```
+
+## 3. Install `dstack` with all extras and dev dependencies:
+
+> [!WARNING]
+> Building documentation requires `python_version >= 3.11`.
+
+```shell
+uv sync --all-extras
+```
+
+`dstack` will be installed into the project's `.venv` in editable mode.
+
+## 4. (Recommended) Install pre-commit hooks:
+
+Code formatting and linting can be done automatically on each commit with `pre-commit` hooks:
+
+```shell
+uv run pre-commit install
+```
+
+## 5. Preview documentation
+
+To preview the documentation, run the follow command:
+
+```shell
+uv run mkdocs serve -w examples -s
+```
+
+If you want to build static files, you can use the following command:
+
+```shell
+uv run mkdocs build -s
+```

{dstack-0.19.37 → dstack-0.19.38}/docker/server/entrypoint.sh

@@ -10,7 +10,7 @@ fi
 DB_PATH="${HOME}/.dstack/server/data/sqlite.db"
 mkdir -p "$(dirname "$DB_PATH")"
 if [[ -z "${LITESTREAM_REPLICA_URL}" ]]; then
-  exec dstack server --host 0.0.0.0
+  dstack server --host 0.0.0.0
 else
   if [[ ! -f "$DB_PATH" ]]; then
     echo "Attempting Litestream restore..."
@@ -23,5 +23,5 @@ else
       fi
     fi
   fi
-  exec litestream replicate -exec "dstack server --host 0.0.0.0" "$DB_PATH" "$LITESTREAM_REPLICA_URL"
+  litestream replicate -exec "dstack server --host 0.0.0.0" "$DB_PATH" "$LITESTREAM_REPLICA_URL"
 fi

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/amd-on-tensorwave.md

@@ -15,7 +15,7 @@ to orchestrate AI containers with any AI cloud vendor, whether they provide on-d
 
 In this tutorial, we’ll walk you through how `dstack` can be used with
 [TensorWave :material-arrow-top-right-thin:{ .external }](https://tensorwave.com/){:target="_blank"} using
-[SSH fleets](../../docs/concepts/fleets.md#ssh).
+[SSH fleets](../../docs/concepts/fleets.md#ssh-fleets).
 
 <img src="https://dstack.ai/static-assets/static-assets/images/dstack-tensorwave-v2.png" width="630"/>
 
@@ -235,6 +235,6 @@ Want to see how it works? Check out the video below:
 <iframe width="750" height="520" src="https://www.youtube.com/embed/b1vAgm5fCfE?si=qw2gYHkMjERohdad&rel=0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" referrerpolicy="strict-origin-when-cross-origin" allowfullscreen></iframe>
 
 !!! info "What's next?"
-    1. See [SSH fleets](../../docs/concepts/fleets.md#ssh)
+    1. See [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets)
     2. Read about [dev environments](../../docs/concepts/dev-environments.md), [tasks](../../docs/concepts/tasks.md), and [services](../../docs/concepts/services.md)
     3. Join [Discord :material-arrow-top-right-thin:{ .external }](https://discord.gg/u8SmfwPpMd)

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/benchmark-amd-containers-and-partitions.md

@@ -122,7 +122,7 @@ The full, reproducible steps are available in our GitHub repository. Below is a
 
 #### Creating a fleet
 
-We first defined a `dstack` [SSH fleet](../../docs/concepts/fleets.md#ssh) to manage the two-node cluster.
+We first defined a `dstack` [SSH fleet](../../docs/concepts/fleets.md#ssh-fleets) to manage the two-node cluster.
 
 ```yaml
 type: fleet

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/gh200-on-lambda.md

@@ -11,7 +11,7 @@ categories:
 # Supporting ARM and NVIDIA GH200 on Lambda
 
 The latest update to `dstack` introduces support for NVIDIA GH200 instances on [Lambda](../../docs/concepts/backends.md#lambda)
-and enables ARM-powered hosts, including GH200 and GB200, with [SSH fleets](../../docs/concepts/fleets.md#ssh).
+and enables ARM-powered hosts, including GH200 and GB200, with [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets).
 
 <img src="https://dstack.ai/static-assets/static-assets/images/dstack-arm--gh200-lambda-min.png" width="630"/>
 
@@ -78,7 +78,7 @@ $ dstack apply -f .dstack.yml
 !!! info "Retry policy"
     Note, if GH200s are not  available at the moment, you can specify the [retry policy](../../docs/concepts/dev-environments.md#retry-policy) in your run configuration so that `dstack` can run the configuration once the GPU becomes available.
 
-> If you have GH200 or GB200-powered hosts already provisioned via Lambda, another cloud provider, or on-prem, you can now use them with [SSH fleets](../../docs/concepts/fleets.md#ssh).
+> If you have GH200 or GB200-powered hosts already provisioned via Lambda, another cloud provider, or on-prem, you can now use them with [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets).
 
 !!! info "What's next?"
     1. Sign up with [Lambda :material-arrow-top-right-thin:{ .external }](https://cloud.lambda.ai/sign-up?_gl=1*1qovk06*_gcl_au*MTg2MDc3OTAyOS4xNzQyOTA3Nzc0LjE3NDkwNTYzNTYuMTc0NTQxOTE2MS4xNzQ1NDE5MTYw*_ga*MTE2NDM5MzI0My4xNzQyOTA3Nzc0*_ga_43EZT1FM6Q*czE3NDY3MTczOTYkbzM0JGcxJHQxNzQ2NzE4MDU2JGo1NyRsMCRoMTU0Mzg1NTU1OQ..){:target="_blank"}

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/gpu-health-checks.md

@@ -55,7 +55,7 @@ For active checks today, you can run [NCCL tests](../../examples/clusters/nccl-t
 
 ## Supported backends
 
-Passive GPU health checks work on AWS (except with custom `os_images`), Azure (except A10 GPUs), GCP, OCI, and [SSH fleets](../../docs/concepts/fleets.md#ssh) where DCGM is installed and configured for background checks. 
+Passive GPU health checks work on AWS (except with custom `os_images`), Azure (except A10 GPUs), GCP, OCI, and [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets) where DCGM is installed and configured for background checks. 
 
 > Fleets created before version 0.19.22 need to be recreated to enable this feature.
 

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/instance-volumes.md

@@ -41,8 +41,8 @@ resources:
 
 <!-- more -->
 
-> Instance volumes work with both [SSH fleets](../../docs/concepts/fleets.md#ssh)
-> and [cloud fleets](../../docs/concepts/fleets.md#cloud), and it is possible to mount any folders on the instance,
+> Instance volumes work with both [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets)
+> and [cloud fleets](../../docs/concepts/fleets.md#backend-fleets), and it is possible to mount any folders on the instance,
 > whether they are regular folders or NFS share mounts.
 
 The configuration above mounts `/root/.dstack/cache` on the instance to `/root/.cache` inside container.

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/intel-gaudi.md

@@ -44,7 +44,7 @@ machines equipped with Intel Gaudi accelerators.
 ## Create a fleet
 
 To manage container workloads on on-prem machines with Intel Gaudi accelerators, start by configuring an 
-[SSH fleet](../../docs/concepts/fleets.md#ssh). Here’s an example configuration for your fleet:
+[SSH fleet](../../docs/concepts/fleets.md#ssh-fleets). Here’s an example configuration for your fleet:
 
 <div editor-title="examples/misc/fleets/gaudi.dstack.yml">
 

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/kubernetes-beta.md

@@ -299,7 +299,7 @@ VM-based backends also offer more granular control over cluster provisioning.
 
 ### SSH fleets vs Kubernetes backend
 
-If you’re using on-prem servers and Kubernetes isn’t a requirement, [SSH fleets](../../docs/concepts/fleets.md#ssh) may be simpler.
+If you’re using on-prem servers and Kubernetes isn’t a requirement, [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets) may be simpler.
 They provide a lightweight and flexible alternative.
 
 ### AMD GPUs

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/nebius.md

@@ -103,7 +103,7 @@ $ dstack apply -f .dstack.yml
 The new `nebius` backend supports CPU and GPU instances, [fleets](../../docs/concepts/fleets.md), 
 [distributed tasks](../../docs/concepts/tasks.md#distributed-tasks), and more. 
  
-> Support for [network volumes](../../docs/concepts/volumes.md#network) and accelerated cluster 
+> Support for [network volumes](../../docs/concepts/volumes.md#network-volumes) and accelerated cluster 
 interconnects is coming soon.
 
 !!! info "What's next?"

dstack-0.19.38/docs/blog/posts/nvidia-dgx-spark.md

@@ -0,0 +1,132 @@
+---
+title: "Orchestrating workloads on NVIDIA DGX Spark"
+date: 2025-11-14
+description: "TBA"
+slug: nvidia-dgx-spark
+image: https://dstack.ai/static-assets/static-assets/images/nvidia-dgx-spark.png
+# categories:
+#   - Benchmarks
+---
+
+# Orchestrating workloads on NVIDIA DGX Spark
+
+With support from [Graphsignal :material-arrow-top-right-thin:{ .external }](https://x.com/GraphsignalAI/status/1986565583593197885){:target="_blank" }, our team gained access to the new [NVIDIA DGX Spark :material-arrow-top-right-thin:{ .external }](https://www.nvidia.com/en-us/products/workstations/dgx-spark/){:target="_blank"} and used it to validate how `dstack` operates on this hardware. This post walks through how to set it up with `dstack` and use it alongside existing on-prem clusters or GPU cloud environments to run workloads.
+
+<img src="https://dstack.ai/static-assets/static-assets/images/nvidia-dgx-spark.png" width="630"/>
+
+<!-- more -->
+
+If DGX Spark is new to you, here is a quick breakdown of the key specs.
+
+* Built on the NVIDIA GB10 Grace Blackwell Superchip with Arm CPUs.
+* Capable of up to 1 petaflop of AI compute at FP4 precision, roughly comparable to RTX 5070 performance.
+* Features 128GB of unified CPU and GPU memory enabled by the Grace Blackwell architecture.
+* Ships with NVIDIA DGX OS (a tuned Ubuntu build) and NVIDIA Container Toolkit.
+
+These characteristics make DGX Spark a fitting extension for local development and smaller-scale model training or inference, including workloads up to the GPT-OSS 120B range.
+
+## Creating an SSH fleet
+
+Because DGX Spark supports SSH and containers, integrating it with dstack is straightforward. Start by configuring an [SSH fleet](../../docs/concepts/fleets.md#ssh-fleets). The file needs the hosts and access credentials.
+
+<div editor-title="fleet.dstack.yml">
+
+```yaml
+type: fleet
+name: spark
+
+ssh_config:
+  user: devops
+  identity_file: ~/.ssh/id_rsa
+  hosts:
+    - spark-e3a4
+```
+
+</div>
+
+The `user` must have `sudo` privileges.
+
+Apply the configuration:
+
+<div class="termy">
+
+```shell
+$ dstack apply -f fleet.dstack.yml
+
+Provisioning...
+---> 100%
+
+ FLEET  INSTANCE  GPU     PRICE  STATUS  CREATED 
+ spark  0         GB10:1  $0     idle    3 mins ago      
+```
+
+</div>
+
+Once active, the system detects hardware and marks the instance as `idle`. From here, you can run
+[dev environments](../../docs/concepts/dev-environments.md), [tasks](../../docs/concepts/tasks.md), 
+and [services](../../docs/concepts/services.md) on the DGX Spark fleet, the same way you would with other on-prem or cloud GPU backends.
+
+## Running a dev environment
+
+Example configuration:
+
+<div editor-title=".dstack.yml">
+
+```yaml
+type: dev-environment
+name: cursor
+
+image: lmsysorg/sglang:spark
+
+ide: cursor
+
+resources:
+  gpu: GB10
+
+volumes:
+  - /root/.cache/huggingface:/root/.cache/huggingface
+
+fleets: [spark]
+```
+
+</div>
+
+We use an [instance volume](../../docs/concepts/volumes.md#instance-volumes) to keep model downloads cached across runs. The `lmsysorg/sglang:spark` image is tuned for inference on DGX Spark. Any Arm-compatible image with proper driver support will work if customization is needed.
+
+Run the environment:
+
+<div class="termy">
+
+```shell
+$ dstack apply -f .dstack.yml
+
+ BACKEND       GPU     INSTANCE TYPE  PRICE  
+ ssh (remtoe)  GB10:1  instance       $0     idle
+
+Submit the run cursor? [y/n]: y
+ 
+ #  NAME    BACKEND       GPU     PRICE  STATUS   SUMBITTED
+ 1  cursor  ssh (remote)  GB10:1  $0     running  12:24
+
+Launching `cursor`...
+---> 100%
+
+To open in VS Code Desktop, use this link:
+  vscode://vscode-remote/ssh-remote+cursor/workflow
+```
+
+</div>
+
+## What's next?
+
+> Running workloads on DGX Spark with `dstack` works the same way as on any other [backend](../../docs/concepts/backends.md) (including GPU clouds): you can run [dev environments](../../docs/concepts/dev-environments.md) for interactive development, [tasks](../../docs/concepts/tasks.md) for fine tuning, and [services](../../docs/concepts/services.md) for inference through the unified interface.
+
+1. Read the [NVIDIA DGX Spark in-depth review :material-arrow-top-right-thin:{ .external }](https://lmsys.org/blog/2025-10-13-nvidia-dgx-spark/){:target="_blank"} by the SGLang team.
+2. Check [dev environments](../../docs/concepts/dev-environments.md), 
+    [tasks](../../docs/concepts/tasks.md), [services](../../docs/concepts/services.md), 
+    and [fleets](../../docs/concepts/fleets.md)
+3. Follow [Quickstart](../../docs/quickstart.md)
+4. Join [Discord :material-arrow-top-right-thin:{ .external }](https://discord.gg/u8SmfwPpMd){:target="_blank"}
+
+!!! info "Aknowledgement"
+    Thanks to the [Graphsignal :material-arrow-top-right-thin:{ .external }](https://graphsignal.com/){:target="_blank"} team for access to DGX Spark and for supporting testing and validation. Graphsignal provides inference observability tooling used to profile CUDA workloads during both training and inference.

{dstack-0.19.37 → dstack-0.19.38}/docs/blog/posts/prometheus.md

@@ -49,7 +49,7 @@ For a full list of available metrics and labels, check out [Metrics](../../docs/
 
 ??? info "NVIDIA"
     NVIDIA DCGM metrics are automatically collected for `aws`, `azure`, `gcp`, and `oci` backends,
-    as well as for [SSH fleets](../../docs/concepts/fleets.md#ssh).
+    as well as for [SSH fleets](../../docs/concepts/fleets.md#ssh-fleets).
 
     To ensure NVIDIA DCGM metrics are collected from SSH fleets, ensure the `datacenter-gpu-manager-4-core`,
     `datacenter-gpu-manager-4-proprietary`, and `datacenter-gpu-manager-exporter` packages are installed on the hosts.

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/backends.md

@@ -1157,12 +1157,12 @@ Also, the `vastai` backend supports on-demand instances only. Spot instance supp
 ## On-prem
 
 In on-prem environments, the [Kubernetes](#kubernetes) backend can be used if a Kubernetes cluster is already set up and configured.  
-However, often [SSH fleets](../concepts/fleets.md#ssh) are a simpler and lighter alternative.
+However, often [SSH fleets](../concepts/fleets.md#ssh-fleets) are a simpler and lighter alternative.
 
 ### SSH fleets
 
 SSH fleets require no backend configuration. 
-All you need to do is [provide hostnames and SSH credentials](../concepts/fleets.md#ssh), and `dstack` sets up a fleet that can orchestrate container-based runs on your servers.
+All you need to do is [provide hostnames and SSH credentials](../concepts/fleets.md#ssh-fleets), and `dstack` sets up a fleet that can orchestrate container-based runs on your servers.
 
 SSH fleets support the same features as [VM-based](#vm-based) backends.
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/dev-environments.md

@@ -460,7 +460,7 @@ retry:
 
 !!! info "Retry duration"
     The duration period is calculated as a run age for `no-capacity` event
-    and as a time passed since the last `interruption` and `error` for `interruption` and `error` events..
+    and as a time passed since the last `interruption` and `error` for `interruption` and `error` events.
 
 ### Inactivity duration
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/fleets.md

@@ -9,7 +9,7 @@ Fleets act both as pools of instances and as templates for how those instances a
 
 When you run `dstack apply` to start a dev environment, task, or service, `dstack` will reuse idle instances from an existing fleet whenever available.
 
-## Backend fleets { #backend-fleets }
+## Backend fleets
 
 If you configured [backends](backends.md), `dstack` can provision fleets on the fly.
 However, it’s recommended to define fleets explicitly.
@@ -269,7 +269,7 @@ retry:
     [`max_price`](../reference/dstack.yml/fleet.md#max_price), and
     among [others](../reference/dstack.yml/fleet.md).
 
-## SSH fleets { #ssh-fleets }
+## SSH fleets
 
 If you have a group of on-prem servers accessible via SSH, you can create an SSH fleet.
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/gateways.md

@@ -11,7 +11,7 @@ provide an HTTPS endpoint mapped to your domain, handle auto-scaling and rate li
 First, define a gateway configuration as a YAML file in your project folder.
 The filename must end with `.dstack.yml` (e.g. `.dstack.yml` or `gateway.dstack.yml` are both acceptable).
 
-<div editor-title="gateway.dstack.yml"> 
+<div editor-title="gateway.dstack.yml">
 
 ```yaml
 type: gateway
@@ -47,6 +47,21 @@ Provisioning...
 
 </div>
 
+## Configuration options
+
+### Backend
+
+You can create gateways with the `aws`, `azure`, `gcp`, or `kubernetes` backends, but that does not limit where services run. A gateway can use one backend while services run on any other backend supported by dstack, including backends where gateways themselves cannot be created.
+
+??? info "Kubernetes"
+    Gateways in `kubernetes` backend require an external load balancer. Managed Kubernetes solutions usually include a load balancer.
+    For self-hosted Kubernetes, you must provide a load balancer by yourself.
+
+### Public IP
+
+If you don't need/want a public IP for the gateway, you can set the `public_ip` to `false` (the default value is `true`), making the gateway private.
+Private gateways are currently supported in `aws` and `gcp` backends.
+
 !!! info "Reference"
     For all gateway configuration options, refer to the [reference](../reference/dstack.yml/gateway.md).
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/services.md

@@ -822,7 +822,7 @@ If one replica of a multi-replica service fails with retry enabled,
 `dstack` will resubmit only the failed replica while keeping active replicas running.
 
 !!! info "Retry duration"
-    The duration period is calculated as a run age for `no-capacity` event and as a time passed since the last `interruption` and `error` for `interruption` and `error` events..
+    The duration period is calculated as a run age for `no-capacity` event and as a time passed since the last `interruption` and `error` for `interruption` and `error` events.
 
 ### Spot policy
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/tasks.md

@@ -719,7 +719,7 @@ If one job of a multi-node task fails with retry enabled,
 `dstack` will stop all the jobs and resubmit the run.
 
 !!! info "Retry duration"
-    The duration period is calculated as a run age for `no-capacity` event and as a time passed since the last `interruption` and `error` for `interruption` and `error` events..
+    The duration period is calculated as a run age for `no-capacity` event and as a time passed since the last `interruption` and `error` for `interruption` and `error` events.
 
 ### Priority
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/concepts/volumes.md

@@ -4,12 +4,12 @@ Volumes enable data persistence between runs of dev environments, tasks, and ser
 
 `dstack` supports two kinds of volumes: 
 
-* [Network volumes](#network) — provisioned via backends and mounted to specific container directories.
+* [Network volumes](#network-volumes) — provisioned via backends and mounted to specific container directories.
   Ideal for persistent storage.
-* [Instance volumes](#instance) — bind directories on the host instance to container directories.
+* [Instance volumes](#instance-volumes) — bind directories on the host instance to container directories.
 Useful as a cache for cloud fleets or for persistent storage with SSH fleets.
 
-## Network volumes { #network }
+## Network volumes
 
 Network volumes are currently supported for the `aws`, `gcp`, and `runpod` backends.
 
@@ -222,7 +222,7 @@ If you've registered an existing volume, it will be de-registered with `dstack`
 ??? info "Can I attach network volumes to multiple runs or instances?"
     You can mount a volume in multiple runs. This feature is currently supported only by the `runpod` backend.
 
-## Instance volumes { #instance }
+## Instance volumes
 
 Instance volumes allow mapping any directory on the instance where the run is executed to any path inside the container.
 This means that the data in instance volumes is persisted only if the run is executed on the same instance.
@@ -257,7 +257,7 @@ Since persistence isn't guaranteed (instances may be interrupted or runs may occ
 volumes only for caching or with directories manually mounted to network storage.
 
 !!! info "Backends"
-    Instance volumes are currently supported for all backends except `runpod`, `vastai` and `kubernetes`, and can also be used with [SSH fleets](fleets.md#ssh).
+    Instance volumes are currently supported for all backends except `runpod`, `vastai` and `kubernetes`, and can also be used with [SSH fleets](fleets.md#ssh-fleets).
 
 ??? info "Optional volumes"
     If the volume is not critical for your workload, you can mark it as `optional`.
@@ -297,7 +297,7 @@ volumes:
 
 ### Use instance volumes with SSH fleets
     
-If you control the instances (e.g. they are on-prem servers configured via [SSH fleets](fleets.md#ssh)), 
+If you control the instances (e.g. they are on-prem servers configured via [SSH fleets](fleets.md#ssh-fleets)), 
 you can mount network storage (e.g., NFS or SMB) and use the mount points as instance volumes.
 
 For example, if you mount a network storage to `/mnt/nfs-storage` on all hosts of your SSH fleet,

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/guides/clusters.md

@@ -8,13 +8,13 @@ Ensure a fleet is created before you run any distributed task. This can be eithe
 
 ### SSH fleets
 
-[SSH fleets](../concepts/fleets.md#ssh) can be used to create a fleet out of existing baremetals or VMs, e.g. if they are already pre-provisioned, or set up on-premises.
+[SSH fleets](../concepts/fleets.md#ssh-fleets) can be used to create a fleet out of existing baremetals or VMs, e.g. if they are already pre-provisioned, or set up on-premises.
 
 > For SSH fleets, fast interconnect is supported provided that the hosts are pre-configured with the appropriate interconnect drivers.
 
 ### Cloud fleets
 
-[Cloud fleets](../concepts/fleets.md#cloud) allow to provision interconnected clusters across supported backends.
+[Cloud fleets](../concepts/fleets.md#backend-fleets) allow to provision interconnected clusters across supported backends.
 For cloud fleets, fast interconnect is currently supported only on the `aws`, `gcp`, `nebius`, and `runpod` backends.
 
 === "AWS"
@@ -68,7 +68,7 @@ To test the interconnect of a created fleet, ensure you run [NCCL](../../example
 
 ### Instance volumes
 
-[Instance volumes](../concepts/volumes.md#instance) enable mounting any folder from the host into the container, allowing data persistence during distributed tasks.
+[Instance volumes](../concepts/volumes.md#instance-volumes) enable mounting any folder from the host into the container, allowing data persistence during distributed tasks.
 
 Instance volumes can be used to mount:
 
@@ -77,7 +77,7 @@ Instance volumes can be used to mount:
 
 ### Network volumes
     
-Currently, no backend supports multi-attach [network volumes](../concepts/volumes.md#network) for distributed tasks. However, single-attach volumes can be used by leveraging volume name [interpolation syntax](../concepts/volumes.md#distributed-tasks). This approach mounts a separate single-attach volume to each node.
+Currently, no backend supports multi-attach [network volumes](../concepts/volumes.md#network-volumes) for distributed tasks. However, single-attach volumes can be used by leveraging volume name [interpolation syntax](../concepts/volumes.md#distributed-tasks). This approach mounts a separate single-attach volume to each node.
 
 !!! info "What's next?"
     1. Read about [distributed tasks](../concepts/tasks.md#distributed-tasks), [fleets](../concepts/fleets.md), and [volumes](../concepts/volumes.md)

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/guides/kubernetes.md

@@ -111,4 +111,4 @@ For more details on clusters, see the [corresponding guide](clusters.md).
 
     If your priority is orchestrating cloud GPUs and Kubernetes isn’t a must, [VM-based](../concepts/backends.md#vm-based) backends are a better fit thanks to their native cloud integration.
 
-    For on-prem GPUs where Kubernetes is optional, [SSH fleets](../concepts/fleets.md#ssh) provide a simpler and more lightweight alternative.
+    For on-prem GPUs where Kubernetes is optional, [SSH fleets](../concepts/fleets.md#ssh-fleets) provide a simpler and more lightweight alternative.

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/guides/metrics.md

@@ -44,7 +44,7 @@ In addition to the essential metrics available via the CLI and UI, `dstack` expo
 
 ??? info "NVIDIA DCGM"
     NVIDIA DCGM metrics are automatically collected for `aws`, `azure`, `gcp`, and `oci` backends,
-    as well as for [SSH fleets](../concepts/fleets.md#ssh).
+    as well as for [SSH fleets](../concepts/fleets.md#ssh-fleets).
 
     To ensure NVIDIA DCGM metrics are collected from SSH fleets, ensure the `datacenter-gpu-manager-4-core`,
     `datacenter-gpu-manager-4-proprietary`, and `datacenter-gpu-manager-exporter` packages are installed on the hosts.

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/guides/protips.md

@@ -215,11 +215,11 @@ To change the default idle duration, set
 ## Volumes
 
 To persist data across runs, it is recommended to use volumes.
-`dstack` supports two types of volumes: [network](../concepts/volumes.md#network) 
+`dstack` supports two types of volumes: [network](../concepts/volumes.md#network-volumes) 
 (for persisting data even if the instance is interrupted)
-and [instance](../concepts/volumes.md#instance) (useful for persisting cached data across runs while the instance remains active).
+and [instance](../concepts/volumes.md#instance-volumes) (useful for persisting cached data across runs while the instance remains active).
 
-> If you use [SSH fleets](../concepts/fleets.md#ssh), you can mount network storage (e.g., NFS or SMB) to the hosts and access it in runs via instance volumes.
+> If you use [SSH fleets](../concepts/fleets.md#ssh-fleets), you can mount network storage (e.g., NFS or SMB) to the hosts and access it in runs via instance volumes.
 
 ## Environment variables
 

{dstack-0.19.37 → dstack-0.19.38}/docs/docs/guides/server-deployment.md

@@ -80,7 +80,7 @@ The server loads this file on startup.
 Alternatively, you can configure backends on the [project settings page](../concepts/projects.md#backends) via UI.
 
 > For using `dstack` with on-prem servers, no backend configuration is required.
-> Use [SSH fleets](../concepts/fleets.md#ssh) instead.
+> Use [SSH fleets](../concepts/fleets.md#ssh-fleets) instead.
 
 ## State persistence