Skip to content

Releases: dstackai/dstack-enterprise

0.20.6-v1

21 Jan 13:31

Choose a tag to compare

Server deployment

Memory optimization

This release reduces peak server memory usage. Previously, memory grew with the total number of instances ever submitted; this is now fixed. We recommend upgrading if memory usage increases over time.

Logs storage

Fluent Bit + Elasticsearch/OpenSearch

Run logs can now be stored in your own log storage via Fluent Bit. At the same time, dstack can now read run logs from Elasticsearch/OpenSearch (to display in the UI and CLI), if Fluent Bit ships the logs there.

See the docs for more details.

Fleets

Since 0.20, dstack requires at least one fleet to be created before you can submit any runs. To make this easier, we’ve simplified default fleet creation during project setup in the UI:

In addition, if your project doesn’t have a fleet, the UI will prompt you to create one.

What's changed:

Full changelog: dstackai/dstack@0.20.3...0.20.6

0.20.5-v1

21 Jan 11:20

Choose a tag to compare

This is a hotfix release that fixes a bug in 0.20.4 with some UI pages not working (Users, Projects, Settings).

What's Changed

Full Changelog: dstackai/dstack@0.20.4...0.20.5

0.20.4-v1

21 Jan 10:39

Choose a tag to compare

What's changed

Full Changelog: dstackai/dstack@0.20.3...0.20.4

0.20.3-v1

08 Jan 18:08

Choose a tag to compare

Dev environments

Windsurf IDE

Dev environments now support Windsurf as a first-class IDE option alongside VSCode and Cursor.

type: dev-environment
ide: windsurf

repos:
- https://github.com/dstackai/dstack

resources:
  gpu: 24GB..:1

dstack provisions an instance for your dev environment and seamlessly connects your local Windsurf editor to it.

dstack-windsurf-dev-environment-min

Troubleshooting

Runs/fleets/volumes/gateways JSON via CLI

You can now inspect the full JSON state of runs, fleets, volumes, and gateways using these CLI commands:

$ dstack run get <name> --json
$ dstack fleet get <name> --json
$ dstack volume get <name> --json
$ dstack gateway get <name> --json

Runs/fleets JSON via UI

The UI includes new "Inspect" tabs with read-only JSON viewers for runs and fleets, making it easier to debug and understand resource states.

dstack-inspect-ui-min

What's changed

Full Changelog: dstackai/dstack@0.20.1...0.20.3

0.20.1-v1

25 Dec 11:44

Choose a tag to compare

CLI

No-fleets warning

Since the last major release, fleets are required before submitting runs. This update makes that requirement explicit in the CLI.

Screenshot 2025-12-25 at 15 39 00

When a run is submitted for a project that has no fleets, the CLI now shows a dedicated warning. The run status has also been updated in both the CLI and UI to No fleets instead of No offers.

This removes ambiguity around failed runs that previously appeared as No offers.

dstack login

You can now authenticate the CLI using a new command, dstack login, instead of manually providing a token.

Screenshot 2025-12-25 at 15 42 30

dstack Enterprise supports SSO with providers such as Okta, Microsoft Entra ID, and Google.

Services

Service configurations now support gateway: true.

For services that require gateway features (such as auto-scaling, custom domains, WebSockets, etc), this property makes the requirement explicit. When set, dstack ensures a default gateway is present.

dstack-shim

In addition to the dstack-runner auto-update mechanism introduced in 0.20.0, dstack-shim now also supports auto-updating.

See contributing/RUNNER-AND-SHIM.md for details.

What's Changed

Full Changelog: dstackai/dstack@0.20.0...0.20.1

0.20.0-v1

17 Dec 11:34

Choose a tag to compare

dstack 0.20 is a major release that brings significant improvements and introduces a number of breaking changes. Read below for the most important ones. For migration notes, please refer to the migration guide.

Fleets

dstack previously had two different ways to provision instances for runs: using a fleet configuration or using automatic fleet provisioning on run apply. To unify the UX, dstack no longer creates fleets automatically.

Fleets must now be created explicitly before submitting runs. This gives users full control over the provisioning lifecycle. If you don't need any limits on instance provisioning (as was the case with auto-created fleets), you can create a single elastic fleet for all runs:

type: fleet
name: default-fleet
nodes: 0..

Note that multi-node tasks require fleets with placement: cluster, which provides the best possible connectivity. You will need a separate fleet for each cluster.

Note

To keep the old behavior with auto-created fleets, set the DSTACK_FF_AUTOCREATED_FLEETS_ENABLED environment variable.

Runs

Working directory

Previously, the working_dir property had complicated semantics: it defaulted to /workflow, but for tasks and services without commands, the image's working directory was used instead.

This has now been simplified: working_dir always defaults to the image's working directory. The working directory of the default dstack images is now set to /dstack/run.

Repo directory

Working with repos is now more explicit and intuitive. First, dstack now only sets up repos that are explicitly defined in run configurations via repos; repos initialized with dstack init are not set up unless specified:

type: dev-environment
ide: vscode
repos:
  # Clone the repo in the configuration's dir into `working_dir`
  - .

Second, repos[].path now defaults to working_dir (".") instead of /workflow.

Third, cloning a repo into a non-empty directory now raises an error so that mistakes are not silently ignored. The previous behavior of skipping cloning can be specified explicitly with if_exists: skip:

type: dev-environment
ide: vscode
repos:
  - local_path: .
    path: /my_volume/repo
    if_exists: skip

Events

dstack now stores important events—such as resource CRUD operations, status changes, and other information crucial for auditing and debugging. Users can view events using the dstack event CLI command or in the UI.

$ dstack event
[2025-12-11 15:05:20] [👤admin] [run clever-cheetah-1] Run submitted. Status: SUBMITTED
[2025-12-11 15:05:20] [job clever-cheetah-1-0-0] Job created on run submission. Status: SUBMITTED
[2025-12-11 15:05:26] [job clever-cheetah-1-0-0, instance cloud-fleet-0] Job assigned to instance. Instance status: BUSY (1/1 blocks busy)

CLI

JSON output

The dstack ps and dstack gateway commands now support --format json / --json arguments that print results in JSON instead of plaintext:

$ dstack ps --json
{
  "project": "main",
  "runs": [
    {
      "id": "5f2e08b5-2098-4064-86c7-0efe0eb84970",
      "project_name": "main",
      "user": "admin",
      "fleet": {
        "id": "9598d5db-67d8-4a2e-bdd2-842ab93b2f2e",
        "name": "cloud-fleet"
      },
      ...
    }
  ]
}

Verda (formerly Datacrunch)

The datacrunch backend has been renamed to verda, following the company's rebranding.

projects:
  - name: main
    backends:
      - type: verda
        creds:
          type: api_key
          client_id: xfaHBqYEsArqhKWX-e52x3HH7w8T
          client_secret: B5ZU5Qx9Nt8oGMlmMhNI3iglK8bjMhagTbylZy4WzncZe39995f7Vxh8

Gateways

Gateway configurations now support an optional instance_type property that allows overriding the default gateway instance type:

type: gateway
name: example-gateway

backend: aws
region: eu-west-1

instance_type: t3.large

domain: example.com

Currently instance_type is supported for aws and gcp backends.

All breaking changes

  • Fleets are no longer created automatically on run apply and have to be created explicitly before submitting runs.
  • The run's working_dir now always defaults to the image's working directory instead of /workflow. The working directory of dstack default images is now /dstack/run.
  • repos[].path now defaults to working_dir (".") instead of /workflow.
  • Dropped implicitly loaded repos; repos must be specified via repos configuration property.
  • Cloning a repo into a non-empty directory now raises an error. This can be changed by setting if_exists: skip.
  • Dropped CLI commands dstack config, dstack stats, and dstack gateway create.
  • Dropped Python API RunCollection methods RunCollection.get_plan(), RunCollection.exec_plan(), and RunCollection.submit().
  • Dropped local repos support: dstack init --local and dstack.api.LocalRepo.
  • Dropped Azure deprecated VM series Dsv3 and Esv4.
  • Dropped legacy server environment variables DSTACK_SERVER_METRICS_TTL_SECONDS and DSTACK_FORCE_BRIDGE_NETWORK.

Deprecations

  • Deprecated the API endpoint /api/project/{project_name}/fleets/create in favor of /api/project/{project_name}/fleets/apply.
  • Deprecated repo_dir argument in RunCollection.get_run_plan() in favor of repos[].path.

What's Changed

Read more

0.19.38-v1

21 Nov 08:40

Choose a tag to compare

Run plan

Since 0.19.26 release, dstack provisions instances with respect to configured fleets, but run plans offers didn't reflect that, so you not might see the actual offers used for provisioning. This is now fixed and run plan shows offers with respect to configured fleets. For example, you can create a fleet for provisioning spot GPU instances on AWS:

type: fleet
name: cloud-fleet
nodes: 0..
backends: [aws]
spot_policy: spot
resources: 
  gpu: 1..

and the runs respect that configuration:

✗ dstack apply                                                      
...
 #  BACKEND          RESOURCES                            INSTANCE TYPE  PRICE    
 1  aws (us-east-1)  cpu=4 mem=16GB disk=100GB T4:16GB:1  g4dn.xlarge    $0.526   
 2  aws (us-east-2)  cpu=4 mem=16GB disk=100GB T4:16GB:1  g4dn.xlarge    $0.526   
 3  aws (us-west-2)  cpu=4 mem=16GB disk=100GB T4:16GB:1  g4dn.xlarge    $0.526   
    ...                                                                           
 Shown 3 of 309 offers, $71.552max

Gateways

dstack gateways now support SGLang Router, enabling inference request routing with policies such as cache_aware, power_of_two, round_robin, and random. Currently, the gateway supports sglang-router version 0.2.1. You can enable the SGLang router in your gateway configuration and select any of the available routing policies. Example configuration:

type: gateway
name: sglang-gateway

backend: aws
region: eu-west-1

domain: example.com
router:
  type: sglang
  policy: cache_aware

What's Changed

Full Changelog: dstackai/dstack@0.19.37...0.19.38

0.19.37-v1

13 Nov 10:59

Choose a tag to compare

CLI

dstack attach --logs --since

The dstack attach --logs command now supports a --since argument to show only the recent logs before following real-time logs. You can specify either a relative duration or an absolute timestamp:

# Show logs from a specific timestamp and follow real-time logs
> dstack attach my-task --logs --since 2025-11-05T08:54:15Z

# Show logs from the last 5 minutes and follow real-time logs
> dstack attach my-task --logs --since 5m

This is especially helpful for long-running services and trainings when you don't need to load the entire logs history.

Fleets

Placement groups for elastic fleets

Previously dstack set up interconnected clusters with placement groups only for fleets with static number of instances such as nodes: 8. Now instances provisioned in fleets with placement: cluster always use placement groups. So now you can use elastic fleets and get best connectivity:

type: fleet
name: cloud-fleet
placement: cluster
nodes: 0..

Important change: Multi-node tasks can now run only on fleets with placement: cluster.

Backends

Gateways on Kubernetes

Previously gateways support on Kubernetes was limited to managed Kubernetes with DNS-based load balancers such as EKS. Now the support is extended to IP-based load balancers such as GKE and Nebius' mk8s.

What's Changed

New Contributors

Full Changelog: dstackai/dstack@0.19.36...0.19.37

0.19.36-v1

06 Nov 16:45

Choose a tag to compare

CLI

dstack ps

The output of dstack ps has been revamped to include colored statuses and a more compact resource view. Full resource details are still available in dstack ps --verbose.

dstack-ps

dstack logs --since

The dstack logs command now supports a --since argument to show only recent logs. You can specify either a relative duration or an absolute timestamp:

# Show logs from a specific timestamp
> dstack logs logs-task --since 2025-11-05T08:54:15Z

# Show logs from the last 5 minutes
> dstack logs logs-task --since 5m

Kubernetes

Improved GPU allocation

The kubernetes backend now requests all available GPU types when scheduling jobs, instead of limiting to just the first available type. This enables more flexible scheduling in heterogeneous Kubernetes clusters with multiple GPU types.

Offers

Optional GPU requirements

When specifying GPU requirements with a lower bound of 0 (e.g., gpu: 0..8:24GB), dstack now includes non-GPU offers in addition to GPU instances. This allows for more flexible resource selection when GPU access is optional.

What's changed

New Contributors

Full Changelog: dstackai/dstack@0.19.35...0.19.36

0.19.35-v1

30 Oct 08:38

Choose a tag to compare

Runpod

Instant Clusters

dstack adds support for Runpod Instant Clusters enabling multi-node tasks on Runpod:

✗ dstack apply -f nccl-tests.dstack.yaml -b runpod

 Project          main                                    
 User             admin                                   
 Configuration    .dstack/confs/nccl-tests-simple.yaml    
 Type             task                                    
 Resources        cpu=2.. mem=8GB.. disk=100GB.. gpu:1..8 
 Spot policy      auto                                    
 Max price        -                                       
 Retry policy     -                                       
 Creation policy  reuse-or-create                         
 Idle duration    5m                                      
 Max duration     -                                       
 Reservation      -                                       

 #  BACKEND           RESOURCES                          INSTANCE TYPE     PRICE    
 1  runpod (US-KS-2)  cpu=128 mem=2008GB disk=100GB      NVIDIA A100-SXM…  $16.7…   
                      A100:80GB:8                                                   
 2  runpod (US-MO-1)  cpu=128 mem=2008GB disk=100GB      NVIDIA A100-SXM…  $16.7…   
                      A100:80GB:8                                                   
 3  runpod            cpu=160 mem=1504GB disk=100GB      NVIDIA H100 80G…  $25.8…   
    (CA-MTL-1)        H100:80GB:8                                                   
    ...                                                                             
 Shown 3 of 5 offers, $34.464max

Submit the run nccl-tests? [y/n]: 

Runpod offers clusters of 2 to 8 nodes with H200, B200, H100, and A100 GPUs and InfiniBand networking up to 3200 Gbps.

What's Changed

New Contributors

Full Changelog: dstackai/dstack@0.19.34...0.19.35